в любом случае профит будет

тут люди обсуждали страшные вещи про использование plpython и модуль multiprocessing, а кто нить пробывал asyncio туда вкрутить ? :)

а вообще у самого Robert Haas можно найти интересные презентации и тестамы с разными max_parallel_degree

ну вот я и спрашиваю. Мы думаем с биллиингом мигрировать, но у нас продакшн - это -дев ветка. (и это норм для нас, но вот на счет постри я не уверен)

Ник, Postgres в принципе выглядит как вечная Beta, так что...

норм набросил

Там до сих пор мастер-мастер из коробки нет надо ещё сказать.

угу )

зато уже есть upsert-ы

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

в мускле то с мастер-мастер я без проблем живу лет 8

мастер-мастер и апсерты не нужны

такие дела

апсерты очень нужны.

экономят строчки кода и задержки за счет количества sql команд.

или всё на хранимые процедуры переписывать? )

CTE же есть

google://why upsert is weird

drop table if exists зато в sql server 2k16 появилось

зачем сразу хранимые

мастер-мастер и апсерты не нужны

за upsert-ы не говорил, наверно, только ленивый. как это они не нужны?

во всяком случае никто не заставляет ими пользоваться

вы еще спросите почему мап редьюсов нету...

upsert это весело, но я бы променял upsert на merge

Да, после oracle по merge скучаешь...

А про автономные транзакции никто не вспомнил

Да, хотя бы дблинк и автономные

Они возможно есть в планах, так что надежда есть ?

А merge частенько может заменять update tbl set col=val from (query) where

в мускле то с мастер-мастер я без проблем живу лет 8

Ник, это частный случай. У меня даже мастер слейв никогда нормально не работал. То погибнет, то отстанет

Вы просто не умеете его готовить

booking.com и fb.com как-то живут с репликацией в mysql

тыщи инстансов, все дела.

все верно. для того чтоб приготовить и поддерживать нормальную работу репликации в mysql надо долго и постоянно учиться и практиковаться. А так да... "тыщи инстансов" и штат кулинаров вокруг них.

а в постгре не так?

для поддержании стриминг репликации мастер-слейв - абсолютно не так

у меня конечно не такой большой набор pg был, около 100 наверно инстансов, мастер-слейв

и отставания/разваливания были только из-за физики

(работало без replication slot)

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

но там свой геморой - с невозможность востановления отдельной базы из бакапа

booking.com и fb.com как-то живут с репликацией в mysql

Мои поздравления им. Видимо да, что-то я делаю не так. И куча людей ещё делает не так. Включая бывших разработчиков MySQL :)

Не факт что у них репликация нативная, с таким штатом они могут ее спроектировать и реализовать сами поверх базы

но там свой геморой - с невозможность востановления отдельной базы из бакапа

эм? не пугайте

Это кто из бывших разработчиков mysql что то делает не так?

Не факт что у них репликация нативная, с таким штатом они могут ее спроектировать и реализовать сами поверх базы

ну на самом деле мой случай - это клиент с легаси и слабо регулируемый. типа "ну так получилось" его ответ. или массовая услуга, где вообще ничего формализовать невозможно. Кнутов мастер мастер держит на полтора землекопа с такой же нагрузкой и следит за тем, что туда пишет. А он зануда (и в хорошем смысле тоже), что ой. Т.е. это вполне возможно, но да, с толпой кулинаров и официантов и жестком проектировании

Это кто из бывших разработчиков mysql что то делает не так?

Царев же

Царев никогда не работал в mysql

архивные логи создаются на инстанс, поэтому востановление на какую-то временную точку даже маленькой базы приводит к востановлению всего инстанса. базы в pg на самом деле какой-то атавизм. проще бы сделали, убрали, чтобы народ не путать :)

я смотрю PostgreSQL сообщество Олега канонизировало уже :) эх что религия животворящая с людьми вытворяет :)

Царев никогда не работал в mysql

ну Percona. тем более. он мне патч года 4 назад делал

окей, Олег работал в Percona, и не смог завести параллельную репликацию в MySQL 5.6, о чём написал статью на хабру. Мы кстати долго обсуждали эту статью с ним. Ему на статью ответили что есть MariaDB, Galera, и те проблемы о которых он говорит, исправили в 5.7.

Booking.com использует MariaDB именно из-за хорошо работающей параллельной репликации.

окей, Олег работал в Percona, и не смог завести параллельную репликацию в MySQL 5.6, о чём написал статью на хабру. Мы кстати долго обсуждали эту статью с ним. Ему на статью ответили что есть MariaDB, Galera, и те проблемы о которых он говорит, исправили в 5.7.

в mysql появился один журнал на все стораджи?

