Разработчиците на OrioleDB анализираха текущото състояние на нискоуровневия API, използван за достъп до разширенията на таблици и индекси в PostgreSQL (Table/Index Access Method (AM) API), и предложиха пътища за подобряване. От момента на появата на подобен API в PostgreSQL 12, разработчиците получиха възможност да създават алтернативни механизми за съхранение на данни. Все пак, въпреки наличието на този API и известните ограничения на вграденото хранилище, все още не са се появили напълно функционални транзакционни хранилища, реализирани единствено под формата на разширения.
Най-търсените функции за алтернативни таблични двигатели на PostgreSQL са:
- Алтернативни реализации на MVCC, например, хранилища на основата на журнал UNDO.
- Индексно организирани таблици, където индексът не е задължително допълнение към таблицата, което ускорява заявките, а представлява основната структура от данни, в която се съхраняват данните на таблицата.
Необходимите промени в API Table/Index AM, за да се поддържат алтернативни реализации на MVCC, се разглеждат с оглед на разширението OrioleDB, разработено за отстраняване на известните недостатъци на вграденото хранилище на PostgreSQL. Проблемът е, че за пълна интеграция на OrioleDB с PostgreSQL са необходими промени в кода на PostgreSQL, което усложнява внедряването на проекта и подчертава необходимостта от модернизация на текущия API Table AM.
API Table AM не налага директно начина на реализация на MVCC. Въпреки това, API Table AM и API Index AM правят следното предположение: всеки TID (Tuple/row Identifier) е индексирован от всички индекси или не е индексирован изобщо. Дори и Index AM да има няколко препратки към един TID (например GIN), всички тези препратки трябва да съответстват на същата индексирована стойност.
Този принцип беше критикуван за увеличаване на броя на операциите по запис («write amplification») — ако се обновява един индексирован атрибут, е необходимо да се обнови всеки индекс в таблицата. При необходимост пълноценно да се използват предимствата на журнала UNDO или да се изгради друг метод за съхранение без «усилване на записа» (например, метод WARM), е нужно да се наруши това предположение.
Table AM, основан на UNDO и не нарушает это предположение, напоминает существующий метод HOT (Heap-Only Tuples). Однако старые версии строк сохраняются в журнале UNDO и не должны помещаться на ту же страницу. Но, по мнению авторов, этого преимущества недостаточно, чтобы оправдать существование отдельного Table AM.
Практически ограничения существующего API:
- При обновлении строки таблицы индексы обновляются по принципу «все или ничего».
- Отсутствие в API Index AM возможности точечного удаления определенных кортежей. В настоящее время кортежи могут быть удалены из индексов массово с помощью методов ambulkdelete и amvacuumcleanup. Попытка реализовать точечное удаление через этот API привела бы к низкой эффективности, поскольку большинство реализаций должны сканировать весь индекс. Кроме того, API не позволяет указать, какие из кортежей, ссылающихся на один и тот же TID, следует удалить. Он может удалить только все.
- Индексы в настоящее время ссылаются на строки таблицы по номеру блока (32 бита) и номеру смещения (16 бит). И только 11 бит номера смещения можно безопасно передать из TID таблицы во все методы доступа индекса. При этом альтернативным реализациям MVCC может потребоваться хранить дополнительную полезную нагрузку (payload) вместе с TID. Например, в OrioleDB требуется один или несколько бит для реализации индексов «delete-marking» или полной информации о видимости.
Предложено два способа преодолеть ограничения на практике:
Подход 1: API Index AM предоставляет возможности для альтернативной реализации MVCC.
В то время как Table AM продолжает отвечать за все компоненты MVCC, Index AM предоставляет необходимые возможности для альтернативной реализации MVCC, а именно: хранение пользовательской полезной нагрузки (payload) вместе с TID, метод точечного удаления и даже метод точечного обновления (если TID в индексе не может быть изменен, пользовательская полезная нагрузка – может). Кроме того, необходима возможность разрешить нескольким кортежам индекса ссылаться на один и тот же TID, поэтому методы API, применяемые при сканировании индекса, также нуждаются в обновлении.
Подход 2: Индексы, поддерживающие MVCC.
Алтернатива би могла да бъде разрешаването на индекси, които поддържат MVCC. Тоест, „изпълнителят“ (или, може би, Table AM) просто извиква методите insert() и delete() в Index AM, докато Index AM предоставя способност за сканиране с оглед на MVCC. Това значително би опростило сканирането, използващо само индекси (index-only). Дори цялото Table AM в такъв случай би могло да стане междинен слой, съхраняващ данни в индекса.
На диаграмата по-долу е даден пример. Стойността на индекс 2 се актуализира от транзакция 11 от стойност „A“ на стойност „B“. Затова стойността „A“ е маркирана като xmax == 11, а стойността „B“ е маркирана като xmin == 11. По този начин е възможно да се сканира индекс 2 и да се извлекат само видимите кортежи в съответствие с MVCC без проверки на купчината (heap). Събирането на боклука на индекс 2 също може да бъде извършено без използване на купчина.
При внедряване на всички изброени новшества в API методите за достъп до индекси, малко вероятно е да успеете да доработите всичките индекси, за да поддържат всички нови функции. По-реалистично е да се разрешат няколко реализация за един метод за достъп до индекс. Например, в допълнение към обикновения B-tree, разширението може да реализира алтернативен B-tree с поддръжка на MVCC в рамките на индекса и поддръжка на идентификатори на записи с произволна дължина.
Така че, се предлага да се преразгледа не само API Table AM, но и API Index AM, който успешно е служил на общността PostgreSQL в продължение на много години. Освен това, се предлага да се раздели Index AM на логически слой и слой на реализация. Тази преосмислена архитектура ще позволи на PostgreSQL да поддържа различни модели на съхранение.
Източник: opennet.ru
