Postgresql в убере

[metaclass]

https://eng.uber.com/mysql-migration/
http://postgresql.nabble.com/Why-we-lost-Uber-as-a-user-td5913417.html

Занятное чтиво про заморочки MVCC и реализации индексов в postgresql.
Все бы это хорошо, но я не понимаю один момент - почему они сравнивают только физическую репликацию (передачу изменений в страницах БД) и репликацию передачей исполняемых запросов?
Есть же вариант "передавать логические изменения в во всех измененных записях в порядке их коммита". Т.е. в таком варианте проблемы с недетерминированным выполнением запросов отсутствуют, но размер передаваемых данных заметно меньше, чем в случае "передавать весь WAL".

Comments

[plumqqz.livejournal.com]

У них там технарь сменился, вот и. Обычный хипстеж.

[cmotruc.livejournal.com]

Не сменился. Несколько лет назад он же писал доклад о перезде убера с MySql на Postgres.

[jakobz.livejournal.com]

Вон чуваки их бинарного лога посгреса выгребают логические изменения и кладут в кафку
http://www.confluent.io/blog/bottled-water-real-time-integration-of-postgresql-and-kafka/

Я вообще думаю что на замену "мы выбрали одну БД и трахаемся с кэшами", грядет "срем в очередь, откуда одни куски летят в РСУБД, другие в Elastic, третьи - сразу в in-memory cache, и еще в аналитику".

Т,е. transaction log на той же кафке должен стать главным узлом, а не БД, которая умеет всего понемногу и плохо.

Хотя именно что РСУБД на входе в очередь все равно большинству потребуется. Чисто для OLTP-целей - чтобы reference integrity была, и прочая consistency.

Так что как по мне, все эти хипстерские самодельные репликации как в MSSQL - в жопу. БД должна уметь шипать логический transaction log в понятном другим виде, который будет уметь жрать не только эта самая БД, а еще куча всего вокруг. И Postgre делает правильно как всегда, а MSSQL как всегда - хипстерское попсовое говно ради сиюминутных бенчмарков.

[metaclass.livejournal.com]

Консистентность без одной точки с транзакциями или распределенных транзакций как-то не получается.
Т.е. для некоторых систем оно то пригодно - логи там собирать, метрики миллиардами, а вот если гонять деньги - без БД чо-то не получается, очереди либо дают нужные гарантии с транзакциями либо производительность, вместе что-то не придумывается.

[jakobz.livejournal.com]

Ну да, я ж и говорю что РСУБД (или чот-то еще с консистентностью) на входе все равно большинству надо.

Но из нее можно выкинуть большую часть обычной РСУБД:
- все данные которые не влияют на консистентность. В типичной СУБД это большая часть данных, за вычетом ID-шек в табличках, и может каких-нибудь там "сколько денег на счете"
- все индексы, которые не нужны чтобы чекать консистентность
- оптимизатор запросов - тоже вряд ли нужен
- всякие там аудиты, все про аналитику, в общем все что не касается OLTP.
- даже персистить на диск не надо

Т.е. точка входа может заниматься только тем чтобы:
- проверить что операция не нарушает consistency
- если ок - записать в transaction log

В этом раскладе, может оказаться что хватит какой-нибудь шустрой in-memory БД. А может и просто самописного кода в стиле applyTransaction(state, transaction) => state.

[anonim-legion.livejournal.com]

>MSSQL

В статье MySql

[anonim-legion.livejournal.com]

Из статьи:

Depending on how it’s written, the code may implicitly have a database transaction that’s held open until after the email finishes sending. While it’s always bad form to let your code hold open database transactions while performing unrelated blocking I/O, the reality is that most engineers are not database experts and may not always understand this problem, especially when using an ORM that obscures low-level details like open transactions.

Первое выделенное вообще чудесно. Я не столь давно встретил код на C# и EntityFramework, который увеличивал счетчик голосования и выглядел примерно как:

using(var db = new DbContext())
{
var vote = db.getVoteById(id);
vote.count++;
db.SaveChanges();
}

Этот код разумеется рушился при конкурентном обновлении. До того, как начать падать, оно проработало примерно год.

А вся беда в том, что в айти отсутствует стремление к специализации. Сама субкультура подталкивает людей к тому, чтобы они били себя пяткой в грудь и говорили, что все знают и умеют, и занимались не своим делом. Вместо того, чтобы честно сказать "я это не знаю, и делать не буду, пока не узнаю, это потребует длительного времени, идите нах".

Но и второе тоже хорошо. ORM, которые явно держат транзакции - встречаются редко. И уж точно в них не полезет разработчик без опыта.

[berezovsky.livejournal.com]

а кого ебёт, что не знает? сказали - делай. не знаешь - разбирайся. не хочешь - уёбывай.

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

[tzirechnoy.livejournal.com]

В айти дохера стремления к спецыализацыи. Фронтэнд, бэкэнд, эмбедщики, системщики, девопсы, и пр.

Просто многие лезут куда не надо своими грязными ручками. Гуевозитель после примеров на бейсике херачит в РСУБД, вообще не представляя что это и какие вопросы оно решает.
По объективным причинам лезут, да -- поскольку спрос всё равно превышает предложэние, но от этого не легче.