Dezvoltatorii OrioleDB au analizat starea actuală a API-ului de nivel scăzut utilizat pentru accesul extensiilor la tabele și indecși în PostgreSQL (metoda de acces la tabelă/indice AM) și au propus modalități de îmbunătățire. Din momentul apariției acestui API în PostgreSQL 12, dezvoltatorii au avut posibilitatea de a crea mecanisme alternative de stocare a datelor. Cu toate acestea, în ciuda existenței acestui API și a limitărilor cunoscute ale mecanismului de stocare încorporat, nu au apărut până acum motoare de stocare tranzacționale complet funcționale implementate exclusiv sub formă de extensii.
Cele mai solicitate funcții pentru motoarele alternative de tabele PostgreSQL sunt:
- Implementări alternative ale MVCC, de exemplu, stocări bazate pe jurnal UNDO.
- Tabele organizate pe indici, unde indicele nu este o adăugare opțională la tabel care accelerează interogările, ci reprezintă structura principală de date în care sunt stocate datele tabelului.
Schimbările necesare în API-ul Table/Index AM pentru a sprijini implementările alternative ale MVCC sunt discutate având în vedere extensia OrioleDB, dezvoltată pentru a elimina deficiențele cunoscute ale mecanismului de stocare încorporat PostgreSQL. Problema este că pentru integrarea completă a OrioleDB cu PostgreSQL sunt necesare modificări ale codului PostgreSQL, ceea ce complică implementarea proiectului și subliniază necesitatea modernizării actualului API Table AM.
API-ul Table AM nu impune direct o modalitate de implementare a MVCC. Cu toate acestea, API-ul Table AM și API-ul Index AM fac următoarea presupunere: fiecare TID (Identificator de Tuplu/rând) este ori indexat de toate indecșii, ori nu este indexat deloc. Chiar dacă Index AM are mai multe referințe la un TID (de exemplu, GIN), toate aceste referințe trebuie să corespundă aceleași valori indexate.
Acest principiu a fost criticat pentru creșterea numărului de operațiuni de scriere („amplificare a scrierii”) — dacă un atribut indexat este actualizat, este necesară actualizarea fiecărui indice din tabel. Atunci când este necesar să se valorifice pe deplin avantajele jurnalului UNDO sau să se construiască o altă metodă de stocare fără „amplificarea scrierii” (de exemplu, metoda WARM), este nevoie să se încalce această presupunere.
Tabela AM bazată pe UNDO, care nu va încălca această presupunere, se aseamănă cu metoda existentă HOT (Heap-Only Tuples), cu excepția faptului că versiunile vechi ale rândurilor sunt păstrate în jurnalul UNDO și nu trebuie să încapă în aceeași pagină. Totuși, autorii consideră că acest avantaj nu este suficient pentru a justifica existența unei Tabele AM separate.
Limitările practice ale API-ului existent:
- În timpul actualizării rândului din tabel, indexurile sunt actualizate pe principiul „totul sau nimic”.
- Lipsa în API-ul Index AM a posibilității de a șterge punctual anumite tupluri. În prezent, este posibil să ștergi tupluri din indexuri în mod masiv prin metodele ambulkdelete și amvacuumcleanup. Încercarea de a implementa ștergeri punctuale prin acest API ar conduce la o eficiență scăzută, deoarece majoritatea implementărilor curente trebuie să scaneze întregul index. În plus, API-ul nu permite specificarea care dintre tupluri, referitoare la același TID, ar trebui să fie șterse. Acesta poate șterge doar pe toate.
- Indexurile în prezent se referă la rândurile din tabel prin numărul de bloc (32 de biți) și numărul de deplasare (16 biți). Și doar 11 biți din numărul de deplasare pot fi transmis în siguranță din TID-ul tabelului în toate metodele de acces al indexului. În acest context, implementările alternative MVCC ar putea necesita să stocheze o sarcină utilă (payload) suplimentară împreună cu TID. De exemplu, în OrioleDB este necesar un sau mai mulți biți pentru a implementa indexuri „delete-marking” sau informații complete despre vizibilitate.
Au fost propuse două modalități de a depăși limitările în practică:
Abordarea 1: API-ul Index AM oferă funcționalități pentru o implementare alternativă MVCC.
În timp ce Table AM continuă să se ocupe de toate componentele MVCC, Index AM oferă funcționalitățile necesare pentru o implementare alternativă MVCC, și anume: stocarea sarcinii utile (payload) personalizate împreună cu TID, metoda de ștergere punctuală și chiar metoda de actualizare punctuală (dacă TID-ul din index nu poate fi modificat, sarcina utilă personalizată – poate fi). În plus, deoarece trebuie să se permită mai multor tupluri din index să se refere la același TID, metodele API utilizate la scanarea indexului necesită, de asemenea, actualizare.
Abordarea 2: Indexuri care suportă MVCC.
O alternativă ar fi să se permită indecși care suportă MVCC. Asta înseamnă că executorul (sau, posibil, Table AM) pur și simplu apelează metodele insert() și delete() în Index AM, în timp ce Index AM oferă capacitatea de scanare având în vedere MVCC. Acest lucru ar simplifica semnificativ scanarea folosind doar indecșii (index-only). Chiar și întregul Table AM ar putea deveni un strat intermediar, stocând datele în index.
În diagrama de mai jos este un exemplu. Valoarea indexului 2 este actualizată de tranzacția 11 de la valoarea „A” la valoarea „B”. Prin urmare, valoarea „A” este marcată ca xmax == 11, iar valoarea „B” este marcată ca xmin == 11. Astfel, se poate scana indexul 2 și se pot obține doar tupluri vizibile conform MVCC fără verificări pe heap. Colectarea gunoiului pentru indexul 2 poate fi, de asemenea, efectuată fără utilizarea heap-ului.
În cadrul implementării tuturor inovațiilor enumerate în API-ul metodelor de acces pentru indecși, este puțin probabil să se reușească să se finalizeze toate indecșii pentru a suporta toate noile capacități în același timp. Este mai realist să se permită mai multe implementări pentru o metodă de acces index. De exemplu, pe lângă B-tree-ul obișnuit, extensia ar putea implementa un B-tree alternativ cu suport pentru MVCC în interiorul indexului și suport pentru identificatori de înregistrări de lungime arbitrară.
Astfel, se propune revizuirea nu doar a API-ului Table AM, ci și a API-ului Index AM, care a servit comunitatea PostgreSQL cu fidelitate de-a lungul anilor. Mai mult, se sugerează împărțirea Index AM în strat logic și strat de implementare. Această arhitectură reimaginată ar permite PostgreSQL să suporte diferite modele de stocare.
Sursa: opennet.ro
