Индекс-организованное хранение в Pangolin DB Enterprise может заметно ускорить транзакционную нагрузку, но не заменяет классический heap во всех сценариях. Главный выигрыш появляется там, где база часто обновляет строки, накапливает устаревшие версии и упирается в дисковые операции.
В классической таблице PostgreSQL строки лежат в heap, а первичный индекс хранится отдельно. При обновлениях возникают новые версии строк, старые версии остаются до очистки, а VACUUM требует ресурсов. Индекс-организованная таблица размещает актуальные строки непосредственно в листьях B+ дерева по первичному ключу, а предыдущие состояния переносит в UNDO-журнал.
Когда IOT даёт преимущество
В тестах разработчика на конфигурациях с 4-8 ядрами самый заметный прирост получился при дефиците IOPS и синхронной репликации: до 90% TPS в pgbench. На сбалансированной системе результат был скромнее - 15-20% TPS, а в go-tpc/TPC-C - 5-10% tpmC. Это показатели разных тестов, их нельзя объединять в одну шкалу.
Подход особенно интересен для OLTP-систем с большим числом UPDATE и DELETE, где важны предсказуемая задержка, ограничение bloat и снижение объёма WAL. Дополнительный эффект дают блочное сжатие ZSTD и Copy-on-Write для контрольных точек.
Когда heap может быть лучше
Для тяжёлой аналитики и последовательного чтения больших таблиц автор прямо допускает преимущество heap из-за особенностей страничного кеша операционной системы. При массовой вставке экономия места без сжатия также может быть небольшой: размеры двух вариантов хранения оказываются близкими.
Поэтому решение нельзя принимать по одному максимальному числу из теста. Нужен собственный стенд с реальными данными, характерным соотношением чтения и записи, репликацией, резервным копированием и теми же ограничениями дисковой подсистемы, что будут в production.
Как мигрировать безопаснее
Heap и индекс-организованные таблицы могут работать в одной базе. Это позволяет переносить отдельные таблицы и сравнивать результат поэтапно. Для существующих данных разработчик предлагает точечное пересоздание таблицы через Table Access Method API.
Глобально устанавливать новый метод хранения по умолчанию для базы со сторонними расширениями не рекомендуют. Расширения могут рассчитывать на скрытые системные столбцы и особенности heap, что создаёт риск ошибок или замедления.
Практический чек-лист
Сначала выберите одну таблицу с высокой долей обновлений и заметным bloat. Зафиксируйте исходные TPS, задержки, объём WAL, время VACUUM, размер таблицы и реплики. Затем повторите нагрузку на IOT при одинаковом железе и настройках. Отдельно проверьте восстановление, резервные копии, репликацию и совместимость расширений.
Публикация описывает внутренние тесты разработчика, а не независимый бенчмарк. Результаты подтверждают потенциал подхода, но итог для конкретной системы зависит от профиля нагрузки.
Пока никто не ответил. Начните обсуждение.