Создание репликационно-безопасных LSM деревьев в Postgres: улучшение производительности и надежности баз данных

Альткойны

Log-Structured Merge Tree, или LSM дерево, представляет собой специализированную структуру данных, которая в последние годы приобрела популярность в системах с интенсивной записью, таких как RocksDB, Cassandra и теперь Postgres. Основная идея LSM дерева заключается в оптимизации операций записи за счет превращения случайных записей в последовательные. Это достигается путем первичного сохранения данных в памяти в структуре, называемой memtable, а затем периодического сброса этих данных на диск в виде сегментированных файлов, упорядоченных по времени записи. Со временем эти сегменты объединяются в более крупные уровни через процесс, известный как компактация. Такая архитектура позволяет значительно увеличить скорость вставки и обновления данных, что особенно важно для сценариев с высокими нагрузками, таких как онлайн-поиск и аналитика в реальном времени.

Postgres традиционно использовал структуру данных типа B-дерево или GIN для полнотекстового поиска. Однако, несмотря на эффективность поиска, эти индексы нередко становятся узким местом при больших объемах записей, замедляя производительность при интенсивной нагрузке на запись. Внедрение LSM деревьев в Postgres должно было стать ответом на эту проблему, обеспечивая улучшенную пропускную способность записи и сокращая время индексации. Тем не менее, переход на LSM деревья в Postgres не прошел без сложностей. Основной вызов состоял в сохранении репликационной безопасности — способности поддерживать консистентное и надежное дублирование данных на репликах.

Postgres обеспечивает два типа репликации: физическую и логическую. Физическая репликация основывается на технологии Write-Ahead Logging (WAL), где изменения на первичном узле транслируются на реплицируемые узлы на уровне блоков данных. Логическая репликация работает выше, передавая изменения строк по отдельности. При этом LSM деревья, из-за своей сложной структуры, нарушали целостность процессов физической репликации по умолчанию. Проблемы физической репликации с LSM деревьями связаны с атомарностью обновлений.

В Postgres заметной особенностью является отсутствие возможности воспроизведения блокировок транзакций на репликах, так как это существенно замедлило бы производительность. Вместо этого, система полагается на пакетное применение изменений к отдельным блокам памяти, обеспечивая их последовательное и атомарное изменение. Однако операции, охватывающие несколько блоков данных одновременно, в том числе и связанные с LSM деревьями, могут привести к промежуточным состояниям, которые реплики не смогут корректно воспроизвести, что в итоге приводит к структурной ошибке данных. Чтобы решить эту проблему, разработчики использовали метод Copy-on-Write, создавая копии структур данных в памяти, которые потом атомарно заменяются целиком. Такая техника помогает изолировать изменения и исключить возможность появления непоследовательного состояния на репликах.

В случае с LSM деревом это означает, что группа сегментов при компактации заменяется целиком, а не частично, что обеспечивает согласованное и безопасное обновление. Еще одна существенная проблема, влияющая на целостность репликации, — взаимодействие с процессом VACUUM. Данная операция в Postgres отвечает за очистку «мертвых» версий строк, которые появляются из-за особенностей системы многоверсионной совместимости транзакций (MVCC). При обновлении или удалении строк предыдущие версии не удаляются мгновенно, а остаются на диске для поддержки согласованности многопользовательских транзакций. VACUUM периодически очищает такие устаревшие данные, освобождая пространство и улучшая производительность.

Возникает сложность в том, что VACUUM запускается на основном сервере и его действия транслируются на реплики. Однако реплики могут одновременно обрабатывать долгие запросы, которые еще используют «мертвые» строки, но VACUUM на основном сервере в это время уже счел эти данные неактуальными. Это приводит к конфликтам и возможным ошибкам при чтении на репликах, поскольку они пытаются получить доступ к удаленным данным. Данная проблема обостряется при использовании LSM деревьев, где компактация данных происходит постоянно, порой несколько раз в секунду. Таким образом, риск возникновения конфликтов и сбоев на репликах значительно возрастает, особенно под высокими нагрузками записи.

Для решения данной проблемы Postgres предлагает настройку hot_standby_feedback. Эта опция позволяет репликам сообщать основному серверу минимальную точку снимка транзакций (xmin), которая используется в активных запросах. Иными словами, реплики уведомляют, какие версии данных своим запросам еще необходимы, заставляя основной сервер отложить очистку VACUUM до тех пор, пока эти запросы не завершатся. Благодаря hot_standby_feedback основной сервер удерживает «мертвые» версии данных до безопасного момента, что значительно снижает вероятность возникновения ошибок в процессе репликации. Для систем с LSM деревьями, таких как pg_search — расширение Postgres для поиска — эта функция является ключевым элементом, гарантирующим логическую консистентность данных на репликах.

Тем не менее, стоит понимать, что использование hot_standby_feedback — это компромисс. Отсрочка очистки VACUUM может привести к увеличению объема неподчищенных данных и, как следствие, росту потребления места на диске. Поэтому внедрение этой опции должно сопровождаться мониторингом и настройкой времени выполнения VACUUM, а также управления размером таблиц и индексов. В результате комплексного подхода — использования атомарных операций на уровне блоков с Copy-on-Write, а также применения hot_standby_feedback — разработчикам удалось создать LSM дерево, работающее внутри Postgres с поддержкой физической и логической консистентности в условиях репликации. Это позволило значительно повысить пропускную способность записи без ущерба надежности и целостности данных.