
Konstantin
14.05.2016
09:39:34
В MySQL 3.23 была нормальная репликация. И в MySQL 5.7 более-менее нормальная репликация.

Phil
14.05.2016
09:39:45
То есть наша ниша - транзакционный nosql
это не объясняет - данные гарантируются? и кстати я не знаю что такое nosql. ну в смысле я не понимаю, что вкладывается в это понятие. мне честно всё равно каким языком.

Konstantin
14.05.2016
09:39:56
Все остальные релизы - это переход от statement-based (3.23) к row-based, и без знания деталий заводится она через ж.

Phil
14.05.2016
09:40:34

Google

Konstantin
14.05.2016
09:40:50
Мы не отвечаем "ок" клиенту пока данные не попадают на диск. Точнее, технически, наш режим работы по умолчанию - ОК после записи в буфер операционной системы. Но у нас есть режим с O_SYNC, когда мы файл журнала открываем без буферизации.
Мы пилим SQL чтобы стать ближе к людям.
И уйти от эзотерики, необходимости учить наши концепции.
И конечно же мы хотим в кровавый энтерпрайз.

Pavel
14.05.2016
09:43:26

Magistr
14.05.2016
09:47:10
Константин, спасибо за такой развернутый ответ, я вспомнил аэроспайк когда зашла речь о движках на диске и в памяти

Konstantin
14.05.2016
09:50:12
а как он устроен?
я так до сих пор и не знаю
аэроспайк возможно скоро тоже станет mysql :)
точнее mariadb nosql :)

Magistr
14.05.2016
10:01:53
из того что понял, там достаточно просто, данные лежат на диске, индекс в памяти, либо и данные и индекс в памяти.. но по сути особой разницы по скорости нет
данные делятся на бины которых 4096 или около того и этими бинами реплицируются

Konstantin
14.05.2016
10:12:17
технология 21го века. А он вообще развивается? Я смотрел на сорцы, там достаточно уныло

Google

Konstantin
14.05.2016
10:12:48
с одной стороны чистый С, но с другой стороны похоже что С не потому что так завещал Линус, а потому что С++ не осилили
т.е. достаточно прямолинейный С, без хитрых ядерных паттернов

Phil
14.05.2016
10:13:24

Konstantin
14.05.2016
10:14:15
Можно если у тебя либо battery-backed cache, либо ты не боишься потерять N последний проводок при падении мастера.

Phil
14.05.2016
10:14:44

Konstantin
14.05.2016
10:14:45
т.к. репликация асинхронная.
в этом смысле мы работаем точно так же как mysql
как innodb, если быть точным
т.е. есть журнал
к сожалению, это not good enough для меня.
я всё же оч. хочу выкатить синхронную репликацию.
в целом идея - создать неубиваемую транзакционную базу для in-memory задач

Phil
14.05.2016
10:16:30
хмхм... задумался. но я правда репликацию никогда не использовал... хм... а почему кстати потеряются транзакции?

Konstantin
14.05.2016
10:16:30
(это для начала).

Magistr
14.05.2016
10:16:40

Konstantin
14.05.2016
10:16:41
потому что они не успеют прилететь на slave
ух ты, не знал

Magistr
14.05.2016
10:17:24
точнее даже поправили в 3.7.1 но мы нетестили

Phil
14.05.2016
10:18:09

Konstantin
14.05.2016
10:20:27
ну представь у тебя мастер умер совсем.

Google

Konstantin
14.05.2016
10:20:29
разнесло его
или другой вариант : он умер временно, но ты на слейва переключился, т.к. у тебя деньги горят
у нас конечно будет видно, что слейв не успел забрать
но балансы поедут

Phil
14.05.2016
10:21:11
а. да понял

Konstantin
14.05.2016
10:21:11
т.е. у нас репликация "не разламывается" при фейловере
т.к. у нас мастер-мастер асинхронный

Phil
14.05.2016
10:21:28
ну ок. 15 лет на mysql. две фирмы. и ничего

