Ha en bra fredag allihopa! Det återstår allt mindre tid innan kursen startar , så idag delar vi översättningen av ett annat användbart material om ämnet.
På utvecklingsstadiet Det har gjorts en del imponerande arbete för att förbättra tabellpartitioneringen. Skiljebord - det här är en funktion som funnits i PostgreSQL ganska länge, men den existerade så att säga i princip inte förrän version 10, där den blev en mycket användbar funktion. Vi har tidigare sagt att tabellarv är vår implementering av partitionering, och det är sant. Endast denna metod tvingade dig att göra det mesta av arbetet manuellt. Till exempel, om du vill att tuplar ska infogas i sektioner under INSERT, måste du konfigurera triggers för att göra detta åt dig. Partitionering genom arv var mycket långsam och svår att utveckla ytterligare funktionalitet ovanpå.
I PostgreSQL 10 såg vi födelsen av "deklarativ partitionering", en funktion utformad för att lösa många problem som var olösliga med den gamla arvsmetoden. Detta ledde till ett mycket kraftfullare verktyg som gjorde att vi kunde dela data horisontellt!
Funktionsjämförelse
PostgreSQL 11 introducerar en imponerande uppsättning nya funktioner som hjälper till att förbättra prestanda och göra partitionerade tabeller mer transparenta för applikationer.
1. Använda begränsande undantag
2. Lägger endast till noder
3. Endast för en partitionerad tabell som refererar till en icke-partitionerad
4. Index måste innehålla alla nyckelkolumner i partitionen
5. Sektionsbegränsningar på båda sidor måste matcha
Производительность
Vi har goda nyheter här också! Ny metod har lagts till . Denna nya algoritm kan bestämma lämpliga avsnitt genom att titta på frågevillkoret WHERE. Den tidigare algoritmen kontrollerade i sin tur varje avsnitt för att avgöra om det kunde uppfylla villkoret WHERE. Detta resulterade i att planeringstiden ökade ytterligare i takt med att antalet sträckor ökade.
I 9.6, med partitionering via arv, gjordes routning av tupler till partitioner vanligtvis genom att skriva en triggerfunktion som innehöll en serie IF-satser för att infoga tupeln i rätt partition. Dessa funktioner kan vara mycket långsamma att utföra. Med deklarativ partitionering tillagd i version 10 fungerar detta mycket snabbare.
Med hjälp av en partitionerad tabell med 100 partitioner kan vi utvärdera prestandan för att ladda 10 miljoner rader i en tabell med 1 BIGINT-kolumn och 5 INT-kolumner.
Prestanda för att fråga den här tabellen för att hitta en indexerad post och köra DML för att manipulera en post (med endast en processor):
Här kan vi se att prestandan för varje operation har ökat avsevärt sedan PG 9.6. Förfrågningar SELECT ser mycket bättre ut, särskilt de som kan exkludera flera partitioner under frågeplanering. Detta innebär att schemaläggaren kan hoppa över mycket arbete som den borde ha gjort tidigare. Till exempel byggs inte längre stigar för onödiga sträckor.
Slutsats
Tabellpartitionering börjar bli en mycket kraftfull funktion i PostgreSQL. Det låter dig snabbt visa data online och ta den offline utan att vänta på att långsamma, massiva DML-operationer ska slutföras.. Detta innebär också att relaterad data kan lagras tillsammans, vilket innebär att den data du behöver kan nås mycket mer effektivt. Förbättringarna som gjorts i den här versionen hade inte varit möjliga utan utvecklarna, granskarna och anslutningarna som arbetat outtröttligt med alla dessa funktioner.
Tack till dem alla! PostgreSQL 11 ser fantastiskt ut!
Här är en så kort men ganska intressant artikel. Dela dina kommentarer och glöm inte att registrera dig för , inom vilken kursprogrammet kommer att beskrivas i detalj.
Källa: will.com