{"id":79039,"date":"2020-04-23T19:43:26","date_gmt":"2020-04-23T17:43:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql"},"modified":"2020-04-23T19:43:26","modified_gmt":"2020-04-23T17:43:26","slug":"ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"Wir sparen beim Umgang mit gro\u00dfen Mengen in PostgreSQL.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Im Folgenden, in Ankn\u00fcpfung an das Thema der Erfassung gro\u00dfer Datenstr\u00f6me, das in dem vorhergehenden Artikel \u00fcber Partitionierung behandelt wurde,<\/a><\/noindex>werden wir Methoden untersuchen, mit denen die 'physische' Gr\u00f6\u00dfe der gespeicherten Daten<\/b> in PostgreSQL verringert werden kann und deren Einfluss auf die Serverleistung.<\/p>\n

Es geht um TOAST-Einstellungen und Datenausrichtung.<\/b>Durchschnittlich werden diese Methoden nicht besonders viele Ressourcen sparen, aber sie erfordern keinerlei \u00c4nderungen am Anwendungscode.<\/p>\n

\"Wir
\nAllerdings war unsere Erfahrung in dieser Hinsicht durchaus produktiv, da das Speicherformat nahezu aller Monitoring-Daten in der Regel append-only ist,<\/b> was die geschriebenen Daten betrifft. Und falls Sie interessiert sind, wie man die Datenbank dazu bringen kann, mit einer Geschwindigkeit von 200 MB\/s<\/b> deutlich weniger zu schreiben \u2013 scrollen Sie weiter.
\n<\/a><\/noindex><\/p>\n

Kleine Geheimnisse gro\u00dfer Daten<\/h2>\n

\nIm Rahmen der Aktivit\u00e4ten unseres Services<\/a><\/noindex>, erh\u00e4lt er regelm\u00e4\u00dfig aus den Logs Textpakete.<\/b>.<\/p>\n

Da das SBIS-System,<\/a><\/noindex>dessen Datenbanken wir \u00fcberwachen, ein komplexes Produkt mit komplizierten Datenstrukturen ist, sind die Abfragen zur Erreichung maximaler Leistung<\/b> entsprechend gestaltet. \u00abMultivolumes\u00bb mit komplexer algorithmischer Logik<\/a><\/noindex>. Daher ist das Volumen jeder einzelnen Anfrage oder des resultierenden Ausf\u00fchrungsplans in unserem eingehenden Protokoll \u201eim Durchschnitt\u201c betr\u00e4chtlich gro\u00df.<\/p>\n

Schauen wir uns die Struktur einer der Tabellen an, in die wir \u201erohe\u201c Daten schreiben \u2013 also den originalen Text aus dem Protokolleintrag:<\/p>\n

CREATE TABLE rawdata_orig(\n  pack -- PK\n    uuid NOT NULL\n, recno -- PK\n    smallint NOT NULL\n, dt -- Abschnittsschl\u00fcssel\n    date\n, data -- das Wichtigste\n    text\n, PRIMARY KEY(pack, recno)\n);<\/code><\/pre>\n
\nEine typische solche Tabelle (bereits partitioniert, das ist klar, daher handelt es sich um eine Abschnittsvorlage), wobei der wichtigste Punkt der Text ist. Manchmal recht umfangreich.<\/p>\n
Erinnern wir uns daran, dass die \u201ephysische\u201c Gr\u00f6\u00dfe eines Eintrags in PG nicht mehr als eine Datenseite belegen kann, aber die \u201elogische\u201c Gr\u00f6\u00dfe \u2013 das ist eine ganz andere Sache. Um einen umfassenden Wert in ein Feld (varchar\/text\/bytea) zu speichern, wird die TOAST-Technologie verwendet<\/a><\/noindex>:<\/p>\n
PostgreSQL verwendet eine feste Seitengr\u00f6\u00dfe (in der Regel 8 KB) und l\u00e4sst es nicht zu, dass Tupel mehrere Seiten einnehmen. Daher ist es nicht m\u00f6glich, sehr gro\u00dfe Feldwerte direkt zu speichern. Um dieses Limit zu umgehen, werden gro\u00dfe Feldwerte komprimiert und\/oder in mehrere physische Zeilen aufgeteilt. Dies geschieht unbemerkt f\u00fcr den Benutzer und hat nur geringf\u00fcgige Auswirkungen auf den Gro\u00dfteil des Servercodes. Diese Methode ist bekannt als TOAST \u2026<\/p><\/blockquote>\n
\nTats\u00e4chlich wird f\u00fcr jede Tabelle mit \u201epotenziell gro\u00dfen\u201c Feldern automatisch eine zugeh\u00f6rige Tabelle mit \u201eSchnipseln\u201c<\/a><\/noindex> jeder \u201egro\u00dfen\u201c Datensatzsegmente von 2KB erstellt:<\/p>\n
TOAST(\n  chunk_id\n    integer\n, chunk_seq\n    integer\n, chunk_data\n    bytea\n, PRIMARY KEY(chunk_id, chunk_seq)\n);<\/code><\/pre>\n
\nDas bedeutet, dass wenn wir eine Zeile mit einem \u201egro\u00dfen\u201c Wert schreiben m\u00fcssen, data<\/code>die tats\u00e4chliche Speicherung nicht nur in der Haupttabelle und ihrem PK erfolgt, sondern auch in TOAST und dessen PK. Reduzierung des TOAST-Einflusses<\/b>.<\/p>\n
Die meisten unserer Eintr\u00e4ge sind jedoch nicht so gro\u00df,<\/h4>\n
\nsie sollten in 8KB passen \u2014 wie kann man hier sparen?..<\/b> Hier kommt uns das Attribut<\/p>\n
STORAGE der Spalte der Tabelle zu Hilfe:<\/code><\/a><\/noindex> EXTENDED<\/p>\n
\n