IA
Мне одному не нравится идея вообще какие-либо локи в базе делать?
Size: a a a
2020 October 06
SL
Igor A
Мне одному не нравится идея вообще какие-либо локи в базе делать?
ну совет про оптимистичные локи вроде как услышан не был, либо совсем не применим к ситуации.
IA
Но это единственный путь не в ад
IA
Pessimistic Локи не скейлятся, плохо работают, итд итп. Надо очень верить базе.
Master-slave вообще приведет непонятно к чему.
10М записей это на пределе того что может нормальная rdbms - те проблемы уже на горизонте
Master-slave вообще приведет непонятно к чему.
10М записей это на пределе того что может нормальная rdbms - те проблемы уже на горизонте
SL
Igor A
Но это единственный путь не в ад
это перенос ада из базы в бэкенд : )
IA
Каждый сам решает) аргументы я написал
PD
Билетов может быть порядка 10 лямов. Производительности хотелось бы добиться порядка 150 rps.
Число билетов не важно при этом, там же rowlock. 150 TPS не должно приводить к блокировкам.
PT
Почему не должно?
PD
Igor A
Pessimistic Локи не скейлятся, плохо работают, итд итп. Надо очень верить базе.
Master-slave вообще приведет непонятно к чему.
10М записей это на пределе того что может нормальная rdbms - те проблемы уже на горизонте
Master-slave вообще приведет непонятно к чему.
10М записей это на пределе того что может нормальная rdbms - те проблемы уже на горизонте
Ну, нет. 10mln - это очень немного записей, нагрузка требуется совсем низкая, так что вообще все равно как делать. Тут не в БД дело, а в чем-то ещё.
PD
Почему не должно?
Потому что это смешная нагрузка. У меня на Pg на дешёвом железе 2000 TPS на в разы более дорогом skip locked получалось без проблем. На тех самых 10mln записей.
Какой движок БД используется?
Какой движок БД используется?
PT
InnoDB.
IA
:)
PD
Ну тогда там нет блокировок всей таблицы на for update, так что все должно быть нормально. А часто в бизнесе ситуация, что 150 TPS прилетают на один SKU?
PT
Нууу, лотерейные билеты же часто надо продавать. И по многу.
PD
Но 150tps? Не очень верю, честно говоря. Это РФ или Китай?
PD
А 'по многу' тут не важно, кстати.
Вообще, если дело в выстраивании в очередь на одной записи - так можно сделать автоматический сплит. Если число запросов на sku больше 50 TPS, то делим на несколько. Если меньше 20 или остаток небольшой, то сливаем.
Вообще, если дело в выстраивании в очередь на одной записи - так можно сделать автоматический сплит. Если число запросов на sku больше 50 TPS, то делим на несколько. Если меньше 20 или остаток небольшой, то сливаем.
СХ
Ну тогда там нет блокировок всей таблицы на for update, так что все должно быть нормально. А часто в бизнесе ситуация, что 150 TPS прилетают на один SKU?
почему? распродажи например
PD
почему? распродажи например
Распродажи чего? Какой товар продается с частотой в 150 TPS? Один товар.
PD
Это же даже не iPhone в день открытия продаж )
SB
Но 150tps? Не очень верю, честно говоря. Это РФ или Китай?
Если это какие-нибудь акции/облигации, там вполне может быть и такое, кмк.