HabrMVCC без VACUUM: что нам дал UNDO-лог, какую цену мы заплатили и зачем нам 5 механизмов сборки мусора
Новая статья из цикла про нашу OLTP-СУБД на Rust. С самого начала мы выбрали MVCC на UNDO-логе вместо версионирования в heap, как в PostgreSQL. И годами повторяли свой же лозунг: «нет VACUUM, нет bloat». Оказалось, это правда ровно наполовину. Heap и правда не пухнет от истории версий. Но bloat никуда не делся: он переехал в индексы, в мёртвые слоты и в сам UNDO-лог. А сборка мусора из одного механизма незаметно превратилась в пять, и мы только сводим их к единому координатору. В статье разобрали без прикрас обе стороны. Что UNDO-модель дала: стабильный TID (UPDATE, который не трогает индексы), rollback пропорционально размеру транзакции, аналитику, не дорожающую от write-нагрузки, и AS OF как «машину времени» почти даром. И чем за это платим: главная эксплуатационная цена это долгоживущий снапшот, который молча останавливает очистку для всех. Вопрос к тем, кто эксплуатировал MVCC-базы под нагрузкой: что меньшее зло — блокировать GC ради долгих транзакций или отдавать «snapshot too old»? Любопытно ваше мнение в комментариях.
MVCC без VACUUM: что нам дал UNDO-лог, какую цену мы заплатили и зачем нам 5 механизмов сборки мусора
Мы пишем реляционную базу данных на Rust. В предыдущих статьях цикла мы разбирали отдельные подсистемы: Buffer Pool с Clock-sweep и изоляцией сканов и векторизованный исполнитель с многоверсионными...