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

[metaclass.livejournal.com]

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

[jakobz.livejournal.com]

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

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

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

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