OrioleDB в Pangolin
Поскольку OrioleDB использует собственную модель организации данных и отличается от стандартного механизма Heap, часть ранее реализованных механизмов СУБД Pangolin была доработана с учетом особенностей нового движка хранения.
Функциональности Pangolin, реализация которых не зависит от особенностей физического хранения данных и механизма табличного доступа, не требуют адаптации для работы с OrioleDB. Их поведение и порядок использования при работе с таблицами OrioleDB соответствуют поведению и порядку использования с таблицами классического движка Heap. Полный список наборов функциональности приведен в разделе «Описание редакций продукта СУБД Pangolin».
Поддержка прозрачного защитного преобразования данных (TDE)
При использовании движка хранения OrioleDB функциональность прозрачного защитного преобразования данных (TDE) поддерживается в полном объеме. Порядок настройки, состав конфигурационных параметров и правила эксплуатации полностью соответствуют реализации для классического движка хранения Heap. Использование OrioleDB не требует выполнения дополнительных действий по настройке или администрированию данной функциональности. Ознакомиться с полной документацией по функциональности можно в разделе «Прозрачное защитное преобразование данных (TDE)».
Архитектура хранения данных OrioleDB расширяет контур прозрачного шифрования данных (TDE) за счет добавления к объектам защиты TDE UNDO-лога. С точки зрения криптографии и управления ключами работа TDE с UNDO-логом унифицирована с обработкой объектов базы данных (для подробностей смотрите раздел «Ключи второго уровня»).
Глобальные индексы в OrioleDB
Особенности реализации
Реализация глобальных индексов для партиционированных таблиц OrioleDB имеет особенности:
- Адресация по первичному ключу. В OrioleDB индексы ссылаются на строки по значению первичного ключа, а не по физическому адресу. Поэтому структура первичного ключа (набор столбцов) должна быть абсолютно одинаковой во всех партициях таблицы. При создании глобального первичного ключа на родительской таблице СУБД автоматически создает точно такие же локальные первичные ключи в каждой из ее партиций.
- По умолчанию — моноиндекс. По умолчанию глобальный индекс в OrioleDB представляет собой независимый моноиндекс. В классической heap-архитектуре глобальный индекс обычно формируется как эпи-индекс — иерархическая структура, где локальные индексы партиций выступают дочерними узлами (сабиндексами) единого дерева. Однако первичные ключи, которые OrioleDB автоматически создает внутри каждой партиции для адресации по ключу, изначально не встраиваются в дерево глобального индекса. В результате сразу после создания такой индекс остается самостоятельным моноиндексом.
- Переход к эпи-индексу. Команды
VACUUM FULL,REINDEX,TRUNCATE,ALTER TABLE ... ATTACH PARTITION, выполненные в отношении партиции или ее индексов, инициируют полную физическую перестройку структуры B-tree. В процессе перестроения локальные первичные ключи интегрируются в глобальную иерархию: их корневые узлы становятся дочерними элементами дерева глобального первичного ключа. По завершении операции индекс приобретает структуру эпи-индекса, аналогично реализации для heap-таблиц.
Требования к методу доступа
Создание партиционированной таблицы
Партиционированные таблицы не наследуют значение default_table_access_method, поэтому при создании партиционированной таблицы в OrioleDB метод доступа следует указывать явно:
CREATE TABLE test (id INT PRIMARY KEY GLOBAL) PARTITION BY RANGE (id) USING orioledb;
Иначе будет выдана ошибка:
ERROR: Global index "test_pkey" cannot be defined for partitioned table "test"
DETAIL: Table "test" has no explicitly set access method
Параметр partitioned_table_inherit_default_am
Для автоматического назначения метода доступа новым партиционированным таблицам установите конфигурационный параметр partitioned_table_inherit_default_am в значение on. При включенном параметре метод доступа будет наследоваться и применяться к секциям автоматически при их создании.
Присоединение партиций
Партицию с другим методом доступа нельзя добавить к партиционированной таблице OrioleDB, у которой есть глобальный индекс. Ограничение действует и для CREATE TABLE ... PARTITION OF, и для ALTER TABLE ... ATTACH PARTITION:
CREATE TABLE test (id INT PRIMARY KEY GLOBAL) PARTITION BY RANGE (id) USING orioledb;
CREATE TABLE test_p0 PARTITION OF test FOR VALUES FROM (0) TO (10) USING heap;
ERROR: cannot attach non-orioledb table "test_p0" as a partition of orioledb table "test" which keeps global index "test_pkey"
DETAIL: Partitions of an OrioleDB partitioned table with global index must use the orioledb access method.
Если глобальных индексов нет, присоединить партицию с другим методом доступа можно — но она заблокирует последующее создание глобального индекса:
CREATE TABLE test (id INT) PARTITION BY RANGE (id) USING orioledb;
CREATE TABLE test_p0 PARTITION OF test FOR VALUES FROM (0) TO (10) USING heap;
ALTER TABLE test ADD PRIMARY KEY (id) GLOBAL;
ERROR: Cannot create global index "test_pkey" for partitioned table "test"
DETAIL: Paritition "test_p0" has different access method
Поддержка защиты данных от привилегированных пользователей
При использовании движка хранения OrioleDB функциональность защиты от привилегированного пользователя поддерживается в полном объеме. Порядок настройки, состав конфигурационных параметров и правила эксплуатации полностью соответствуют реализации для классического движка хранения Heap. Использование OrioleDB не требует выполнения дополнительных действий по настройке или администрированию данной функциональности. Ознакомиться с полной документацией по функциональности можно в разделе «Защита данных от привилегированных пользователей».
При использовании движка хранения OrioleDB необходимо учитывать, что данные, получаемые посредством утилит диагностики, могут быть доступны в открытом виде независимо от состояния данной функциональности. Указанное ограничение распространяется исключительно на доступ к данным с использованием утилит диагностики и не влияет на работу механизма защиты при штатном доступе к данным средствами СУБД, расширений и иных поддерживаемых утилит.
Поддержка команды VACUUM FULL
В СУБД Pangolin для таблиц, использующих движок хранения OrioleDB, обеспечена поддержка команды VACUUM FULL, предназначенной для принудительной очистки отношения от неактуальных (мертвых) строк и реорганизации его физической структуры.
При выполнении команды производится полное перестроение отношения и связанных с ним индексных структур. В новое B-дерево переносятся только актуальные версии строк, тогда как строки, помеченные как удаленные, окончательно исключаются из физического представления данных. В результате выполнения операции освобождается пространство, занимаемое неактуальными строками, и формируется новое компактное представление отношения.
Несмотря на то, что архитектура OrioleDB предусматривает повторное использование пространства, освобождаемого при удалении строк, и его постепенную переупаковку в процессе эксплуатации, поддержка VACUUM FULL позволяет выполнить принудительную полную реорганизацию отношения без ожидания естественного перераспределения данных.
Поддержка 64-битных идентификаторов транзакций (XID)
При использовании движка хранения OrioleDB так же осуществляется поддержка 64-битных идентификаторов транзакций.