Konstantin
14.05.2016
10:21:38
при воссоединении сети последнии изменения "докачиваются"
но при этом там не будет проверки на потенциальные конфликты, т.е. проводки надо делать так, чтобы они при "проигрывании" после докачки не ломали консистентность.
например, если у тебя проводка а = а + 3000
b = b - 3000
то это ок
а если у тебя проводка типа a = 6000
то у тебя при мастер-мастере нашем, когда такая проводка прилетит после "восстановления" сети, она имеет шанс перезаписать уже более новое значение a на слейве
но это не тот чатик уже пошёл :)
ща меня забанят ту
т

Phil
14.05.2016
10:23:35
я просто честно не могу понять - а имеет ли реальный смысл тарантула для классическогго биллинга и личного кабинета? или это я пытаюсь на асфальтоукладчике кирпичи к стройке подвозить?

Konstantin
14.05.2016
10:23:50
думаю да. нахрена тебе это?

Google

Konstantin
14.05.2016
10:24:07
смотри, если нет хотя бы 10 тыщ rps то тарантул не нужне
нужен
можно обойтись любой другой базой у которой больше фич.
есть ещё ниша big data, но там по факту тоже > 10 тыщ rps
(то же самое про aerospike кстати можно сказать, и про memsql). Есть ещё одна причина зачем тарантул может быть нужен - низкий latency. Но это не биллинг.

Phil
14.05.2016
10:26:21
а. ага. понял. собственно во всей екомерсе есть проблема на уровне базы товаров - там начинается или гавно типа EAV или кэширование всего в nosql для индексов.

Pavel
14.05.2016
10:26:24

Konstantin
14.05.2016
10:26:26
Это всякий там антифрод, антиспам, и т.п.
что такое eav?

Alex
14.05.2016
10:27:08
у каждого свои понятия о БигДата )

Konstantin
14.05.2016
10:27:18
запрос учёного = запуск map/reduce. он приводят к миллионам операций с данными обычно
или pregel - то же самое, миллионы операций, если не миллиарды
т.е. там один запрос потенциально несколько раз обходит все данные
entity attribute value
ок, я не догнал причём тут eav и биллинг? при том что eav тормозит в традиционной базе типа PostgreSQL?
Не верю.

Phil
14.05.2016
10:30:57
что такое eav?
не знаю даже как на пальцах. есть товар. у него есть какие-то свойства. свойства описываются таблицей с тремя полями "что" "какое свойство" "значение". это так грубо. и вот это обычно кошмар. всё что так описывается в реляционном мире. https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model

Alex
14.05.2016
10:32:24
Эмм.. и какие с этим сложности ?
у меня сейчас таблиц несколько с этим вашим eav по 50-80 гиг
запросы в пределах 200ms проходят

Google

Phil
14.05.2016
10:33:06

Alex
14.05.2016
10:35:25
на счет индекса не очень понял, а в остальном всё решаемо

Konstantin
14.05.2016
10:39:25
а зачем так делать?
почему тупо не положить json в базу?

Phil
14.05.2016
10:40:24

Alex
14.05.2016
10:41:16
У меня пока это легаси, а так да согласен, json уместнее

Konstantin
14.05.2016
10:41:26
ну вторичные индексы построить по нужным полям.
postgresql это умеет
mysql начиная с версии 5.7 тоже

Phil
14.05.2016
10:43:28
ну вторичные индексы построить по нужным полям.
а оно при этом работает? ну и 9.5 (pg тоже не умел) и 5.7, так что это вот буквально вот, документация (как впрочем вся документация в postgres) деталей не раскрывает, я не уверен, что много кто пользуется

Konstantin
14.05.2016
10:44:04
percona нет. mariadb свою реализацию сделала
percona выпустит 5.7 скоро
и в нём будет то же самое что в mysql 5.7
кстати, не знаю будет ли это работать на их tokudb движке

Phil
14.05.2016
10:45:07

Konstantin
14.05.2016
10:45:23
ну я так понимаю да.
это кстати занятный вопрос, не задумывался над этим
в 5.7 оч. много изменений в innodb и engine api
думаю отклеились
не хочу врать, надо чуваков из mariadb спросить
могу их сюда притащить :)