Ha en flott fredag alle sammen! Det gjenstår stadig mindre tid før kurset starter , så i dag deler vi oversettelsen av et annet nyttig materiale om emnet.
På utviklingsstadiet Det har vært gjort noe imponerende arbeid for å forbedre bordpartisjonering. Skillebord - dette er en funksjon som eksisterte i PostgreSQL ganske lenge, men den eksisterte så å si i hovedsak ikke før versjon 10, hvor den ble en veldig nyttig funksjon. Vi har tidligere uttalt at tabellarv er vår implementering av partisjonering, og dette er sant. Bare denne metoden tvang deg til å gjøre det meste av arbeidet manuelt. For eksempel, hvis du ønsket at tupler skulle settes inn i seksjoner under INSERT, må du konfigurere utløsere for å gjøre dette for deg. Partisjonering gjennom arv var veldig sakte og vanskelig å utvikle tilleggsfunksjonalitet på toppen av.
I PostgreSQL 10 så vi fødselen til "deklarativ partisjonering", en funksjon designet for å løse mange problemer som var uløselige ved å bruke den gamle arvemetoden. Dette førte til et mye kraftigere verktøy som tillot oss å dele data horisontalt!
Funksjonssammenligning
PostgreSQL 11 introduserer et imponerende sett med nye funksjoner som bidrar til å forbedre ytelsen og gjøre partisjonerte tabeller mer transparente for applikasjoner.
1. Bruke begrensende unntak
2. Legger kun til noder
3. Bare for en partisjonert tabell som refererer til en ikke-partisjonert
4. Indekser må inneholde alle nøkkelkolonner i partisjonen
5. Seksjonsbegrensninger på begge sider må samsvare
Производительность
Vi har gode nyheter her også! Ny metode lagt til . Denne nye algoritmen kan bestemme passende seksjoner ved å se på spørringsbetingelsen WHERE. Den forrige algoritmen sjekket på sin side hver seksjon for å finne ut om den kunne oppfylle betingelsen WHERE. Dette resulterte i en ekstra økning i planleggingstid ettersom antall strekninger økte.
I 9.6, med partisjonering via arv, ble ruting av tuples til partisjoner vanligvis gjort ved å skrive en triggerfunksjon som inneholdt en serie IF-setninger for å sette inn tuppelen i riktig partisjon. Disse funksjonene kan være svært trege å utføre. Med deklarativ partisjonering lagt til i versjon 10, fungerer dette mye raskere.
Ved å bruke en partisjonert tabell med 100 partisjoner, kan vi evaluere ytelsen ved å laste 10 millioner rader inn i en tabell med 1 BIGINT-kolonne og 5 INT-kolonner.
Ytelse ved å spørre denne tabellen for å finne én indeksert post og kjøre DML for å manipulere én post (med kun 1 prosessor):
Her kan vi se at ytelsen til hver operasjon har økt betydelig siden PG 9.6. Forespørsler SELECT ser mye bedre ut, spesielt de som er i stand til å ekskludere flere partisjoner under spørringsplanlegging. Dette betyr at planleggeren kan hoppe over mye arbeid som den burde ha gjort før. Det bygges for eksempel ikke lenger stier for unødvendige strekninger.
Konklusjon
Tabellpartisjonering begynner å bli en veldig kraftig funksjon i PostgreSQL. Den lar deg raskt vise data online og ta dem offline uten å vente på at langsomme, massive DML-operasjoner skal fullføres.. Dette betyr også at relaterte data kan lagres sammen, noe som betyr at dataene du trenger kan nås mye mer effektivt. Forbedringene som er gjort i denne versjonen ville ikke vært mulig uten utviklerne, anmelderne og formidlerne som jobbet utrettelig med alle disse funksjonene.
Takk til dem alle! PostgreSQL 11 ser fantastisk ut!
Her er en så kort, men ganske interessant artikkel. Del dine kommentarer og ikke glem å registrere deg for , der kursprogrammet vil bli skissert i detalj.
Kilde: www.habr.com