Voor opties voor kolomcompressie biedt PostgreSQL 14 een nieuwe compressiemethode LZ4. Vergeleken met de bestaande PGLZ-compressiemethode in TOAST, is LZ4-compressie sneller. In dit artikel wordt beschreven hoe u de volledige optie kunt gebruiken en hoe u de prestaties ervan kunt vergelijken met andere compressiealgoritmen.
achtergrond
In PG is de pagina de eenheid voor het opslaan van gegevens, en de standaardwaarde is 8 KB. Over het algemeen mag een rij gegevens niet over pagina's worden opgeslagen. Er zijn echter enkele gegevenstypen met variabele lengte en de opgeslagen gegevens kunnen één pagina van de universiteit overschrijden. Om de volledige beperking te overwinnen, wordt het grote veld gecomprimeerd of opgesplitst in meerdere fysieke rijen. Deze techniek is TOAST:
Als er kolommen met variabele lengte in de tabel staan en de grootte van de rijgegevens groter is dan TOAST_TUPLE_THRESHOLD (standaard 2 KB), wordt TOAST standaard geactiveerd. Eerst worden de gegevens eerst gecomprimeerd; als het na compressie nog steeds te groot is, zal de opslag overlopen. Opgemerkt moet worden dat als de opslagstrategie voor kolommen EXTERN/PLAIN specificeert, compressie wordt verboden.
Vóór PG14 ondersteunt TOAST slechts één compressie-algoritme PGLZ (PG ingebouwd algoritme). Maar andere compressie-algoritmen kunnen sneller zijn dan PGLZ of een hogere compressieverhouding hebben. Er is een nieuwe compressieoptie LZ4-compressie in PG14, een verliesvrij compressie-algoritme dat bekend staat om zijn snelheid. We kunnen dus verwachten dat dit de snelheid van TOAST-compressie en decompressie zal helpen verhogen.
Hoe LZ4 te gebruiken?
Om de LZ4-compressiefunctie te gebruiken, moet u bij het compileren -with-lz4 opgeven en de LZ4-bibliotheek in het besturingssysteem volgen. Het TOAST standaardcompressie-algoritme van de PG-instantie kan worden opgegeven via de GUC-parameter default_toast_compression. Mag in postgresql zijn. Configureer in conf, je kunt ook alleen de huidige verbinding wijzigen via het SET-commando:
postgres＝＃ SET standaard＿toast＿compressie＝lz4；
SET
Specificeer het algoritme voor kolomcompressie bij het maken van een tabel in CREATE TABLE:
We kunnen de opdracht d+ gebruiken om het compressie-algoritme voor alle kolommen te zien. Als de kolom het compressie-algoritme niet ondersteunt of niet specificeert, wordt er een spatie weergegeven in de kolom Compressie. In het bovenstaande voorbeeld ondersteunt de id-kolom het compressie-algoritme niet, gebruikt de kolom col1 PGLZ, gebruikt col2 LZ4 en specificeert col3 het compressie-algoritme niet, dan zal het het standaard compressie-algoritme gebruiken.
U kunt het algoritme voor kolomcompressie wijzigen via ALTER TABLE, maar het moet worden opgemerkt dat het gewijzigde algoritme alleen de invoeggegevens beïnvloedt nadat de volledige opdracht is uitgevoerd.
postgres＝＃ INSERT INTO tbl VALUES (1, herhaal（＇abc＇，1000）， herhaal（＇abc＇，1000），herhaal（＇abc＇，1000））；
INVOEGEN 0 1
postgres＝＃ WIJZIG TABEL tbl WIJZIG KOLOM col1 INSTEL COMPRESSIE lz4；
ALTER TABLE
postgres＝＃ INSERT INTO tbl VALUES (2, herhaal（＇abc＇，1000）， herhaal（＇abc＇，1000），herhaal（＇abc＇，1000））；
INVOEGEN 0 1
postgres＝＃ SELECT ID
postgres－＃ pg＿kolom＿compressie（id） AS compressie＿colid，
postgres－＃ pg＿kolom＿compressie（col1） AS-compressie＿col1，
postgres－＃ pg＿kolom＿compressie（col2） AS-compressie＿col2，
postgres－＃ pg＿kolom＿compressie（col3） AS-compressie＿col3
postgres－＃ VAN tbl；
id ｜ compressie＿colid ｜ compressie＿col1 ｜ compressie＿col2 ｜ compressie＿col3
ik
1 ｜ ｜ pglz ｜ lz4 ｜ lz4
2 ｜ ｜ lz4 ｜ lz4 ｜ lz4
（2 rijen）
U kunt zien dat voor rijen die zijn ingevoegd voordat het compressie-algoritme werd gewijzigd, col1 nog steeds het PGLZ-compressie-algoritme gebruikt, zelfs als het compressie-algoritme wordt gewijzigd van PGLZ naar LZ4. (Dus welk algoritme moet worden gebruikt voor decompressie na wijziging?)
Houd er rekening mee dat als u gegevens uit een andere tabel scant en deze in deze tabel invoegt, zoals CREATE TABLE. . . ALS. . . Of INVOEGEN. . . SELECTEER. . . , Het compressiealgoritme dat door de ingevoegde gegevens wordt gebruikt, gebruikt nog steeds de compressiemethode van de originele gegevens. pg_dump en pg_dumpall hebben ook de optie-geen-toast-compuression toegevoegd. Nadat de volledige optie is gebruikt, wordt de TOAST-compressieoptie niet gedumpt.
Prestatievergelijking
De compressiesnelheid en compressiesnelheid van LZ4 en PGLZ getest. En de testresultaten van niet-gecomprimeerde gegevens toegevoegd (de opgegeven opslagstrategie is EXTERN). Voor ongecomprimeerde gegevens is er geen tijdrovende compressie en decompressie, maar de tijd om gegevens te lezen en te schrijven zal toenemen.
Gegevens gebruikt in de test: PG-documenten (één HTML-bestand per gegevensregel); gegevens geleverd door SilesiaCorpus, inclusief HTML, tekst, broncode, uitvoerbare binaire bestanden en afbeeldingen
Gebruik van testmachineIntel? Xeon? Zilver 4210 CPU ＠2．20GHz met 10 cores／20 threads／2 sockets。
Gebruik pgbench om de uitvoeringstijd van het SQL-statement te testen, en pg_table_size om de table university te controleren (voer VACUUM FULL uit voor elke uitvoering om de invloed van dode records te elimineren).
Compressieverhouding
De compressiesnelheden van PGLZ en LZ4 zijn beide afhankelijk van herhaalde gegevens. Hoe meer herhaalde tupels, hoe hoger de compressiesnelheid. Als PG een dergelijke compressiesnelheid echter als niet goed beoordeelt, wordt compressie niet uitgevoerd, zelfs als de gegevensgrootte de drempel bereikt. Omdat compressie niet efficiënt schijfruimte bespaart, brengt het ook extra tijd en bronnenverbruik voor decompressievergrendelingen met zich mee.
In de huidige PG14 vereist PGLZ een compressieverhouding van minimaal 25%, terwijl LZ alleen kleiner is dan bij ongecomprimeerde gegevens. Ik vergeleek de afmetingen van LZ4, PGLZ-tabellen en niet-gecomprimeerde tabellen. Het is te zien dat in de meeste scenario's de compressieverhouding van PGLZ iets beter is, de compressieverhouding wordt geëvalueerd als 2.23 en de compressieverhouding van LZ4 2.07 is. Dit betekent dat PGLZ 7% schijfruimte kan besparen.
Afbeelding 1 Tabelgroottes vergelijken （in KB）
Compressie/decompressie snelheid
TOAST-gegevens worden gecomprimeerd en gedecomprimeerd tijdens het invoegen en opvragen. Daarom heb ik enkele SQL-instructies uitgevoerd om de impact van verschillende compressie-algoritmen te zien.
Vergelijk eerst de prestaties van de INSERT-instructie wanneer u LZ, PGLZ gebruikt en geen compressie gebruikt. Het is duidelijk dat LZ4, vergeleken met niet-gecomprimeerde gegevens, iets meer tijd kost, en PGLZ meer tijd. De compressietijd van LZ4 is gemiddeld 20% korter dan die van PGLZ. Dit is een zeer aanzienlijke verbetering.
Afbeelding 2 － INSERT-prestaties vergelijken
Vergelijk SELECT hieronder. Vergeleken met PGLZ kan LZ4 20% tijd besparen, en er is niet veel verschil met ongecomprimeerde gegevens. De kosten van decompressie zijn tot een zeer laag niveau teruggebracht.
Afbeelding 3 SELECT-prestaties vergelijken
Vergelijk de gelijktijdige INSERT-instructies van 16 clients. Vergeleken met PGLZ zijn de compressieprestaties van enkele grote bestanden (HTML, Engelse tekst, broncode, binaire uitvoerbare bestanden, afbeeldingen) met LZ4 60% -70% sneller. Voeg meerdere kleine bestanden (PG-bestanden) toe, de prestaties worden niet verbeterd. Vergeleken met ongecomprimeerde data is er een enorme verbetering. Er wordt aangenomen dat het gebruik van compressie de hoeveelheid gegevens die naar de schijf wordt geschreven, vermindert.
Afbeelding 4 INSERT-prestaties vergelijken met 16 clients
Met 16 client SELECT's presteert LZ4 in de meeste scenario's beter dan PGLZ:
Afbeelding 5 SELECT-prestaties vergelijken met 16 clients
Het vergelijkt ook de snelheid van tekstverwerking met behulp van de tekenreeksfuncties SELECT en UPDATE. LZ4 is beter dan PGLZ in de hele scène. Vergeleken met de niet-gecomprimeerde gegevens hebben de gegevens van het LZ4-compressiealgoritme vrijwel dezelfde functieverwerkingssnelheid, en heeft het LZ4-algoritme nauwelijks invloed op de bewerkingssnelheid van de string.
Afbeelding 6 － Prestaties vergelijken met stringfuncties
In vergelijking met PGLZ comprimeert en decomprimeert LZ4 TOAST-gegevens efficiënter en levert het goede prestaties. Vergeleken met niet-gecomprimeerde gegevens is de querysnelheid bijna hetzelfde, en vergeleken met PGLZ is het invoegen 80% sneller. Natuurlijk is de compressiesnelheid in sommige scenario's niet erg goed, maar als je de uitvoeringssnelheid wilt verhogen, wordt het sterk aanbevolen om het LZ4-algoritme te gebruiken.
Moet ook aandacht besteden aan, moeten overwegen of de gegevens in de tabel geschikt zijn voor compressie. Als de compressieverhouding niet goed is, zal het nog steeds proberen het nummer te comprimeren en dan opgeven. Dit zal resulteren in extraRAMVerspilling van hulpbronnen en grote invloed op de snelheid van het invoegen van gegevens.
toekomst
LZ4 heeft de compressie- en decompressieprestaties van TOAST aanzienlijk verbeterd. Naast LZ4 zijn er nog veel andere compressie-algoritmen zoals Zstandard. Gebruikers die Zstandard ondersteunen, kunnen een betere compressieverhouding krijgen dan PGLZ. LZ4 HC heeft een compressiesnelheid van 98.5% dan de LZ4-decompressie, maar kan de compressiesnelheid aanzienlijk verhogen. Ik hoop dat de toekomstige versie van PG meer compressie-algoritmen kan gebruiken.
Naast TOAST moeten ook andere scènes worden gecomprimeerd. Voor zover ik weet, ondersteunt de huidige ontwikkelingsversie al WAL's LZ4-compressie, wat een opwindende functie is.