@pgsql

Страница 24 из 1062
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
В MySQL 3.23 была нормальная репликация. И в MySQL 5.7 более-менее нормальная репликация.
в 3.23 я ещё не пытался, в 5.7 уже не пытался :) что-то кстати у меня с row based было и я в итоге mixed

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

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

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

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

Pavel
14.05.2016
09:43:26
Мы пилим SQL чтобы стать ближе к людям.
Отличный ход, а то у каждой модной nosql базы свой синтаксис запросов и это очень доставляет трудностей.

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
с одной стороны чистый С, но с другой стороны похоже что С не потому что так завещал Линус, а потому что С++ не осилили

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

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

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
технология 21го века. А он вообще развивается? Я смотрел на сорцы, там достаточно уныло
ну релизы каждые 2 недели, и даже обещали сетевые проблемы которые афир натестил поправить

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
потому что они не успеют прилететь на slave
ммм... ну так он перезаберет?

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
есть ещё ниша big data, но там по факту тоже > 10 тыщ rps
Разве? А если например 50терабайтная база, и к ней ученый один раз в день делает запрос?

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
Эмм.. и какие с этим сложности ?
1. набивать 2. консистентность 3. оверкилл в индексе

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

Konstantin
14.05.2016
10:39:25
а зачем так делать?

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

Phil
14.05.2016
10:40:24
почему тупо не положить json в базу?
и что с ним потом делать?

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) деталей не раскрывает, я не уверен, что много кто пользуется

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

Konstantin
14.05.2016
10:44:04
percona нет. mariadb свою реализацию сделала

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

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

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

Phil
14.05.2016
10:45:07
percona нет. mariadb свою реализацию сделала
т.е. mariadb отклеилась от innodb?

Konstantin
14.05.2016
10:45:23
ну я так понимаю да.

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

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

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

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

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

Страница 24 из 1062