Programiści OrioleDB przeanalizowali aktualny stan niskopoziomowego API wykorzystywanego do dostępu rozszerzeń do tabel i indeksów w PostgreSQL (Table/Index Access Method (AM) API) i zaproponowali możliwości jego poprawy. Od momentu wprowadzenia tego API w PostgreSQL 12, programiści zyskali możliwość tworzenia alternatywnych mechanizmów przechowywania danych. Niemniej jednak, mimo istnienia tego API i znanych ograniczeń wbudowanego mechanizmu przechowywania, nadal nie pojawiły się w pełni funkcjonalne transakcyjne silniki przechowywania, zrealizowane wyłącznie w formie rozszerzeń.
Najbardziej pożądanymi funkcjami dla alternatywnych silników tabelowych PostgreSQL są:
- Alternatywne implementacje MVCC, na przykład magazyny oparte na dzienniku UNDO.
- Tabele zorganizowane według indeksów, gdzie indeks nie jest opcjonalnym dodatkiem do tabeli, który przyspiesza zapytania, lecz stanowi podstawową strukturę danych, w której przechowywane są dane tabeli.
Zmiany, które są konieczne w API Table/Index AM, aby wspierać alternatywne implementacje MVCC, są rozważane w kontekście rozszerzenia OrioleDB, opracowanego w celu usunięcia znanych wad wbudowanego mechanizmu przechowywania PostgreSQL. Problem polega na tym, że pełna integracja OrioleDB z PostgreSQL wymaga zmian w kodzie PostgreSQL, co utrudnia wdrożenie projektu i podkreśla potrzebę modernizacji obecnego API Table AM.
API Table AM nie narzuca bezpośrednio sposobu implementacji MVCC. Niemniej jednak, API Table AM i API Index AM zakładają, że każdy TID (Tuple/row Identifier) jest albo indeksowany przez wszystkie indeksy, albo w ogóle nie jest indeksowany. Nawet jeśli Index AM ma kilka odniesień do jednego TID (na przykład GIN), wszystkie te odniesienia muszą odpowiadać temu samemu indeksowanemu wartości.
Krytykowano tę zasadę za zwiększenie liczby operacji zapisu („wzmacnianie zapisu”) — jeśli aktualizowany jest jeden atrybut indeksowany, konieczne jest zaktualizowanie każdego indeksu w tabeli. Aby w pełni wykorzystać zalety dziennika UNDO lub zbudować inną metodę przechowywania bez „wzmacniania zapisu” (na przykład metodę WARM), konieczne jest naruszenie tego założenia.
Tabela AM oparta na UNDO, która nie narusza tego założenia, przypomina istniejącą metodę HOT (Heap-Only Tuples), z wyjątkiem tego, że stare wersje wierszy są przechowywane w dzienniku UNDO i nie muszą mieścić się na tej samej stronie. Jednak, według autorów, ta korzyść nie jest wystarczająca, aby uzasadnić istnienie osobnej Tabeli AM.
Praktyczne ograniczenia istniejącego API:
- Podczas aktualizacji wierszy tabeli indeksy są aktualizowane zasada „wszystko lub nic”.
- Brak w API Index AM możliwości punktowego usuwania określonych krotek. Obecnie można masowo usuwać krotki z indeksów za pomocą metod ambulkdelete i amvacuumcleanup. Próba wdrożenia punktowego usuwania przez to API prowadziłaby do niskiej wydajności, ponieważ większość obecnych realizacji musi skanować cały indeks. Ponadto API nie pozwala określić, które z krotek odnoszących się do tego samego TID należy usunąć. Może usunąć tylko wszystkie.
- Indeksy obecnie odwołują się do wierszy tabeli według numeru bloku (32 bity) i numeru offsetu (16 bitów). I tylko 11 bitów numeru offsetu można bezpiecznie przekazać z TID tabeli do wszystkich metod dostępu do indeksu. Przy tym alternatywne realizacje MVCC mogą wymagać przechowywania dodatkowego ładunku (payload) razem z TID. Na przykład w OrioleDB potrzebny jest jeden lub więcej bitów do wdrożenia indeksów „delete-marking” lub pełnych informacji o widoczności.
Proponowane są dwa sposoby na pokonanie ograniczeń w praktyce:
Podejście 1: API Index AM zapewnia możliwości dla alternatywnej realizacji MVCC.
Podczas gdy Table AM nadal odpowiada za wszystkie komponenty MVCC, Index AM zapewnia niezbędne możliwości dla alternatywnej realizacji MVCC, a mianowicie: przechowywanie użytkowego ładunku (payload) razem z TID, metodę punktowego usuwania, a nawet metodę punktowej aktualizacji (jeśli TID w indeksie nie może być zmieniony, użytkowy ładunek – może). Oprócz tego, ponieważ konieczne jest umożliwienie wielu krotkom indeksu odniesienia do tego samego TID, metody API stosowane podczas skanowania indeksu także potrzebują aktualizacji.
Podejście 2: Indeksy wspierające MVCC.
Alternatywą byłoby umożliwienie indeksów wspierających MVCC. To znaczy, że „executor” (lub, być może, Table AM) po prostu wywołuje metody insert() i delete() w Index AM, podczas gdy Index AM zapewnia możliwość skanowania zgodnie z MVCC. To znacznie uprościłoby skanowanie z wykorzystaniem tylko indeksów (index-only). Nawet cały Table AM w takim przypadku mógłby stać się warstwą pośrednią, przechowując dane w indeksie.
Na poniższym diagramie przedstawiony jest przykład. Wartość indeksu 2 jest aktualizowana przez transakcję 11 z wartości „A” na wartość „B”. Dlatego wartość „A” jest oznaczona jako xmax == 11, a wartość „B” jako xmin == 11. W ten sposób można skanować indeks 2 i uzyskiwać tylko widoczne krotki zgodnie z MVCC bez sprawdzania kupy (heap). Zbieranie śmieci indeksu 2 również może być wykonane bez używania kupy.
Przy wdrażaniu wszystkich wymienionych nowości w API metod dostępu do indeksów, mało prawdopodobne jest, aby udało się jednocześnie dostosować wszystkie indeksy do wsparcia wszystkich nowych możliwości. Realistyczniej byłoby zezwolić na kilka implementacji dla jednej metody dostępu indeksu. Na przykład, oprócz zwykłego B-drzewa, rozszerzenie mogłoby wdrożyć alternatywne B-drzewo z obsługą MVCC w indeksie i wsparciem dla identyfikatorów rekordów o dowolnej długości.
W związku z tym proponuje się rewizję nie tylko API Table AM, ale także API Index AM, które rzetelnie służyło społeczności PostgreSQL przez wiele lat. Co więcej, proponuje się rozdzielenie Index AM na warstwę logiczną i warstwę implementacyjną. Ta przemyślana architektura pozwoli PostgreSQL wspierać różne modele przechowywania.
Źródło: opennet.ru
