{"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":"Sparen wir ein bisschen bei hohen Volumina in PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Im Zusammenhang mit dem Thema der Aufzeichnung gro\u00dfer Datenmengen, das im vorherigen Artikel \u00fcber Partitionierung angesprochen wurde,<\/a><\/noindex>, betrachten wir hier M\u00f6glichkeiten, wie man die \u201ephysikalische\u201c Gr\u00f6\u00dfe des gespeicherten<\/b> in PostgreSQL verringern kann und ihren Einfluss auf die Serverleistung.<\/p>\n

Es geht um TOAST-Einstellungen und Datenausrichtung.<\/b>Im Durchschnitt erm\u00f6glichen diese Methoden nicht allzu viele Ressourcen zu sparen, jedoch \u2014 ganz ohne Modifizierung des Anwendungscodes.<\/p>\n

\"Sparen
\nUnserer Erfahrung nach war dies in dieser Hinsicht jedoch sehr produktiv, da das Speichersystem nahezu jeder \u00dcberwachung aufgrund seiner Natur gr\u00f6\u00dftenteils append-only ist,<\/b> was die geschriebenen Daten betrifft. Und falls Sie sich fragen, wie man die Datenbank anweisen kann, auf die Festplatte zu schreiben, anstatt 200MB\/s<\/b> um die H\u00e4lfte weniger \u2014 bitte weiterlesen.
\n<\/a><\/noindex><\/p>\n

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

\nIm Rahmen unserer Servicearbeit<\/a><\/noindex>, erh\u00e4lt er regelm\u00e4\u00dfig aus den Protokollen Textpakete.<\/b>.<\/p>\n

Und da die SBIS-Komplexit\u00e4t<\/a><\/noindex>, dessen Datenbanken wir \u00fcberwachen, ein vielschichtiges Produkt mit komplexen Datenstrukturen ist, ergeben sich auch die Anfragen , um eine maximale Leistung zu erzielen,<\/b> als durchaus solche \u201eMultivolumen\u201c mit komplexer algorithmischer Logik.<\/a><\/noindex>So ist auch das Volumen jeder einzelnen Instanz von Anfragen oder des resultierenden Ausf\u00fchrungsplans in den Protokollen, die zu uns gelangen, \u201eim Durchschnitt\u201c ausreichend gro\u00df.<\/p>\n

Schauen wir uns die Struktur einer der Tabellen an, in die wir \u201erohe\u201c Daten schreiben \u2014 das hei\u00dft, direkt den urspr\u00fcnglichen Text aus dem Protokoll:<\/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, selbstverst\u00e4ndlich, daher ist dies ein Abschnitts-Template), in der das Wichtigste der Text ist. Manchmal recht umfangreich.<\/p>\n
Erinnern wir uns daran, dass die \u201ephysikalische\u201c Gr\u00f6\u00dfe eines Eintrags in PG nicht mehr als eine Datenseite einnehmen kann, aber die \u201elogische\u201c Gr\u00f6\u00dfe \u2014 v\u00f6llig anders. Um einen umfangreichen Wert (varchar\/text\/bytea) in einem Feld zu speichern, wird die TOAST-Technologie verwendet.<\/a><\/noindex>:<\/p>\n
PostgreSQL verwendet eine feste Seitengr\u00f6\u00dfe (in der Regel 8 KB) und erlaubt es nicht, dass Tupel mehrere Seiten einnehmen. Daher ist es nicht m\u00f6glich, sehr gro\u00dfe Werte von Feldern direkt zu speichern. Um diese Einschr\u00e4nkung zu \u00fcberwinden, werden gro\u00dfe Werte von Feldern komprimiert und\/oder in mehrere physische Zeilen aufgeteilt. Dies geschieht unsichtbar f\u00fcr den Benutzer und hat nur geringe Auswirkungen auf den Gro\u00dfteil des Servercodes. Diese Methode ist als TOAST bekannt ...<\/p><\/blockquote>\n
\nTats\u00e4chlich wird f\u00fcr jede Tabelle mit \"potenziell gro\u00dfen\" Feldern automatisch eine passende Tabelle mit \"St\u00fcckelungen\"<\/a><\/noindex> jeder \"gro\u00dfen\" Aufzeichnung in Segmente von je 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 hei\u00dft, wenn wir eine Zeile mit einem \"gro\u00dfen\" Wert schreiben m\u00fcssen, data<\/code>, wird die tats\u00e4chliche Speicherung nicht nur in der Haupttabelle und ihrem PK erfolgen, sondern auch in TOAST und ihrem PK.<\/b>.<\/p>\n
TOAST-Einfluss verringern<\/h4>\n
\nAber die meisten Aufzeichnungen sind dennoch nicht allzu gro\u00df, sollten in 8KB passen<\/b> \u2014 wie k\u00f6nnen wir dabei sparen?..<\/p>\n
Hier kommt uns das Attribut STORAGE<\/code><\/a><\/noindex> der Spalte der Tabelle zugute:<\/p>\n
\n