А merge частенько может заменять update tbl set col=val from (query) where

в ограниченных случаях - да, можно юзать

:D

окей, Олег работал в Percona, и не смог завести параллельную репликацию в MySQL 5.6, о чём написал статью на хабру. Мы кстати долго обсуждали эту статью с ним. Ему на статью ответили что есть MariaDB, Galera, и те проблемы о которых он говорит, исправили в 5.7.

угу. и на РИТ он пробежался по 5.7 и Галере

disclaimer: я ревьювил статью Олега. Но с учётом того, что я уже к тому моменту ушёл из MySQL, всего спектра решений я не видел.

По поводу одного журнала на все стораджи.

Тут история такая. В MySQL действительно есть отдельно репликационный журнал, и отдельно транзакционный журнал.

Это удваивает издержки на коммит - в теории, т.к. надо делать 2 phase commit в двух транзакционных журналах.

Но у этого есть и преимущества: например, простота подключения разных storage engines

К сожалению, это преимущество тоже теоретическое, т.к. у MySQL в любом случае очень сложный storage engine api

Возмём для сравнения 2 другие multi-engine СУБД: MongoDB и Tarantool

Как устроен MongoDB:

там можно заменить только один storage engine.

Т.е. в системе не может быть несколько storage engines. Выбирается 1 при компиляции.

Репликационный журнал (так называемый oplog) при этом, хранится в этом самом storage engine, как отдельная коллекция.

Т.е. уходит необходимость в 2 phase commit, но данные технически пишутся два раза всё равно (если движок транзакционный).

Такая архитектура тоже результат легаси MongoDB: mmapv1 движок не имел своего транзакционного журнала, поэтому пока у них не появился wired tiger и rockdb , у них вообще не стояла проблема двух журналов.

Думаю, они смогут эту проблему устранить в будущих релизах.

Как устроен Tarantool: у Tarantool транзакционный журнал внешний к storage engine, и он же используется для репликации.

Таким образом, в статью Олега это попало как раз из архитектуры Tarantool - что мол смотрите, вот так правильно.

Теперь, давайте посмотрим как развивалась эта история.

В PostgreSQL вообще нет подключаемых storage engines. End of story. Т.е. сравнение некорректное - система более интегрирована, но лишена архитектурных возможностий конкурентов.

Замечу, однако, что 2 phase commit репликационного и транзакционного лога усложняет параллельную репликацию (т.е. параллельное применение изменений сделанных на мастере на реплике, таким образом распараллеливание "ддогона" реплики) но не является принципиальной проблемой для параллельной репликации

просто решение параллельной репликации становится более технически сложным.

в mariadb c проблемой справились.

так вот, как развивались события дальше.

2 года назад я был фэном архитектуры с pluggable storage engines, и считал её вполне рабочей, при условии что она сделана правильно (с одним транзакционным логом)

В Tarantool параллельно развивалось два storage engine - memtx и sophia, именно по такой архитектуре.

2 года мы пытались её завести, и убедились в следующем:

даже если решить проблему 1 журнала, остаётся целый ряд других "инконруентностей" между ядром субд и storage engine, которые приводят к неэффективной реализации.

Например, у нас идея была что есть disk-based и memory-bsaed storage engines. Т.е. те, у кого фокус на эффективной работе когда данные 100% в памяти, и те, которые эффективно кэшируют данные в памяти.

Мы убедились, что это *не работает*

проблема в том, что кэш по сути надо делать на основе тех же структур данных, что и используются в memory-only движке.

Костя - так в результате какая storage engine осталась?

Т.к. иначе идёт колоссальное повторение усилий в каждом движке

Таким образом, мы в Tarantool 1.7 форкнули Sophia.

И сейчас активно интегрируем этот disk-based движок с нашей in-memory технологией.

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

*но* под капотом там будет общая кодовая база, с разными настройками!

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

Т.е. выбирать PostgreSQL за то, что он более идеально спроектирован чем MySQL - чистой воды религия.

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

в Tarantool мы, я надеюсь, сможем опередить и то и другое на (как вы видите) пару поколений в дизайне

У нас есть нормальные транзакции. Репликация пока асинхронная, но мы идём к тому, тчобы из коробки была синхронная репликация для всех движков.

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

Вопрос есть, а зачем SQL синтаксис пилите таки ? если ниша nosql ?

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

Естественно. Но судя по описанию реплика у него работает, а у MySQL нет :) У меня реально нет ни одной тру стори реплики с MySQL где я не ругался бы. Обычно в бою конечно не ищешь что за ошибка, а в панике переливаешь. Поэтому хз. Но постоянно то рушилась, то отставала хз почему