Путешествия Убера:

туда (2013) и обратно (2016)

Реакция PostgreSQL сообщества:

• HackerNews: 294 комментария
• pgsql-hackers: 69 писем
• Reddit: 154 комментария

Ответы Уберу:

	Robert Haas	"Uber's move away from PostgreSQL"
	Christophe Pettus	"A PostgreSQL Response to Uber"
	Simon Riggs	"Thoughts on Uber's list of Postgres Limitations"
	Александр Коротков	"Наш ответ Уберу"

Проблемы PostgreSQL

Логическая организация

Физическая организация

Неиндексный UPDATE

Индексный UPDATE

Сборка мусора

Чем плох вакуум?

• сканирование данных
• в один поток
• завязан на эффективность HOT, index-only scans, репликации
• кровавые детали: Алексей Лесовский «Девять кругов ада или PostgreSQL Vacuum»

Проблема Uber: write amplification

• Маленькое неиндексное обновление:
  1. записать новую версию всей строки в heap
  2. добавить новые записи во все индексы
  3. записать все обновления в WAL

HOT updates

• Heap-Only Tuples
  • если старая и новая версия на одной странице
  • поставить «ссылку» со старой версии на новую
  • и не трогаем индексы
  • и будет счастье?

Ограничения HOT

• работает до первого индексного обновления
  • => чем больше индексов, тем меньше шансов у HOT сработать
• работает, только если есть место
• mini-vacuum неэффективен:
  • когда много параллельных транзакций (OLTP)
  • когда есть длинные транзакции

Ответ сообщества: write amplification

• Robert Haas:
  • есть проблема, HOT не панацея, нужно делать storage engine на undo
• Christophe Pettus, Simon Riggs:
  • есть же HOT, Uber просто ¯\_(ツ)_/¯!
• Александр Коротков:
  • есть HOT, есть ограничения, но скоро будет счастье!

О чём молчит политрук: write amplification

• в проблеме Uber нет ничего «специфического»
• это обычные для OLTP операции (очереди, счётчики, ...)
• MVCC и организация данных на диске в PostgreSQL плохо подходят для OLTP
• полного решения проблемы нет, и видимо будет нескоро
• а с аналогами TokuDB/MyRocks в PostgreSQL всё ещё хуже

Проблемы Uber: репликация и MVCC

• VACUUM на мастере может убить запросы на реплике (max_standby_streaming_delay, 30 секунд по умолчанию)

Проблемы Uber: репликация и MVCC

• длинные транзакции по вине разработчиков

Ответ сообщества: репликация и MVCC

• все:
  • hot_standby_feedback=on
• Christophe Pettus:
  • Uber просто ¯\_(ツ)_/¯ !

О чём молчит политрук: репликация и MVCC

• hot_standby_feedback задерживает VACUUM на мастере
  • => проблемы могут возникнуть уже там!
• ошибки разработчиков случаются
• физическая репликация плохо подходит для масштабирования чтения
• нет, это не «специфический» случай

Проблемы Uber: репликация и write amplification

• репликация физическая:
  • избыточная запись на мастере => избыточная запись в сеть
  • проблемы со скоростью между разными DC
  • широкополосные каналы между DC дорогие
  • и даже дорогих каналов не всегда хватает

Ответ сообщества: репликация и write amplification

• Robert Haas:
  • компрессия WAL или SSL могли бы помочь
  • нужно было попробовать Slony/Bucardo/Londiste
• Simor Riggs:
  • лекция о плюсах/минусах физической репликации
  • скоро будет pglogical!

Ответ сообщества: репликация и write amplification

• Christophe Pettus:
  • «не нужно сравнивать логическую и физическую репликацию»
  • Slony, Bucardo и т.д. сложно установить и управлять, но...
  • Uber ¯\_(ツ)_/¯ !
  • с 9.4 есть же pglogical!

Ответ сообщества: репликация и write amplification

• Александр Коротков:
  • на самом деле, Uber сравнивает логическую репликацию в MySQL и физическую в PostgreSQL
  • в MySQL нет физической репликации, Алибаба работает
  • pglogical пишет на мастере меньше данных, чем MySQL (на самом деле нет)

Проблема Uber: кросс-версионные обновления

• проблема:
  • перейти с 9.2 на 9.3 без остановки мастера
  • с физической репликацией не решается
