OrioleDB: Движок хранения нового поколения для PostgreSQL

примечание

Эта страница переведена при помощи нейросети GigaChat.

OrioleDB — это расширение для хранения данных в PostgreSQL, использующее систему подключаемых движков хранения PostgreSQL.

Разработан как прямая замена существующего движка хранения PostgreSQL. OrioleDB создан с использованием преимуществ современного оборудования и облачной инфраструктуры, обеспечивая более высокую производительность и масштабируемость для рабочих нагрузок PostgreSQL.

Пример

OrioleDB использует механизм доступа к таблицам PostgreSQL (TAM) для предоставления подключаемого движка хранения для PostgreSQL. Ниже приведен пример создания таблицы с использованием OrioleDB:

-- Включение расширения OrioleDB
CREATE EXTENSION orioledb;

CREATE TABLE blog_post
(
  id int8 NOT NULL,
  title text NOT NULL,
  body text NOT NULL,
  PRIMARY KEY(id)
) USING orioledb; -- Использование движка хранения OrioleDB

Подключаемое хранение в PostgreSQL

Подключаемое хранение предоставляет возможность использования различных движков хранения для разных таблиц в пределах одной базы данных. Разработчики могут выбрать метод хранения, оптимизированный под конкретные потребности: некоторые таблицы могут быть настроены для высоких транзакционных нагрузок, другие — для аналитических рабочих нагрузок, а остальные — для архивирования.

Примеры:

create table analytics_data
(
  id int8,
  created_at timestamptz,
  event text
) using parquet; -- Хранение данных в движке, оптимизированном для аналитики

create table timeseries_data
(
  id int8,
  created_at timestamptz,
  event text
) using timeseries; -- Хранение данных в движке, оптимизированном для временных рядов

Аналогичная возможность уже реализована в MySQL, где начиная с версии 5.5 в качестве движка хранения по умолчанию используется InnoDB (вместо MyISAM). Подробнее об истории подключаемого хранения читайте по ссылке.

Использование OrioleDB с существующими установками PostgreSQL

В настоящее время OrioleDB требует набора патчей для PostgreSQL, расширяющих API подключаемого хранения и другие подсистемы PostgreSQL. Все эти патчи отправлены в сообщество PostgreSQL и находятся на рассмотрении.

Важным свойством данного набора патчей является сохранение бинарной совместимости. То есть, можно перейти на патченную бинарную версию PostgreSQL, сохранив тот же каталог данных. Существующие таблицы продолжат работу с движком heap по умолчанию, пока их не перевести на использование orioledb. Кроме того, возможен обратный переход к использованию оригинальных (непатченных) бинарных версий PostgreSQL. Для этого необходимо предварительно преобразовать таблицы orioledb обратно в кучу.

Цель — перевести все в основной репозиторий (upstream): после принятия данных патчей OrioleDB сможет работать на любой установке PostgreSQL без каких-либо модификаций. Это также позволит всему сообществу PostgreSQL создавать собственные подключаемые движки хранения.

До этого момента можно воспользоваться готовым образом Docker для тестирования OrioleDB. Образ Docker содержит патченную версию PostgreSQL с предварительно установленным OrioleDB. Для начала работы следуйте руководству «Быстрый старт».

Набор патчей

Полный набор патчей доступен по ссылке.

Следующие патчи отправлены в сообщество PostgreSQL для расширения интерфейса TAM и других подсистем:

	Название	Ссылка	Версия
