Fijne vrijdag allemaal! Er rest steeds minder tijd voordat de cursus van start gaat , dus vandaag delen we de vertaling van nog een nuttig materiaal over dit onderwerp.
In ontwikkelingsfase Er is indrukwekkend werk verricht om de tabelpartitionering te verbeteren. Tabellen verdelen - dit is een functie die al een hele tijd in PostgreSQL bestond, maar die als het ware pas in versie 10 bestond, waarin het een zeer nuttige functie werd. We hebben eerder gezegd dat tabelovererving onze implementatie van partitionering is, en dat is waar. Alleen deze methode dwong je om het meeste werk handmatig te doen. Als u bijvoorbeeld wilt dat tijdens INSERTs tupels in secties worden ingevoegd, moet u triggers configureren om dit voor u te doen. Partitioneren via overerving was erg traag en het was moeilijk om er extra functionaliteit bovenop te ontwikkelen.
In PostgreSQL 10 zagen we de geboorte van ‘declaratieve partities’, een functie die is ontworpen om veel problemen op te lossen die onoplosbaar waren met de oude overervingsmethode. Dit leidde tot een veel krachtiger hulpmiddel waarmee we gegevens horizontaal konden splitsen!
Functievergelijking
PostgreSQL 11 introduceert een indrukwekkende reeks nieuwe functies die de prestaties helpen verbeteren en gepartitioneerde tabellen transparanter maken voor applicaties.
1. Beperkende uitzonderingen gebruiken
2. Voegt alleen knooppunten toe
3. Alleen voor een gepartitioneerde tabel die verwijst naar een niet-gepartitioneerde tabel
4. Indexen moeten alle sleutelkolommen van de partitie bevatten
5. Sectiebeperkingen aan beide zijden moeten overeenkomen
Производительность
Ook hier hebben wij goed nieuws! Nieuwe methode toegevoegd . Dit nieuwe algoritme kan geschikte secties bepalen door naar de queryvoorwaarde te kijken WHERE. Het vorige algoritme controleerde op zijn beurt elke sectie om te bepalen of deze aan de voorwaarde kon voldoen WHERE. Dit resulteerde in een extra toename van de planningstijd naarmate het aantal secties toenam.
In 9.6, met partitionering via overerving, werd het routeren van tupels naar partities doorgaans gedaan door een triggerfunctie te schrijven die een reeks IF-instructies bevatte om de tupel in de juiste partitie in te voegen. Deze functies kunnen erg langzaam worden uitgevoerd. Nu declaratieve partities in versie 10 zijn toegevoegd, werkt dit veel sneller.
Met behulp van een gepartitioneerde tabel met 100 partities kunnen we de prestaties evalueren van het laden van 10 miljoen rijen in een tabel met 1 BIGINT-kolom en 5 INT-kolommen.
Prestaties van het opvragen van deze tabel om één geïndexeerd record te vinden en DML uit te voeren om één record te manipuleren (met slechts één processor):
Hier kunnen we zien dat de prestaties van elke bewerking aanzienlijk zijn toegenomen sinds PG 9.6. Verzoeken SELECT zien er veel beter uit, vooral degenen die meerdere partities kunnen uitsluiten tijdens de queryplanning. Dit betekent dat de planner veel werk kan overslaan dat hij eerder had moeten doen. Er worden bijvoorbeeld geen paden meer gebouwd voor onnodige secties.
Conclusie
Tabelpartitionering begint een zeer krachtige functie te worden in PostgreSQL. Hiermee kunt u gegevens snel online weergeven en offline zetten zonder te wachten op de voltooiing van langzame, grootschalige DML-bewerkingen.. Dit betekent ook dat gerelateerde gegevens samen kunnen worden opgeslagen, waardoor de gegevens die u nodig heeft veel efficiënter toegankelijk zijn. De verbeteringen die in deze versie zijn aangebracht zouden niet mogelijk zijn geweest zonder de ontwikkelaars, reviewers en committers die onvermoeibaar aan al deze functies hebben gewerkt.
Dank aan hen allemaal! PostgreSQL 11 ziet er fantastisch uit!
Hier is zo'n kort maar best interessant artikel. Deel uw opmerkingen en vergeet u niet aan te melden , waarbinnen het cursusprogramma in detail wordt beschreven.
Bron: www.habr.com