• pglogical не вариант, потому что 9.4+
• legacy сервисы на PostgreSQL до сих пор на 9.2

Ответ сообщества:

• Robert Haas: ...
• Simon Riggs:
  • pg_upgrade -k не такой уж медленный
  • есть коммерческое решение
• Christophe Pettus:
  • pg_upgrade не панацея, "PostGIS is a huge pain"
  • Uber не осилил Slony/Bucardo/pglogical ¯\_(ツ)_/¯
• Александр Коротков:
  • pglogical

О чём молчит политрук:

• Slony/Bucardo/Londiste:
  • trigger-based (latency на мастере!)
  • изменения записываются в реляционную таблицу
  • и удаляются (VACUUM!)
  • вытаскиваются и прикладываются внешними скриптами
  • удваивают запись на мастере

О чём молчит политрук: проблемы с pglogical

• кросс-версионная репликация может работать, но не обещают (!)
• низкая «обкатанность» даже сейчас, в 2017г.
• рекомендована Уберу как альтернатива репликации MySQL. В 2015г. Серьёзно?

О чём молчит политрук: общие проблемы slony / londiste / bucardo / pglogical

• проблемы с sequences
• DDL только через функции-обёртки
• нет журнала репликации как такового (PITR невозможен)
• нет GTID (перепозиционирование?)
• нет параллелизма

О чём молчит политрук: логическая репликация в PostgreSQL

• один «правильный» сценарий применения физической репликации:
  • High Availability внутри одного DC
• для всего остального нужна логическая репликация
• на сегодня полной альтернативы MySQL репликации в PostgreSQL нет
• в PostgreSQL 10 войдёт урезанный pglogical

Проблема Убер: репликация и баг

• data corruption bug в 9.2
• повреждённые данные на репликах
• баг исправили, но «осадочек остался»

Ответ сообщества: репликация и баг

• все:
  • «так ведь баг давно исправили!»
• Christophe Pettus:
  • "I would not call MySQL bug free"
  • "PostgreSQL had a bug, so we're switching to MySQL."
  • ¯\_(ツ)_/¯

О чём молчит политрук: репликация и баг

"A new version of Postgres could be released at any time that has a bug of this nature, and because of the way replication works, this issue has the potential to spread into all of the databases in a replication hierarchy."

• речь о чувствительности физической репликации к таким багам

Проблема Uber: неэффективный кэш

• меньше переключений контекста в InnoDB
• собственный LRU эффективнее
• статистика (hit rate)

Ответ сообщества: неэффективный кэш

• Robert Haas, Simon Riggs: ...
• Christophe Pettus:
  • есть проблема
  • но неясен эффект на практике
• Александр Коротков:
  • pread() вместо lseek()/read() даёт только 1.5% производительности

О чём молчит политрук: неэффективный кэш

• 1.5% были получены на 1 (одном) бенчмарке на ноутбуке разработчика...
• патч застрял в обсуждениях
• это далеко не единственная проблема в дизайне shared buffers:
  • дублирование данных, контрольные суммы, «вымывание» данных из OS cache
  • в будущем: компрессия, шифрование

Проблема Uber: обработка соединений

• PostgreSQL использует процессы, а MySQL потоки
• синхронизация процессов дороже
• проблемы с большим (сотни) количеством соединений
• pgBouncer в целом решал проблему

Ответ сообщества: обработка соединений

• Robert Haas, Simon Riggs: ...
• Christophe Pettus
  • да, но хорошо бы продемонстрировать на практике
• Александр Коротков
  • надо использовать pgBouncer или другой внешний thread pool

О чём молчит политрук: обработка соединений

• pgBouncer вносит свои проблемы
• MySQL действительно легко переносит сотни соединений
• в Percona Server и MariaDB есть встроенный thread pool для особо тяжёлых случаев

Что в итоге?

• Uber:
  • довольны MySQL
  • PostGIS – это круто, но с подводными камнями и плохо масштабируется в OLTP
  • не верьте в hype, будьте скептиками, тестируйтесь перед миграцией
• сообщество PostgreSQL:
  • подавляющее большинство: «Uber дураки!»
  • единицы: Uber молодцы, нам есть над чем поработать

Спасибо!

Вопросы?