Gli sviluppatori di OrioleDB hanno analizzato lo stato attuale dell'API di basso livello utilizzata per l'accesso alle estensioni a tabelle e indici in PostgreSQL (API Table/Index Access Method (AM)) e hanno proposto modi per migliorarlo. Dalla sua introduzione in PostgreSQL 12, questo API ha offerto agli sviluppatori la possibilità di creare meccanismi di archiviazione dei dati alternativi. Tuttavia, nonostante la presenza di questo API e le note limitazioni del meccanismo di archiviazione integrato, non sono ancora apparsi motori di archiviazione transazionali completamente funzionali implementati esclusivamente come estensioni.
Le funzionalità più richieste per i motori di tabella alternativi a PostgreSQL sono:
- Implementazioni MVCC alternative, ad esempio archivi basati su log UNDO.
- Tabelle organizzate per indice, dove l'indice non è un'aggiunta facoltativa alla tabella che accelera le query, ma rappresenta la struttura dati principale in cui sono memorizzati i dati della tabella.
Le modifiche necessarie all'API Table/Index AM per supportare implementazioni alternative di MVCC vengono esaminate alla luce dell'estensione OrioleDB, sviluppata per risolvere i noti difetti del meccanismo di archiviazione integrato di PostgreSQL. Il problema è che per una completa integrazione di OrioleDB con PostgreSQL è necessario apportare modifiche al codice di PostgreSQL, il che complica l'implementazione del progetto e sottolinea la necessità di modernizzare l'attuale API Table AM.
L'API Table AM non impone direttamente un metodo di implementazione del MVCC. Tuttavia, l'API Table AM e l'API Index AM fanno la seguente assunzione: ogni TID (Tuple/row Identifier) è o indicizzato da tutti gli indici, o non è indicizzato affatto. Anche se l'Index AM ha più riferimenti a un singolo TID (ad esempio, GIN), tutti questi riferimenti devono corrispondere a lo stesso valore indicizzato.
Questo principio è stato criticato per l'aumento del numero di operazioni di scrittura ("write amplification"): se un attributo indicizzato viene aggiornato, è necessario aggiornare ogni indice nella tabella. Quando è necessario sfruttare appieno i vantaggi del log UNDO o costruire un altro metodo di archiviazione senza "amplificazione della scrittura" (ad esempio, il metodo WARM), è necessario violare questa assunzione.
La Tabella AM basata su UNDO, che non viola questa assunzione, ricorda il metodo esistente HOT (Heap-Only Tuples), eccetto per il fatto che le versioni precedenti delle righe vengono conservate nel registro UNDO e non devono essere contenute nella stessa pagina. Tuttavia, gli autori ritengono che questo vantaggio non sia sufficiente a giustificare l'esistenza di una Tabella AM separata.
Limitazioni pratiche dell'API esistente:
- Durante l'aggiornamento di una riga della tabella, gli indici vengono aggiornati secondo il principio 'tutto o niente'.
- Mancanza nell'API Index AM della possibilità di eliminazione puntuale di specifici tuple. Attualmente è possibile eliminare tuple dagli indici in modo massiccio tramite i metodi ambulkdelete e amvacuumcleanup. Tentare di implementare un'eliminazione puntuale tramite questa API porterebbe a una bassa efficienza, poiché la maggior parte delle implementazioni attuali deve eseguire una scansione dell'intero indice. Inoltre, l'API non consente di specificare quali delle tuple, che fanno riferimento allo stesso TID, debbano essere eliminate. Può rimuovere solo tutte.
- Attualmente, gli indici fanno riferimento alle righe della tabella in base al numero di blocco (32 bit) e al numero di offset (16 bit). E solo 11 bit del numero di offset possono essere trasmessi in modo sicuro dal TID della tabella a tutti i metodi di accesso all'indice. Pertanto, implementazioni alternative di MVCC potrebbero dover memorizzare un'ulteriore payload insieme al TID. Ad esempio, in OrioleDB è richiesto uno o più bit per implementare indici 'delete-marking' o informazioni complete sulla visibilità.
Sono stati proposti due modi per superare le limitazioni nella pratica:
Approccio 1: L'API Index AM fornisce funzionalità per un'implementazione alternativa di MVCC.
Mentre la Tabella AM continua a rispondere a tutti i componenti di MVCC, l'Index AM fornisce le funzionalità necessarie per un'implementazione alternativa di MVCC, vale a dire: memorizzazione di payload personalizzata insieme al TID, metodo di eliminazione puntuale e persino metodo di aggiornamento puntuale (se il TID nell'indice non può essere modificato, la payload personalizzata sì). Inoltre, poiché è necessario consentire a più tuple dell'indice di fare riferimento allo stesso TID, i metodi API utilizzati nella scansione dell'indice necessitano di un aggiornamento.
Approccio 2: Indici che supportano MVCC.
Un'alternativa sarebbe consentire indici che supportano MVCC. Cioè, l'«executor» (o, possibilmente, il Table AM) chiama semplicemente i metodi insert() e delete() nell'Index AM, mentre l'Index AM fornisce la possibilità di scansione tenendo conto di MVCC. Questo semplificherebbe notevolmente la scansione utilizzando solo indici (index-only). Anche l'intero Table AM potrebbe diventare un livello intermedio che memorizza i dati nell'indice.
Nella diagramma qui sotto è fornito un esempio. Il valore dell'indice 2 viene aggiornato dalla transazione 11, cambiando da «A» a «B». Pertanto, il valore «A» è contrassegnato come xmax == 11, mentre il valore «B» è contrassegnato come xmin == 11. In questo modo, è possibile scansionare l'indice 2 e ottenere solo le tuple visibili in conformità con MVCC senza controlli sul heap. La raccolta di spazzatura dell'indice 2 può essere eseguita anche senza utilizzare il heap.
Con l'introduzione di tutte le innovazioni elencate nell'API dei metodi di accesso agli indici, è poco probabile che si riesca a rifinire contemporaneamente tutti gli indici per supportare tutte le nuove funzionalità. È più realistico consentire diverse implementazioni per un metodo di accesso all'indice. Ad esempio, oltre al normale B-tree, l'estensione potrebbe implementare un B-tree alternativo con supporto MVCC all'interno dell'indice e supporto per identificatori di record di lunghezza arbitraria.
Pertanto, si propone di rivedere non solo l'API del Table AM, ma anche l'API dell'Index AM, che ha servito fedelmente la comunità PostgreSQL per molti anni. Inoltre, si propone di separare l'Index AM in un livello logico e un livello di implementazione. Questa architettura riconsiderata consentirà a PostgreSQL di supportare diversi modelli di archiviazione.
Fonte: opennet.ru
