В MySQL 3.23 была нормальная репликация. И в MySQL 5.7 более-менее нормальная репликация.

То есть наша ниша - транзакционный nosql

это не объясняет - данные гарантируются? и кстати я не знаю что такое nosql. ну в смысле я не понимаю, что вкладывается в это понятие. мне честно всё равно каким языком.

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

В MySQL 3.23 была нормальная репликация. И в MySQL 5.7 более-менее нормальная репликация.

в 3.23 я ещё не пытался, в 5.7 уже не пытался :) что-то кстати у меня с row based было и я в итоге mixed

Мы не отвечаем "ок" клиенту пока данные не попадают на диск. Точнее, технически, наш режим работы по умолчанию - ОК после записи в буфер операционной системы. Но у нас есть режим с O_SYNC, когда мы файл журнала открываем без буферизации.

Мы пилим SQL чтобы стать ближе к людям.

И уйти от эзотерики, необходимости учить наши концепции.

И конечно же мы хотим в кровавый энтерпрайз.

Мы пилим SQL чтобы стать ближе к людям.

Отличный ход, а то у каждой модной nosql базы свой синтаксис запросов и это очень доставляет трудностей.

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

а как он устроен?

я так до сих пор и не знаю

аэроспайк возможно скоро тоже станет mysql :)

точнее mariadb nosql :)

из того что понял, там достаточно просто, данные лежат на диске, индекс в памяти, либо и данные и индекс в памяти.. но по сути особой разницы по скорости нет

данные делятся на бины которых 4096 или около того и этими бинами реплицируются

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

с одной стороны чистый С, но с другой стороны похоже что С не потому что так завещал Линус, а потому что С++ не осилили

т.е. достаточно прямолинейный С, без хитрых ядерных паттернов

Мы не отвечаем "ок" клиенту пока данные не попадают на диск. Точнее, технически, наш режим работы по умолчанию - ОК после записи в буфер операционной системы. Но у нас есть режим с O_SYNC, когда мы файл журнала открываем без буферизации.

ну просто на большинство nosql гон, что они ничего не гарантируют. вопрос - биллинг в тарантул можно?

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

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

ну это понятно. грубо говоря, я сейчас не боюсь в mysql.

т.к. репликация асинхронная.

в этом смысле мы работаем точно так же как mysql

как innodb, если быть точным

т.е. есть журнал

к сожалению, это not good enough для меня.

я всё же оч. хочу выкатить синхронную репликацию.

в целом идея - создать неубиваемую транзакционную базу для in-memory задач

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

(это для начала).

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

ну релизы каждые 2 недели, и даже обещали сетевые проблемы которые афир натестил поправить

потому что они не успеют прилететь на slave

ух ты, не знал

точнее даже поправили в 3.7.1 но мы нетестили

потому что они не успеют прилететь на slave

ммм... ну так он перезаберет?

ну представь у тебя мастер умер совсем.

разнесло его

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

у нас конечно будет видно, что слейв не успел забрать

но балансы поедут

а. да понял

т.е. у нас репликация "не разламывается" при фейловере

т.к. у нас мастер-мастер асинхронный

ну ок. 15 лет на mysql. две фирмы. и ничего

при воссоединении сети последнии изменения "докачиваются"

но при этом там не будет проверки на потенциальные конфликты, т.е. проводки надо делать так, чтобы они при "проигрывании" после докачки не ломали консистентность.

например, если у тебя проводка а = а + 3000

b = b - 3000

то это ок

а если у тебя проводка типа a = 6000

то у тебя при мастер-мастере нашем, когда такая проводка прилетит после "восстановления" сети, она имеет шанс перезаписать уже более новое значение a на слейве

но это не тот чатик уже пошёл :)

ща меня забанят ту

т

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

думаю да. нахрена тебе это?

смотри, если нет хотя бы 10 тыщ rps то тарантул не нужне

нужен

можно обойтись любой другой базой у которой больше фич.

есть ещё ниша big data, но там по факту тоже > 10 тыщ rps

(то же самое про aerospike кстати можно сказать, и про memsql). Есть ещё одна причина зачем тарантул может быть нужен - низкий latency. Но это не биллинг.

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

есть ещё ниша big data, но там по факту тоже > 10 тыщ rps

Разве? А если например 50терабайтная база, и к ней ученый один раз в день делает запрос?

Это всякий там антифрод, антиспам, и т.п.

что такое eav?

у каждого свои понятия о БигДата )

запрос учёного = запуск map/reduce. он приводят к миллионам операций с данными обычно

или pregel - то же самое, миллионы операций, если не миллиарды

т.е. там один запрос потенциально несколько раз обходит все данные

entity attribute value

ок, я не догнал причём тут eav и биллинг? при том что eav тормозит в традиционной базе типа PostgreSQL?

Не верю.

что такое eav?

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

Эмм.. и какие с этим сложности ?

у меня сейчас таблиц несколько с этим вашим eav по 50-80 гиг

запросы в пределах 200ms проходят

Эмм.. и какие с этим сложности ?

1. набивать 2. консистентность 3. оверкилл в индексе

на счет индекса не очень понял, а в остальном всё решаемо

а зачем так делать?

почему тупо не положить json в базу?

почему тупо не положить json в базу?

и что с ним потом делать?

У меня пока это легаси, а так да согласен, json уместнее

ну вторичные индексы построить по нужным полям.

postgresql это умеет

mysql начиная с версии 5.7 тоже

ну вторичные индексы построить по нужным полям.

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

mysql начиная с версии 5.7 тоже

кстати, а в перкону и марию это затащили?

percona нет. mariadb свою реализацию сделала

percona выпустит 5.7 скоро

и в нём будет то же самое что в mysql 5.7

кстати, не знаю будет ли это работать на их tokudb движке

percona нет. mariadb свою реализацию сделала

т.е. mariadb отклеилась от innodb?

ну я так понимаю да.

это кстати занятный вопрос, не задумывался над этим

в 5.7 оч. много изменений в innodb и engine api

думаю отклеились

не хочу врать, надо чуваков из mariadb спросить

могу их сюда притащить :)