концепції / mvcc
MVCC (багатоверсійне керування конкурентним доступом)
Розглядається як прихований механізм за реальною архітектурною відмінністю між MySQL і Postgres. Обидві бази копіюють рядки в межах транзакцій, але в Postgres копії лягають за новими фізичними адресами — а оскільки вторинні індекси Postgres вказують на фізичне розташування рядків, оновлення навіть однієї індексованої колонки змушує перебудувати ВСІ індекси таблиці. Оптимізація HOT (heap-only tuple) допомагає лише тоді, коли нова версія вміщується в той самий блок на 8 КБ. MySQL натомість оновлює лише той індекс, якого зміна справді стосується (відео про індекси в MySQL і Postgres).
Віктор підкріплює це наслідками в індустрії: знаменита сага міграцій Uber Postgres → MySQL → Postgres була спричинена саме цими нутрощами — нагадування, що відповідь на питання «яка база краща» залежить від того, чи багато у вашому навантаженні оновлень індексованих таблиць, а не від хайпу.
Розібрано у відео
- Як працюють індекси в базах на прикладі: MySQL vs Postgres, UUID vs Auto Increment
повне пояснення: копії рядків на транзакцію, перебудова всіх індексів у Postgres проти точкових оновлень у MySQL, обмеження HOT та історія міграції Uber
Повʼязане
Індекси баз даних — MVCC визначає, скільки UPDATE коштує вашим індексам B-tree / B+ tree — структури, які перебудовуються Глибоке вивчення фундаментальних речей — його ширша теза: саме такі нутрощі дозволяють передбачати поведінку на масштабі