Strategien zur Reduzierung der Datenbankgröße in PostgreSQL: Ein nutzungsbasierter Ansatz

Datenbankpreismodelle sind schwierig. Als Entwickler, der nach einer verwalteten Datenbank sucht, besteht einer der nervigsten (und doch entscheidendsten) Aspekte des Suchprozesses darin, nicht nur den Vorabpreis der Lösung für Ihre Datenbankgröße zu bewerten, sondern auch, wie die Preisgestaltung funktioniert und wie gut sie skalierbar ist . Zusätzlich zu den Nuancen bei der Bewertung der Datenbankpreise (z. B. „Um wie viel erhöht sich die Rechnung, wenn meine Daten wachsen?“, „Werden mir pro Schreib- oder Lesevorgänge Gebühren berechnet?“ und „Muss ich pro Backup mehr bezahlen?“) ) neigen Entwickler dazu, einen Aspekt zu übersehen: Die Art und Weise, wie das Preismodell einer Datenbank strukturiert ist, hat Einfluss darauf, wie Sie Ihre Daten verwalten und die Größe Ihrer Postgres-Datenbank einschätzen. Unterschiedliche Preismodelle erfordern unterschiedliche Ansätze für die Ausführung von PostgreSQL. Wenn Sie beispielsweise auf eine große Festplatte angewiesen sind, legen Sie möglicherweise keine Priorität auf die Reduzierung Ihrer Datenbankgröße. Wenn Ihnen pro Datenlesevorgang eine Gebühr berechnet wird, denken Sie möglicherweise zweimal über die Ausführung bestimmter Abfragen nach, und wenn Ihnen pro Dateneingang eine Gebühr berechnet wird, sind Sie möglicherweise vorsichtig, was die Häufigkeit und das Volumen neu erfasster Daten angeht. Jedes Preiselement beeinflusst auf subtile Weise die Strategien und Verhaltensweisen, die Sie letztendlich anwenden werden, und drängt Sie zu einer bestimmten Art der Verwaltung und Interaktion mit Ihrer Datenbank, um sowohl Kosteneffizienz als auch optimale Leistung sicherzustellen. , mit tollem Kundenfeedback. In diesem Blogbeitrag untersuchen wir die betrieblichen Vorteile, die wir seit der Umstellung auf dieses Modell bei unseren Kunden beobachtet haben, sowie Taktiken, wie Sie Ihren PostgreSQL-Speicher in einem nutzungsbasierten Modell optimal verwalten. Bei Timescale sind wir vor einigen Monaten auf ein nutzungsbasiertes Speichermodell umgestiegen Nutzungsbasierte Speichermodelle werden in der Datenbankwelt immer beliebter – wer möchte schon für Speicherplatz bezahlen, den er nicht nutzt? Dennoch bleibt ein nutzungsbasiertes Modell nicht ohne Konsequenzen, und Sie müssen einige Best Practices berücksichtigen, um es effektiv zu nutzen. Kurze Zusammenfassung der PostgreSQL-Speichermodelle Um eine gemeinsame Grundlage für unsere Diskussion über die Verwaltung Ihrer Datenbankgröße in einem nutzungsbasierten Modell zu schaffen, beginnen wir damit, kurz zu erläutern, wie die Preisgestaltung auf unserer PostgreSQL-Plattform funktioniert ( ) und wie es im Vergleich zu anderen verwalteten PostgreSQL-Produkten wie Amazon RDS für PostgreSQL und Amazon Aurora abschneidet. Zeitstrahl Ab gestern (💥) bieten wir zwei Arten von Datenbankdiensten in der Timescale-Plattform an: Hier können Entwickler PostgreSQL-Datenbanken mit dynamischer Berechnung erstellen, um Geld zu sparen, ohne die Leistung zu beeinträchtigen. Dynamische PostgreSQL-Dienste Zeitreihendienste, mit denen Entwickler PostgreSQL-Datenbanken erstellen können, die über Hypertabellen, Spaltenkomprimierung usw. zusätzliche Leistung und Skalierbarkeit bieten. und mehrstufiger Speicher. kontinuierliche Aggregate Konzentrieren wir uns darauf, wie wir die Speicherpreise auf unserer Plattform festlegen. Beide Dienste verfügen über ein nutzungsbasiertes Speichermodell, das Folgendes bedeutet: Den Entwicklern wird das von ihnen genutzte Volumen in Rechnung gestellt, ohne Kleingedrucktes – keine Mindestdatenbankgröße, keine Mindestskalierungsschritte. Wenn Sie am Ende des Monats 128 GB verbraucht haben, wird Ihnen dieser Betrag in Rechnung gestellt. Sie können bei 1 GB beginnen und auf TBs erweitern. Es fallen keine Gebühren für geschriebene Daten, Datenübertragungen oder ausgeführte Abfragen an. Beim Erstellen einer Datenbank oder Skalierung muss kein Speicher zugewiesen werden. Die Festplatten müssen nicht manuell verkleinert werden. Um dies deutlich zu machen, erläutern wir die Unterschiede zwischen diesem Modell, Amazon RDS PostgreSQL und Amazon Aurora: Zusammenfassend sind hier die drei wichtigsten Erkenntnisse aus unserem Vergleich: Sowohl Timescale als auch Aurora berechnen die tatsächliche Datenbankgröße. Im Gegensatz dazu erhebt RDS PostgreSQL Gebühren für bereitgestellten Speicher. Sie können die Lautstärke in RDS nicht verkleinern. Timescale erhebt keine Gebühren für geschriebene Daten, Datenübertragungen oder Abfragevorgänge. Sowohl RDS als auch Aurora berechnen pro Datenübertragung zusätzlichen Backup-Speicher und es können zusätzliche I/O-Gebühren anfallen, je nachdem, welche Art von Speicher Sie wählen. Bei Timescale gibt es keine Mindestskalierungsschritte, wohingegen Aurora in 10-GB-Schritten skaliert, nachdem mit 10 GB begonnen wurde. Wie Sie sehen, liegt das Modell von Timescale näher daran , mit dem Unterschied, dass es bei Timescale keine Skalierungsschritte und keine zusätzlichen Gebühren für Dinge wie die Datenübertragung gibt. Im Gegensatz dazu ist RDS eine gute Darstellung des zuteilungsbasierten Modells, auch wenn traditionell bei Datenbankanbietern zu finden, die nach diesem Modell arbeiten. Aurora I/O-optimiert RDS fehlen die „Speicherebenen“ Wie nutzungsbasierte Preise die PostgreSQL-Speicherverwaltung verbessern Wie bereits erwähnt, bedeuten unterschiedliche Preismodelle unterschiedliche Datenbankerfahrungen. Als wir von einem zuteilungsbasierten zu einem nutzungsbasierten Modell übergingen, teilten uns unsere Kunden mit, dass sie sofortige Verbesserungen in drei Betriebsbereichen sahen: Sie mussten beim Starten einer Datenbank keinen Speicher im Voraus bereitstellen, was zu weniger Fehlern bei der Überbereitstellung und damit zu niedrigeren Speicherkosten führte. Bei der Skalierung mussten sie sich keine Gedanken über den Speicher machen. Sie könnten herunterskalieren – wenn sie beispielsweise Daten löschen, zahlen sie nicht mehr dafür. Nutzungsbasierte Modelle beseitigen das Problem der Speicherüberversorgung In herkömmlichen zuteilungsbasierten Modellen stellen Entwickler häufig fest, dass sie ihren Speicherbedarf vorhersagen, was sehr oft zu einer Überbereitstellung des Speichers führt. Wir haben dies in unserer gesamten Flotte beobachtet, als Timescale nach einem nutzungsbasierten Modell operierte: Die Mehrheit unserer Kunden nutzte nicht ihre volle Festplattenkapazität, was bedeutete, dass sie im Wesentlichen für Speicherplatz bezahlten, den sie noch nicht nutzten. Nutzungsbasierte Modelle eliminieren dieses Ratespiel (und die Folgen falscher Vermutungen). Sie müssen bei der Skalierung nicht an den Speicher denken „Durch den nutzungsbasierten Speicher von Timescale muss ich mir keine Gedanken mehr über die Festplattengröße machen. Unsere Lagerkosten sind um 30 % gesunken und ich musste nichts tun!“ Adam McCrea, (Timescale-Kunde) Judoskala Bei nutzungsbasierten Modellen skaliert der Speicher nahtlos mit dem Wachstum Ihrer Datenbank. Eine Hauptstressquelle bei herkömmlichen zuteilungsbasierten Modellen ist die Gefahr, dass der Speicherplatz knapp wird, was im schlimmsten Fall zu zahlreichen Problemen führen kann, die von Anwendungsausfällen und verlorenen Transaktionen bis hin zu Datenbeschädigung reichen. Mit nutzungsbasierten Modellen müssen Entwickler ihren Speicher nicht mehr sorgfältig überwachen, um nicht an eine Speichergrenze zu stoßen. Gleichzeitig müssen sie sich keine Gedanken über umfangreiche Autoscaling-Schritte oder Tier-Sprünge machen. Sie können die Skalierung verkleinern (d. h. nicht mehr für gelöschte Daten zahlen) Nicht zuletzt ermöglichen nutzungsbasierte Modelle ein „Downscale“. Wenn Sie Daten löschen (oder es schaffen, die Größe Ihrer Datenbank erheblich zu reduzieren), zahlen Sie weniger pro Speicher, was nur fair klingt. Wie wir im nächsten Abschnitt sehen werden, verfügt Timescale über einige Funktionen, die Kunden dabei helfen, die Größe ihrer PostgreSQL-Datenbank zu reduzieren. Durch die Einführung eines nutzungsbasierten Modells konnten unsere Kunden sofort Einsparungen bei der Reduzierung der Festplattennutzung erzielen, was ihnen einen Anreiz gab, ihre Datenbank schlank zu halten. So navigieren Sie effektiv durch ein nutzungsbasiertes Modell: Tipps zum Reduzieren der Größe Ihrer Postgres-Datenbank Die gerade genannten Vorteile verbessern das Entwicklererlebnis bei der Arbeit mit Speicher erheblich, weshalb nutzungsbasierte Modelle immer beliebter werden. Die nutzungsbasierte Preisgestaltung hat jedoch eine offensichtliche (aber tiefgreifende) Konsequenz: Sie zwingt Entwickler dazu, gute Datenpraktiken anzuwenden, um die Größe ihrer PostgreSQL-Datenbank so weit wie möglich zu reduzieren. Wenn Sie wissen, dass Ihre Speicherkosten direkt von der tatsächlich verwendeten Festplattengröße abhängen, besteht ein neuer Anreiz, bei der Datenspeicherung umsichtiger vorzugehen. Wenn Sie ein nutzungsbasiertes Speichermodell verwenden, liegt es in Ihrer Verantwortung, sicherzustellen, dass Sie Daten effizient speichern. In gewisser Weise kann dies als „Nachteil“ nutzungsbasierter Modelle angesehen werden und erfordert einige Arbeit – aber das ist eigentlich ein Segen. In herkömmlichen zuteilungsbasierten Modellen kann die Datenhygiene etwas vernachlässigt werden, da die Kosten festgelegt sind: Wenn Sie in RDS an eine 500-GB-Festplatte gebunden sind und Ihre Datenbank 200 GB groß ist, scheint es für Sie keinen großen Anreiz zu geben Machen Sie die Speichernutzung effizient. Aber hier ist die Sache: Bei guten Datenpraktiken geht es nicht nur darum, Geld zu sparen. Um eine PostgreSQL-Datenbank zu skalieren, ist es wichtig, sie optimiert zu halten. Durch die Einführung guter PostgreSQL-Datenverwaltungspraktiken werden Sie nicht nur eine bessere Leistung erzielen, sondern auch Ihr Leben als Datenbankadministrator wird viel einfacher. Lassen Sie uns vor diesem Hintergrund einige Vorgehensweisen durchgehen, die Ihnen dabei helfen, ein nutzungsbasiertes Speichermodell so effektiv wie möglich zu steuern und die Größe Ihrer PostgreSQL-Datenbank systematisch zu reduzieren. Im speziellen Fall von Timescale haben wir einige besonders hilfreiche Funktionen, die wir ebenfalls behandeln werden. Reduzieren Sie die Aufblähung Ihrer PostgreSQL-Datenbank Ein erstes Muss in einem nutzungsbasierten Modell besteht darin, auf die Besonderheiten der Funktionsweise des PostgreSQL-Speichers zu achten, d. h., Sie müssen die Aufblähung regelmäßig reduzieren. Dies hilft Ihnen nicht nur bei der Größe Ihrer Datenbank, sondern auch bei Ihren I/O-Anforderungen. Wir werden Sie in diesem Abschnitt auf einige Grundlagen hinweisen, , und wir haben auch geschrieben . aber dieser HN-Thread hat einige tolle Ratschläge ein Blog-Beitrag zum Aufblähen von Tabellen in PostgreSQL Ein proaktiver Ansatz zur Optimierung des PostgreSQL-Speichers beginnt damit, tote Tupel genau im Auge zu behalten. Wenn tote Tupel nicht aktiviert werden, können sie sich ansammeln und zu unnötigem Speicheraufwand führen. Die Erweiterung kann ein großartiger Verbündeter sein, um zu verstehen, wie Tabellen diese Tupel verwalten. Überwachen Sie tote Tupel. pgstattuple() Um das Aufblähen von Tabellen wirksam zu bekämpfen, sollten Sie Autovacuum so konfigurieren, dass es häufiger ausgeführt wird. Anstatt die Autovacuum-Einstellungen in postgresql.conf global anzupassen, ist es präziser, diese Einstellungen pro Tabelle genau abzustimmen. Dadurch wird der Tatsache Rechnung getragen, dass verschiedene Tabellen unterschiedliche Tendenzen zur Anhäufung toter Tupel haben können. Es ist auch wichtig, lang andauernde Transaktionen zu überwachen, die den Autovacuum-Betrieb behindern könnten. Häufig staubsaugen. Während Autovacuum und Vacuum tote Tupel beheben, erfordert die Rückgewinnung ungenutzter Seiten einen anderen Ansatz. Obwohl VACUUM FULL für diesen Zweck verwendet werden kann, besteht die inhärente Einschränkung, dass die gesamte Tabelle gesperrt wird. kann Ihnen dabei helfen. Fordern Sie ungenutzte Seiten zurück. Pg_repack Nehmen Sie eine Feinabstimmung von PostgreSQL vor Die systematische Reduzierung der Größe Ihrer PostgreSQL-Datenbank hängt eng damit zusammen, dass Sie Ihre PostgreSQL-Datenbank effektiv skalieren können, d. h., dass die Dinge schnell und flexibel bleiben, während Sie immer mehr Daten hinzufügen. Es kann hilfreich sein, einige wichtige PostgreSQL-Parameter im Auge zu behalten (und möglicherweise anzupassen). . Hier sind einige Aspekte, die Sie berücksichtigen müssen: In diesem Artikel werden die wichtigsten Leistungsparameter besprochen : Steuert den Speicher, der für den Seitencache von PostgreSQL verwendet wird, und ist normalerweise auf 25 % des gesamten RAM des Systems eingestellt. shared_buffers : Legt den pro Vorgang innerhalb einer Abfrage zugewiesenen Speicher fest. In Timescale ist die empfohlene Einstellung . work_mem (25 % of RAM) / max_connections : Legt die maximale Anzahl gleichzeitiger Verbindungen fest, die zur Datenbank zulässig sind. Verbindungspooler können dabei helfen, viele kurzlebige Verbindungen zu verwalten. max_connections : Bestimmt die maximale Anzahl von Worker-Prozessen, die PostgreSQL initiieren kann. Bei Verwendung von Timescale lautet die Formel zum Festlegen dieses Parameters: . max_worker_processes max_worker_processes = 3 + timescaledb.max_background_workers + max_parallel_workers : Gibt die maximale Anzahl von Workern an, die parallele Abfragen unterstützen. Standardmäßig ist dies gleich der Anzahl der verfügbaren CPUs. max_parallel_workers : Bestimmt die maximale Anzahl gleichzeitiger Autovacuum-Prozesse. In Timescale ist der Wert standardmäßig auf 10 eingestellt. autovacuum_max_workers Üben Sie die Indexierungshygiene Durch die regelmäßige Optimierung der Indizes bleibt Ihr PostgreSQL effizient, insbesondere wenn die Datenbank skaliert wird. Während Indizes Ihnen dabei helfen können, die Abfrageleistung zu verbessern, wenn sie sinnvoll eingesetzt werden, können übermäßige Indizes in großen PostgreSQL-Bereitstellungen zu Problemen führen. Die offensichtlichste Folge einer übermäßigen Indizierung ist ein erhöhter Speicherverbrauch, da jeder Index einen separaten Speicher erfordert, der proportional mit der Größe der Tabellen wächst. Dieser Overhead kann größer werden, wenn Tabellen partitioniert werden, wie etwa in den Hypertabellen von Timescale. Unnötige Indizes können auch kontraproduktiv für die Verbesserung Ihrer Schreibvorgänge sein, da jeder neue Dateneintrag oder jede neue Datenänderung gleichzeitige Indexaktualisierungen erfordert, was zu mehr E/A-Vorgängen und möglicherweise zu einer Aufblähung der Tabelle führt. Durch die Überwachung Ihrer Indizes können Sie erkennen, welche nicht mehr verwendet werden, und so die Abläufe schlank halten. Eine Möglichkeit hierfür ist die Verwendung : pg_stat_user_indexes -- Retrieve indexes that might not be used or are infrequently used SELECT schemaname, relname AS table_name, indexrelname AS index_name, idx_scan AS times_used FROM pg_stat_user_indexes WHERE idx_scan = 0 OR idx_scan < some_low_threshold -- replace 'some_low_threshold' with a value that makes sense for your context ORDER BY idx_scan ASC, schemaname, relname; Wenn ein Index in der Spalte „idx_scan“ den Wert 0 hat, bedeutet dies, dass er seit dem letzten Zurücksetzen der Statistiken nicht mehr verwendet wurde, was bedeutet, dass er ein Kandidat für eine Optimierung sein könnte. Durch Festlegen eines niedrigen Schwellenwerts für können Sie auch selten verwendete Indizes identifizieren. idx_scan Verkleinern Sie Ihre großen Tabellen durch Timescale-Komprimierung Eine der herausragenden Funktionen von Timescale ist die native Unterstützung der Spaltenkomprimierung, die den von großen Tabellen verwendeten Speicherplatz drastisch reduzieren kann, ohne die Abfrageleistung zu beeinträchtigen. Die Komprimierung verbessert die Leistung vieler Abfragen. Die Komprimierung von Timescale erfolgt durch die Konvertierung regulärer zeilenbasierter Daten in ein kompakteres Spaltenformat. Dieser Prozess ist besonders effektiv für Zeitreihendaten, bei denen viele Spalten sich wiederholende Werte enthalten können. Wir können beeindruckende Komprimierungsraten (+90 %) erzielen, indem wir je nach Datentyp unterschiedliche Komprimierungsalgorithmen anwenden. Dadurch können Ihre großen Tische um das bis zu 10-fache verkleinert werden. In Timescale wird die Komprimierung tabellenweise über eine zeitbasierte Komprimierungsrichtlinie aktiviert. Dieser Code ermöglicht beispielsweise die Komprimierung in einer bestimmten Hypertabelle und komprimiert automatisch Daten, die älter als zwei Wochen sind: -- Enable compression on the hypertable ALTER TABLE your_hypertable SET ( timescaledb.compress, timescaledb.compress_segmentby = 'some_column' ); -- Set a compression policy to compress data older than two weeks SELECT add_compression_policy('your_hypertable', INTERVAL '2 weeks'); Um mehr über Komprimierung zu erfahren, . Schauen Sie sich unsere Dokumentation an Richten Sie eine Datenverwaltungsstrategie ein: Verschieben Sie ältere Daten auf günstigeren Speicher und löschen Sie die Daten, die Sie nicht mehr benötigen Die vorherigen Taktiken sind sehr hilfreich, um die Größe Ihrer Datenbank zu reduzieren, aber es gibt noch eine weitere Möglichkeit, die Sie in Timescale nutzen können, um Ihren Speicher effektiv zu skalieren: Tiered Storage. Durch die Erstellung einer einfachen Tiering-Richtlinie können Sie ältere, weniger zugängliche Daten in eine bodenlose Objektspeicherschicht verschieben: -- This policy moves all data older than one month to object storage SELECT add_tiering_policy('example', INTERVAL '1 month); Dieser Objektspeicher weist die folgenden Merkmale auf: Der Preis ist niedriger als bei unserem Hochleistungsspeicher, sodass Sie viele TB an Daten für viel weniger Geld speichern können. Es ist unendlich, das heißt, Sie können so viele Daten speichern, wie Sie möchten. Diese mehrstufige Speicherarchitektur ist im Backend von Timescale verankert. Der Objektspeicher ist kein von Ihrer Datenbank getrennter „Bucket“, sondern ein integraler Bestandteil davon. Abfragen greifen transparent auf beide Speicherebenen zu, ohne dass Sie etwas unternehmen müssen – Sie können einfach weiterhin Standard-SQL über dasselbe Schema verwenden. Sobald Ihre Staffelungsrichtlinie festgelegt ist, gibt es nichts mehr zu beachten! Wir empfehlen, Daten auf die kostengünstige Speicherschicht zu verschieben, wenn Ihre Anwendung nicht häufig darauf zugreift, da dies zu Leistungseinbußen führt (der Objektspeicher ist nicht so schnell wie unser regulärer Speicher). Sie können diese Daten jedoch problemlos weiterhin Ad-hoc-Abfragen ausführen (z. B. Abfragen, die für die Benutzererfahrung Ihrer Kunden nicht kritisch sind und für die es nicht auf Spitzenleistung ankommt). Anmerkung des Herausgebers: Wir werden bald spannende Neuigkeiten zum Thema Tiered Storage veröffentlichen. 🎉 Bleiben Sie dran! Timescale bietet nicht nur diese kostengünstige Speicherschicht, sondern erleichtert auch die Einrichtung von Richtlinien zur Datenaufbewahrung, um nicht mehr benötigte Daten zu löschen: -- Set a data retention policy to drop data older than 10 months SELECT add_retention_policy('your_hypertable', INTERVAL '10 months'); Sie können Datenaufbewahrungsrichtlinien wie die oben beschriebene mit kontinuierlichen Aggregaten kombinieren, um Ihr Dataset effektiv herunterzurechnen – z. B. indem Sie die Granularität von einer Sekunde auf eine Minute reduzieren, die Ein-Sekunden-Werte löschen, aber die Ein-Minuten-Aggregate beibehalten. . Lesen Sie diesen Blogbeitrag, um ein Beispiel dafür zu sehen, wie Sie dies tun und Langzeitdaten proaktiv verwalten können Nutzungsbasierte Modelle und das Datenmanagement-Paradigma Während nutzungsbasierte Modelle auf den ersten Blick nichts anderes als eine Preisänderung zu sein scheinen, bewirken sie einen Paradigmenwechsel in der Art und Weise, wie Entwickler über ihre Datenbankgröße denken und wie sie Daten wahrnehmen und verarbeiten. Nutzungsbasierte Modelle fördern eine Kultur der kontinuierlichen Verbesserung, bei der sich der Schwerpunkt von der bloßen Speicherverwaltung auf den Zustand und die Effizienz der Datenbank verlagert. Dies erfordert zunächst etwas Disziplin, aber sobald Sie Ihre Denkweise ändern und einige Techniken erlernen, sind Sie in der besten Position, Ihre PostgreSQL-Datenbank effizient und effektiv zu skalieren. Timescale verfügt über wertvolle Tools, mit denen Sie die Größe Ihrer PostgreSQL-Datenbank systematisch reduzieren können, z. B. Komprimierung, mehrstufige Speicherung und Richtlinien zur Datenaufbewahrung. Dadurch können Sie Ihre PostgreSQL-Datenbanken in einem nutzungsbasierten Modell effektiv skalieren. . Um es selbst zu erleben, melden Sie sich bei Timescale an – Sie können es in den ersten 30 Tagen kostenlos nutzen - Geschrieben von . Carlota Sota Auch hier veröffentlicht.