Разработчиците на OrioleDB предложиха подобрения на API за алтернативни двигатели на PostgreSQL

Разработчиците на 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), е необходимо да се наруши това предположение.

Таблица AM, основанная на UNDO, не нарушает это предположение и напоминает существующий метод HOT (Heap-Only Tuples), за исключением того, что старые версии строк сохраняются в журнале UNDO и не должны помещаться на ту же страницу. Однако, по мнению авторов, этого преимущества недостаточно, чтобы оправдать существование отдельной Таблицы AM.

Практические ограничения существующего API:

• По време на актуализацията на реда в таблицата индексите се актуализират по принципа „всичко или нищо“.
• Отсутствие в API Index AM возможности точечного удаления определённых кортежей. В настоящее время можно удалять кортежи из индексов массово с помощью методов ambulkdelete и amvacuumcleanup. Попытка реализовать точечное удаление через этот API привела бы к низкой эффективности, поскольку большинство текущих реализаций должны сканировать весь индекс. Кроме того, API не позволяет указать, какие из кортежей, ссылающихся на один и тот же TID, следует удалить. Он может удалить только их все.
• Индексите в момента сочат към редовете на таблицата по номер на блока (32 бита) и номер наoffset (16 бита). И само 11 бита на номера за offset могат безопасно да се предадат от 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. Тоест „executor“ (или, възможно, 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