✅	Добавление недостающих поисков неравенства в rbtree	Ссылка	PostgreSQL 16
✅	Документирование возможности указания TableAM для pgbench	Ссылка	PostgreSQL 16
✅	Удаление функции Tuplesortstate.copytup	Ссылка	PostgreSQL 16
✅	Добавление новой функции Tuplesortstate.removeabbrev	Ссылка	PostgreSQL 16
✅	Перенос логики аббревиатур в puttuple_common()	Ссылка	PostgreSQL 16
✅	Перенос управления памятью из writetup() и tuplesort_put*()	Ссылка	PostgreSQL 16
✅	Разделение TuplesortPublic и Tuplesortstate	Ссылка	PostgreSQL 16
✅	Разделение tuplesortvariants.c и tuplesort.c	Ссылка	PostgreSQL 16
✅	Исправление опечатки в комментарии к функции writetuple()	Ссылка	PostgreSQL 16
✅	Поддержка пользовательских слотов в пользовательских узлах исполнителя	Ссылка	PostgreSQL 16
✉️	Разрешить table AM хранить сложные структуры данных в rd_amcache	Ссылка	PostgreSQL 18
✉️	Разрешить методу tuple_insert() table AM возвращать другой слот	Ссылка	PostgreSQL 18
✉️	Добавление метода TupleTableSlotOps.is_current_xact_tuple()	Ссылка	PostgreSQL 18
✉️	Разрешить блокировку обновленных кортежей в tuple_update() и tuple_delete()	Ссылка	PostgreSQL 18
✉️	Добавление теста изоляции delete returning EvalPlanQual	Ссылка	PostgreSQL 18
✉️	Обобщение анализа отношений в интерфейсе table AM	Ссылка	PostgreSQL 18
✉️	Пользовательские reloptions для table AM	Ссылка	PostgreSQL 18
✉️	Разрешить методам вставки table AM управлять вставкой индексов	Ссылка	PostgreSQL 18

✅ — Патч принят.

✉️ — Патч отправлен и находится на рассмотрении сообществом PostgreSQL.

Возможности

OrioleDB открывает путь к будущему с более мощными моделями хранения, оптимизированными для облачных сред и современных архитектур оборудования.

Открытый исходный код

OrioleDB распространяется под стандартной лицензией PostgreSQL. Цель — перевести все патчи, необходимые для работы OrioleDB, в основной репозиторий PostgreSQL, чтобы расширение могло работать на любой установке PostgreSQL без каких-либо модификаций.

Создан для современного оборудования

Архитектура OrioleDB избегает узких мест устаревших процессоров на современных серверах с десятками и сотнями ядер CPU, обеспечивая оптимизированное использование современных технологий хранения, таких как SSD и NVRAM.

Снижение требований к обслуживанию

OrioleDB реализует концепции журнала отката (undo) и page-mergins, что исключает необходимость в специализированных процессах сборки мусора. Кроме того, OrioleDB реализует 64-битные идентификаторы транзакций по умолчанию, тем самым устранив широко известную проблему переполнения (wraparound).

Создан для распределенной работы

OrioleDB реализует WAL на уровне строк с поддержкой параллельного применения. Данная архитектура журнала оптимизирована для репликации на основе протокола консенсуса RAFT, что позволяет реализовать активную мультимастер-репликацию (active-active multimaster).

Отличительные особенности

Ключевые технические отличия OrioleDB.

Отсутствие маппинга буферов и бесстопорное чтение страниц

In-memory страницы в OrioleDB связаны прямыми ссылками со страницами хранения. Это исключает необходимость маппинга в буфере и связанных с этим узких мест. Кроме того, в OrioleDB чтение in-memory страниц не включает атомарные операции. В совокупности данные архитектурные решения поднимают вертикальную масштабируемость PostgreSQL на совершенно новый уровень.

MVCC на основе концепции журнала отката (undo)

В OrioleDB старые версии кортежей не вызывают разрастание (bloat) в основной системе хранения, а вытесняются в журнал отката (undo), образуя цепи отката. Записи отката на уровне страниц позволяют системе быстро освобождать пространство, занимаемое удаленными кортежами. В совокупности с page-mergins данные механизмы устраняют разрастание в большинстве случаев. Специализированная очистка таблиц с помощью VACUUM также не требуется, что устраняет значимую и распространенную причину деградации производительности системы и отказов баз данных.

Контрольные точки copy-on-write и WAL на уровне строк

OrioleDB использует контрольные точки copy-on-write, что обеспечивает структурно согласованный снимок данных в любой момент времени. Данный подход оптимален для современных SSD и позволяет вести журнал WAL на уровне строк. В свою очередь, логирование WAL на уровне строк легко параллелизуется (реализовано), компактно и подходит для активной мультимастер-репликации (планируется).