De ontwikkelaars van OrioleDB hebben de huidige staat van de low-level API geanalyseerd, die wordt gebruikt voor de toegang van extensies tot tabellen en indexen in PostgreSQL (Table/Index Access Method (AM) API), en hebben verbeteringsmogelijkheden voorgesteld. Sinds de introductie van deze API in PostgreSQL 12 hebben ontwikkelaars de mogelijkheid gekregen om alternatieve databasemechanismen te creëren. Ondanks het bestaan van deze API en de bekende beperkingen van de ingebouwde opslagmechanisme, zijn er tot nu toe geen volledig functionele transactionele opslag-engines verschenen die uitsluitend als extensies zijn gerealiseerd.
De meest gevraagde functies voor alternatieve tabelengines in PostgreSQL zijn:
- Alternatieve implementaties van MVCC, bijvoorbeeld opslag op basis van een UNDO-log.
- Index-organized tables, waarbij de index geen optionele aanvulling op de tabel is die de zoekopdrachten versnelt, maar de primaire datastructuur is waarin de gegevens van de tabel worden opgeslagen.
De benodigde wijzigingen in de API Table/Index AM voor de ondersteuning van alternatieve implementaties van MVCC worden besproken met het oog op de OrioleDB-extensie, die is ontwikkeld om de bekende tekortkomingen van de ingebouwde opslagmechanisme van PostgreSQL te verhelpen. Het probleem is dat voor een volledige integratie van OrioleDB met PostgreSQL aanpassingen aan de PostgreSQL-code vereist zijn, wat de implementatie van het project bemoeilijkt en de noodzaak benadrukt voor een modernisering van de huidige API Table AM.
De API Table AM legt niet rechtstreeks een implementatiewijze van MVCC op. De API Table AM en de API Index AM maken echter de volgende veronderstelling: elk TID (Tuple/row Identifier) is ofwel door alle indexen geïndexeerd, of helemaal niet geïndexeerd. Zelfs als de Index AM meerdere verwijzingen naar één TID heeft (bijvoorbeeld GIN), moeten al deze verwijzingen overeenkomen met dezelfde geïndexeerde waarde.
Dit principe is bekritiseerd vanwege de toename van de schrijfbewerkingen (‘write amplification’) – als één geïndexeerd attribuut wordt bijgewerkt, moet elke index in de tabel worden bijgewerkt. Om optimaal gebruik te maken van de voordelen van het UNDO-log of om een andere opslagmethode zonder ‘write amplification’ (bijvoorbeeld de WARM-methode) op te zetten, moet deze veronderstelling worden doorbroken.
De Table AM, gebaseerd op UNDO, die deze veronderstelling niet zal schenden, lijkt op de bestaande HOT-methode (Heap-Only Tuples), met als enige verschil dat oude versies van rijen worden opgeslagen in het UNDO-logboek en niet op dezelfde pagina hoeven te passen. Doch, volgens de auteurs, is dit voordeel niet genoeg om het bestaan van een aparte Table AM te rechtvaardigen.
Praktische beperkingen van de bestaande API:
- Bij het bijwerken van een tabelrij worden de indexen bijgewerkt volgens het principe 'alles of niets'.
- Het ontbreken van de mogelijkheid tot gerichte verwijdering van bepaalde tuples in de API Index AM. Momenteel kunnen tuples massaal uit indexen worden verwijderd met behulp van de methodes ambulkdelete en amvacuumcleanup. Pogingen om gerichte verwijdering via deze API te implementeren zouden leiden tot lage efficiëntie, aangezien de meeste huidige implementaties de hele index moeten doorzoeken. Bovendien staat de API niet toe om aan te geven welke van de tuples, die naar dezelfde TID verwijzen, moeten worden verwijderd. Het kan alleen ze allemaal verwijderen.
- Indexen verwijzen momenteel naar tabelrijen door middel van een blocknummer (32 bits) en een offsetnummer (16 bits). En slechts 11 bits van het offsetnummer kunnen veilig van TID-table naar alle toegangsmethoden van de index worden doorgegeven. Alternatieve implementaties van MVCC kunnen daarbij extra payload samen met TID moeten opslaan. Bijvoorbeeld, in OrioleDB is één of meer bits nodig voor de implementatie van 'delete-marking' indexen of volledige zichtbaarheidinformatie.
Twee manieren zijn voorgesteld om de beperkingen in de praktijk te overwinnen:
Aanpak 1: API Index AM biedt mogelijkheden voor alternatieve implementatie van MVCC.
Terwijl Table AM verantwoordelijk blijft voor alle componenten van MVCC, biedt Index AM de nodige mogelijkheden voor alternatieve implementatie van MVCC, namelijk: het opslaan van gebruikerspayload samen met TID, een methode voor gerichte verwijdering en zelfs een methode voor gerichte update (als TID in de index niet kan worden gewijzigd, kan de gebruikerspayload dat wel). Bovendien, omdat het nodig is om meerdere tuples in de index naar dezelfde TID te laten verwijzen, moeten de API-methodes die bij het doorzoeken van de index worden toegepast ook worden bijgewerkt.
Aanpak 2: Indexen die MVCC ondersteunen.
Een alternatief zou zijn om indexen toe te staan die MVCC ondersteunen. Dit betekent dat de 'executor' (of misschien Table AM) gewoon de methods insert() en delete() aanroept in Index AM, terwijl Index AM de mogelijkheid biedt om te scannen met betrekking tot MVCC. Dit zou het scannen met alleen indexen (index-only) aanzienlijk vereenvoudigen. Zelfs de hele Table AM zou in dat geval een tussenlaag kunnen worden die gegevens in de index opslaat.
In de onderstaande diagram is een voorbeeld weergegeven. De waarde van index 2 wordt bijgewerkt door transactie 11 van waarde 'A' naar waarde 'B'. Daarom is waarde 'A' gemarkeerd als xmax == 11, en waarde 'B' is gemarkeerd als xmin == 11. Op deze manier kan index 2 worden gescand om alleen zichtbare tuples te krijgen volgens MVCC zonder heap-controles. De garbage collection van index 2 kan ook worden uitgevoerd zonder gebruik te maken van de heap.
Bij het implementeren van alle genoemde vernieuwingen in de API van index-accessmethoden, is het onwaarschijnlijk dat het mogelijk zal zijn om alle indexen gelijktijdig aan te passen om alle nieuwe mogelijkheden te ondersteunen. Het is realistischer om verschillende implementaties voor één index-accessmethode toe te staan. Bijvoorbeeld, naast de gebruikelijke B-tree, kan de extensie een alternatieve B-tree implementeren met ondersteuning voor MVCC binnen de index en ondersteuning voor record-identificatoren van variabele lengte.
Daarom wordt voorgesteld om niet alleen de API van Table AM te herzien, maar ook de API van Index AM, die jarenlang trouw heeft gediend voor de PostgreSQL-gemeenschap. Bovendien wordt voorgesteld om Index AM op te splitsen in een logische laag en een implementatielaag. Deze heroverwogen architectuur zal PostgreSQL in staat stellen om verschillende opslagnmodellen te ondersteunen.
Bron: opennet.ru
