Die Skalierung von PostgreSQL-Datenbanken ist jetzt noch günstiger: Der mehrstufige Speicher von Timescale ist jetzt allgemein verfügbar

Produkte wie Amazon RDS für PostgreSQL eignen sich gut für kleinere Bereitstellungen, aber die Skalierung von PostgreSQL ist eine andere Sache. Sobald das Projekt auf viele Terabyte anwächst, werden diese verwalteten Datenbanken langsam und teuer, was die Datenverwaltung deutlich komplexer macht.

Die Leistung leidet, sobald Tabellen Milliarden von Zeilen erreichen und währenddessen Es gibt Möglichkeiten, es zu verbessern , die Daten werden weiter wachsen. Ohne ordnungsgemäße Datenverwaltung können Entwickler nur zusehen, wie ihre Festplatten (und Rechnungen) immer größer werden.

Aber nicht mehr. Wir freuen uns, heute die allgemeine Verfügbarkeit von Tiered Storage bekannt zu geben, einer mehrschichtigen Speicherarchitektur, die entwickelt wurde, um eine unbegrenzte, kostengünstige Skalierbarkeit für Ihre Zeitreihen- und Analysedatenbanken in der Timescale-Plattform zu ermöglichen. Sie können Ihre älteren, selten abgerufenen Daten jetzt in einer kostengünstigen Speicherebene speichern und trotzdem darauf zugreifen – ohne jemals Einbußen bei der Leistung Ihrer häufig abgerufenen Daten hinnehmen zu müssen.

Folgendes passiert, wenn Sie mit unserem neuen mehrschichtigen Speicher-Backend Daten in eine Timescale-Zeitreihendatenbank einfügen:

1. Ihre aktuellsten Daten werden in eine leistungsstarke Speicherebene geschrieben, die für schnelle Abfragen und hohe Aufnahmemengen optimiert ist.

   
   

2. Wenn Sie nicht häufig auf diese Daten zugreifen, können Sie sie durch die Einrichtung einer Tiering-Richtlinie automatisch auf eine kostengünstigere Objektspeicherschicht umstellen. Die Daten in der kostengünstigen Speicherebene bleiben vollständig in Ihrer Datenbank abfragbar und es gibt keine Begrenzung für die Datenmenge, die Sie speichern können – bis zu Hunderten von TB oder mehr. Unsere kostengünstige Speicherstufe hat einen Pauschalpreis von 0,021 $ pro GB/Monat für Daten – günstiger als Amazon S3.

Entwickler benötigen eine kostengünstige Möglichkeit, ihre großen PostgreSQL-Datenbanken in AWS zu skalieren, ohne die Leistung zu beeinträchtigen. Obwohl Objektspeicher erstaunlich skalierbar und erschwinglich sind, sind sie nicht die schnellsten, und Entwickler müssen außerdem Abfrageantworten im Millisekundenbereich für ihre Anwendungen erhalten.

Wenn Daten jedoch älter werden und seltener darauf zugegriffen wird, ist die Echtzeitleistung oft nicht mehr so wichtig. Entwickler müssen für Ad-hoc-Abfragen, Datenanalysen oder die Einhaltung gesetzlicher Vorschriften weiterhin auf diese historischen Daten zugreifen können, können jedoch bei dieser Art von Abfragen mit einer gewissen Latenz rechnen. Was Entwickler nun wollen, ist die Möglichkeit, diese historischen Daten so kostengünstig und effizient wie möglich zu speichern.

Diese neue Tiered-Storage-Architektur befreit Entwickler von der Wahl zwischen Speicherkosten und Leistungskompromissen für Echtzeitanwendungen. Indem sie ihre aktuellen und häufig aufgerufenen Daten in der Hochleistungsebene aufbewahren, nutzen sie die Millisekunden-Abfragegeschwindigkeit und die Aufnahmefunktionen von Timescale. Durch die Tierierung ihrer älteren Daten können sie so viele TBs behalten, wie sie in ihren PostgreSQL-Datenbanken benötigen weniger.

PostgreSQL-Datenverwaltung mit mehrstufigem Speicher: Was Sie wissen müssen

Die Tiered-Storage-Architektur von Timescale nutzt die Flexibilität von PostgreSQL und Hypertabellen für ein effektives Datenmanagement. Beim Erstellen eines Hypertables kann dieser nun nahtlos über beide Speicherebenen ausgedehnt werden; wenn Sie eine Abfrage ausführen Timescale ermittelt nahtlos, auf welche Speicherebenen zugegriffen werden muss, um die Antwort zu generieren, wodurch die Leistung Ihrer neuesten Daten gesteigert und die Speicherkosten für ältere Daten gesenkt werden. Es fallen keine zusätzlichen Kosten pro Abfrage oder Datenlesevorgang und keine versteckten Gebühren an, was eine unkomplizierte und kostengünstige Datenverwaltung ermöglicht.

Diese Speicherarchitektur eliminiert auch jegliche Speicherbeschränkungen in Timescale-Diensten: Da unsere kostengünstige Speicherebene unbegrenzt ist, können Sie so viele TB speichern, wie Sie möchten. Zum Beispiel, Wir nutzen Tiered Storage intern, um die riesige Timescale-Datenbank zu speichern, die unserem Insights-Produkt zugrunde liegt.

Diese Insights-Datenbank sammelt und analysiert ständig Abfragestatistiken aus unserer gesamten Kundenflotte. Sie hat heute mehr als 350 TB und wächst schnell. Von diesen 350 TB werden 250 TB auf kostengünstigen Speicher verteilt.

Lassen Sie uns rechnen:

• Nach der Komprimierung speichern wir 5 TB in unserem Hochleistungsspeicher. Natürlich haben wir die Komprimierung aktiviert und erhalten Komprimierungsraten von 20x – was bedeutet, dass die ursprünglich 100 TB Postgres-Daten dank der Komprimierung (!) jetzt auf eine 5-TB-Festplatte passen.

  
  

• Die restlichen 250 TB Daten werden in der kostengünstigen Speicherebene gespeichert. Diese Einstufung erfolgt automatisch, sobald die Daten ein bestimmtes Alter erreichen, das derzeit mehrere Wochen alt ist.

  
  

Auch unsere Kunden mit großen Einsätzen nutzen bereits Tiered Storage:

„Wir führen viele Analysen von Marktdaten durch, und die schiere Datenmenge, die wir speichern müssen, macht eine normale festplattenbasierte Datenbanklösung undurchführbar (sie ist einfach zu teuer). Mit dem Tiered Storage von Timescale können wir große Datenmengen nahtlos dorthin verschieben.“ die Objektspeicherschicht. Dies ist eine großartige Lösung, um große Mengen historischer Daten zu speichern und eine Nachanalyse durchzuführen. Ohne dies wären wir gezwungen, eine Lösung intern zu entwickeln.“

- Chief Technology Officer bei einem proprietären Handelsunternehmen für digitale Vermögenswerte

Einfachheit ist das Hauptmerkmal von Tiered Storage. Um Ihre Daten von der Hochleistungsschicht auf die kostengünstige Objektschicht zu verschieben, müssen Sie lediglich unsere verwenden einfache API um Richtlinien zu definieren, um Ihre Daten mit zunehmendem Alter auf einer bestimmten Hypertabelle zu schichten. Daten-Tiering-Richtlinien funktionieren auf Blockbasis (die Richtlinie ordnet vollständige Blöcke zu, sobald sie das in der Richtlinie definierte Alter erreichen). Es sind keine ETL-Prozesse (Extract-Transform-Load) oder Infrastrukturänderungen erforderlich.

Diese Richtlinie würde beispielsweise alle Daten, die älter als einen Monat sind, in den Objektspeicher in Ihrer events Hypertabelle verschieben:

 SELECT add_tiering_policy('events', INTERVAL '1 month');

Das ist alles was Sie brauchen! Alles andere geschieht automatisch, einschließlich der intelligenten Abfrageplanung, die alle SQL-Abfragen nur auf der entsprechenden Ebene ausführt.

Um Daten, die derzeit in der kostengünstigen Speicherebene gespeichert sind, zu löschen, können Sie eine Datenaufbewahrungsrichtlinie definieren, sodass Daten nach einem bestimmten Zeitraum (z. B. nach fünf Jahren) automatisch gelöscht werden. Sie können bestimmte Chunks auch manuell löschen .

Auch wenn Sie einen bestimmten Teil von der kostengünstigen Speicherebene auf die Hochleistungsebene „zurückverschieben“ möchten ( zum Beispiel, wenn Sie Daten auffüllen oder aktualisieren müssen ), können Sie es ganz einfach „auftrennen“.

 -- Untier a particular chunk CALL untier_chunk('_hyper_1_1_chunk');

Sie können in der Timescale-Konsole verfolgen, wie viele Daten gestaffelt wurden (und wie viel sie am Ende des Monats kosten werden):

Apropos Abrechnungsschätzungen …

Wie viel kann ich mit Tiered Storage sparen?

Unsere Hochleistungsspeicherstufe hat einen effektiven Preis von 0,177 $ pro GB/Monat Daten nach der Komprimierung (unter Berücksichtigung der erwarteten Komprimierungsrate, die wir in unserer gesamten Flotte sehen). Hinzu kommt jetzt eine kostengünstige Speicherschicht mit einer Pauschalgebühr von 0,021 US-Dollar pro GB/Monat Daten, bei gleichem Preis in allen Cloud-Regionen.

Beim Tiering von Daten zahlen Sie nur für die von Ihnen gespeicherten Daten , nicht für die ausgeführten Abfragen oder die gescannte Datenmenge: Dies ist wirklich ein Pauschalpreis. Unser Ziel mit dieser Preisstruktur war es, eine transparente, eindeutige und einfache Möglichkeit zur Berechnung der Gesamtkosten für die Datenspeicherung bereitzustellen und so die Verwaltung Ihrer Daten zu erleichtern.

Nehmen wir als kurzes Beispiel an, Sie haben eine Hypertabelle mit 5,2 TB Speicher, wobei aktuelle Hypertabellenblöcke und andere Postgres-Tabellen etwa 200 GB beanspruchen und etwa 5 TB Hypertabellendaten, die älter als einen Monat sind. Sie greifen nicht häufig auf diese älteren Daten zu oder fragen diese nicht ab, sodass Sie sie nicht für den täglichen Betrieb Ihrer Anwendung benötigen. Dennoch möchten Sie, dass es in Ihrer Datenbank für Ad-hoc-Anfragen oder Compliance-Anforderungen zugänglich bleibt (wir sehen bei unseren Kunden viele solcher Fälle).

Als kostengünstige Datenverwaltungsstrategie können Sie alle Datenblöcke, die älter als einen Monat sind, auf die kostengünstige Stufe umstellen und so die Kosten für die Speicherung dieser 5 TB Daten von etwa 478 US-Dollar pro Monat auf etwa 105 US-Dollar pro Monat senken, was einer Reduzierung um 78 % entspricht in Ihrer Lagerrechnung. ( Für diese Schätzung gehen wir davon aus, dass Sie die Komprimierung für Ihre Hypertabelle aktiviert haben, und berücksichtigen die mittlere Gesamtkomprimierung in allen Timescale-Diensten.)

Die Einsparungen steigen zusammen mit Ihren Daten: Wenn Sie mehrere Terabyte auf diese kostengünstige Stufe verschieben, sinken Ihre Speicherrechnungen von Tausenden von Dollar auf einige Hundert. Die folgende Referenztabelle verdeutlicht, wie erschwinglich unsere Low-Cost-Speicherstufe tatsächlich ist.

Du verstehst, worauf es ankommt!

Der Multiplikationseffekt der Einsparungen durch Tiered Storage

Es gibt noch etwas, das Tiered Storage noch erstaunlicher macht: Wenn Sie Daten in der kostengünstigen Speicherebene aufbewahren, zahlen Sie für diese Daten nur einmal, unabhängig davon, ob in Ihrem Dienst ein Hochverfügbarkeitsreplikat oder Lesereplikate ausgeführt werden .

Gleiches gilt für Gabeln. In Timescale können Sie durch Klicken auf eine Schaltfläche auf der Benutzeroberfläche Kopien Ihrer Primärdatenbank (wir nennen sie Forks) erstellen, um beispielsweise Tests auszuführen oder Entwicklungsumgebungen zu erstellen. Wenn Sie einen (oder mehrere) Forks erstellen, werden Ihnen die Daten, die mit dem primären Fork im kostengünstigen Speicher geteilt werden, nicht in Rechnung gestellt . Wenn Sie sich dazu entschließen, mehr Daten, die nicht in der primären Ebene enthalten sind, zu schichten, zahlen Sie für die Speicherung in der kostengünstigen Ebene, profitieren aber dennoch von erheblichen Einsparungen, wenn Sie sie von der Hochleistungsebene der Abzweigung auf die günstigere Ebene verschieben .

Um dies klar zu verdeutlichen, führen wir ein Beispiel durch. Stellen Sie sich vor, Sie haben einen primären Dienst mit 6,5 TB Daten und haben außerdem Folgendes festgelegt:

• Ein hochverfügbares Replikat, um das Risiko von Ausfallzeiten und Datenverlusten aufgrund von Ausfällen deutlich zu reduzieren

  
  

• Eine Lesereplikat, das Ihre Leseabfragen bedient und es der Primärdatenbank ermöglicht, sich vollständig den Schreibvorgängen zu widmen

  
  

• Ein Zweig dieses Dienstes für Entwicklungs- und Testzwecke

  
  

Aus Abrechnungssicht: Wenn Sie die 6,5 TB an Daten in Ihrem primären Dienst in der Hochleistungsspeicherebene behalten würden, würden Sie [6,5 TB x 4] in Ihrer Speicherrechnung sehen, um die beiden Replikate, den Fork und zu berücksichtigen der primäre Dienst – insgesamt 26 TB. Unter der Annahme unserer durchschnittlichen Komprimierungsrate wäre dies kostspielig: etwa 4.602 $/Monat.

Aber was passiert, wenn Ihre Anwendung nur auf die letzten 500 GB an Daten aktiv zugreifen muss? Sie könnten 6 TB auf kostengünstigen Speicher verteilen und nur 500 GB auf Ihrer Hochleistungsspeicherstufe behalten. Und da Sie für die Daten in Ihrer kostengünstigen Speicherstufe nur einmal bezahlen, sieht Ihre neue Speicherrechnung so aus:

• [500 GB x 4] = 2 TB im Hochleistungsspeicher (statt 26 TB)

  
  

• [6 TB x 1] in der kostengünstigen Speicherstufe

  
  

Die oben genannte Speicherrechnung würde sich auf etwa 480 $/Monat belaufen: Sie würden über 4.000 $/Monat sparen! Dies ist der Multiplikationseffekt der Einsparungen durch Tiered Storage. Insbesondere wenn Sie Replikate oder Forks betreiben, ist es eine gute Idee, die kostengünstige Speicherstufe zu nutzen – die Einsparungen, die Sie in Ihrer Gesamtrechnung sehen, werden sehr erheblich sein.

Unsere mehrstufige Speicherreise

Im März haben wir eine frühe Version unserer Tiered-Storage-Funktionalität auf der Timescale-Plattform als Early Access veröffentlicht. Nach vielen Verbesserungen ist es nun allgemein verfügbar. Seit der ersten Veröffentlichung haben wir hart daran gearbeitet, Tiered Storage stabil, zuverlässig und schneller zu machen.

Wir haben auch lange und gründlich über unser Preismodell nachgedacht und konsequent mehrere Möglichkeiten zur Preisgestaltung unserer kostengünstigen Speicherstufe durchlaufen. Schließlich haben wir uns für das Einfachste entschieden: eine Flatrate über das Datenvolumen vor der Komprimierung. Wir haben bereits erwähnt, dass wir Wert auf eine einfache und vorhersehbare Preisgestaltung legen, es war uns aber auch wichtig, einen möglichst niedrigen Preis pro GB/Monat anzubieten. Unser Preis lag bei 0,021 US-Dollar – zum Vergleich: Das Speichern von Dateien auf Amazon S3 kostet 0,023 $ pro GB/Monat .

Persönlich muss ich (Yannis) zugeben, dass ich, nachdem ich mehr als ein Jahrzehnt lang Teams geleitet habe, die Cloud-native Lösungen entwickeln, immer noch zurückgehen und gelegentlich mehrere Tariftabellen auf verschiedenen Cloud-Preisseiten erneut überprüfen muss, insbesondere auf der Suche nach zusätzlichen Gebühren, jedes Mal Ich möchte die Gesamtkosten für unsere Dienstleistungen genau berechnen.

Wir bei Timescale glauben, dass Sie keine komplizierte Tabelle erstellen müssen, um einen Datenbankdienst auszuführen oder fundierte Entscheidungen über Speicherebenen zu treffen.

Unser Engagement, das Leben von Entwicklern einfacher zu machen, hat uns zum Pauschalpreis von 0,021 $ pro GB/Monat geführt – ohne Vermutungen, versteckte Kosten oder Gebühren pro Abfrage oder Datenlesevorgang.

So funktioniert Tiered Storage: Hinter den Kulissen

Alle in Timescale eingefügten Daten werden zunächst in unsere Hochleistungsspeicherschicht geschrieben. Die Verwendung schnellerer Festplatten für Ihre aktuellsten Daten sorgt für eine erstklassige Einfüge- und Abfrageleistung für Ihre aktuellsten Werte, ein Nutzungsmuster, das den Anforderungen datenintensiver Anwendungen gerecht wird.

Im Gegensatz dazu handelt es sich bei der kostengünstigen Speicherebene um einen Objektspeicher, der auf Amazon S3 basiert. Dieser Objektspeicher ist jedoch viel mehr als ein externer Bucket zum Archivieren Ihrer Daten: Er ist ein integraler Bestandteil Ihrer Datenbank. Wenn Sie Daten auf diese Objektspeicherebene verschieben, behält Ihre Datenbank alle Semantiken und Metadaten vollständig im Auge und Sie können weiterhin wie gewohnt mit Standard-SQL Abfragen durchführen (allerdings mit langsamerer Leistung).

Hinter den Kulissen speichern wir die Daten in einem komprimierten Spaltenformat (insbesondere Apache Parquet ). Wenn Daten gestaffelt sind, werden Blöcke im nativen internen Datenbankformat von Timescale (normalerweise in unserem) gespeichert native Spaltenkomprimierung ) werden asynchron in das Parquet-Format konvertiert und im zugrunde liegenden S3-Objekt gespeichert. Wir haben mehrere Mechanismen entwickelt, um sicherzustellen, dass die abgestuften Blöcke dauerhaft in der kostengünstigen Speicherebene gespeichert werden, bevor sie transaktional aus der Hochleistungsebene entfernt werden.

Wenn Sie Ihre SQL-Abfrage ausführen, werden Daten je nach Bedarf transparent aus der Hochleistungsspeicherschicht, der Objektspeicherschicht oder beiden abgerufen. Wenn wir transparent sagen, meinen wir transparent: Timescale unterstützt beliebig komplexe Abfragen über seine Standard- und Tiered-Daten hinweg, einschließlich komplexer Prädikate, JOINs, CTEs, Windowing, Hyperfunktionen und mehr.

In der folgenden Beispielabfrage (mit einer EXPLAIN Klausel) können Sie sehen, wie der Abfrageplan einen Foreign Scan umfasst, wenn die Datenbank auf Daten aus der Objektspeicherebene zugreift. In diesem Beispiel handelt es sich devices und sites um Standard-Postgres-Tabellen (die sich nur im Hochleistungsspeicher befinden), während es sich metrics um eine Hypertabelle handelt, die sich über beide Speicherebenen erstreckt. Bei der Ausführung dieser Abfrage für die metrics Hypertabelle wurden drei ihrer Blöcke aus dem Standardspeicher und fünf Blöcke aus dem Objektspeicher gelesen.

 EXPLAIN SELECT time_bucket('1 day', ts) as day, max(value) as max_reading, device_id FROM metrics JOIN devices ON metrics.device_id = devices.id JOIN sites ON devices.site_id = sites.id WHERE sites.name = 'DC-1b' GROUP BY day, device_id ORDER BY day; QUERY PLAN ---------------------------------------------------------- GroupAggregate Group Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Sort Sort Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Hash Join Hash Cond: (_hyper_5666_706386_chunk.device_id = devices.id) -> Append -> Seq Scan on _hyper_5666_706386_chunk -> Seq Scan on _hyper_5666_706387_chunk -> Seq Scan on _hyper_5666_706388_chunk -> Foreign Scan on osm_chunk_3334 -> Hash -> Hash Join Hash Cond: (devices.site_id = sites.id) -> Seq Scan on devices -> Hash -> Seq Scan on sites Filter: (name = 'DC-1b'::text)

Im obigen Abfrageplan entspricht der Foreign Scan on osm_chunk_3334 dem Abrufen von Daten aus der bodenlosen Objektspeicherebene.

Um zu vermeiden, dass Blöcke verarbeitet werden, die außerhalb des Zeitfensters der Abfrage liegen, führen wir einen Blockausschluss durch, um nur die Blöcke zu bearbeiten, die zur Erfüllung der Abfrage erforderlich sind. Die Datenbank speichert verschiedene Formen von Metadaten, um eine „Karte“ von Zeilengruppen und Spaltenoffsets innerhalb der Objektspeicherung zu erstellen.

Darüber hinaus werden bei der Ausführung einer Abfrage die gelesenen Daten noch selektiver ausgewählt. Wenn Ihre Abfrage nur einen Bereich von Zeilen und ein paar Spalten berührt, wird nur diese Teilmenge der Daten aus dem S3-Objekt hinter der kostengünstigen Speicherebene gelesen.

Im obigen Beispiel werden nur die Spalten device_id und value aus der Objektspeicherschicht gelesen. Wenn ein zusätzlicher zeitbasierter WHERE -Filter enthalten wäre, würde die Datenbank zunächst ihre Metadaten (im Hochleistungsspeicher gespeichert und im Arbeitsspeicher zwischengespeichert) verwenden, um weiter zu reduzieren, welche Parquet-Dateien und Zeilengruppen zum Ausführen der Abfrage gelesen werden müssen. Alles, um die Abfragelatenz zu reduzieren, selbst wenn transparent über PostgreSQL auf diesen grenzenlosen Speicher zugegriffen wird.

Probieren Sie Tiered Storage aus

Speicherentscheidungen für historische Daten müssen nicht kostspielig sein. Mit Timescale haben Sie jetzt Zugriff auf eine kostengünstige, unbegrenzte Speicherstufe ohne Preisprobleme, mit der Sie Ihren Datenbankspeicher zu einem erschwinglichen Preis skalieren können, ohne die Leistung Ihrer Anwendung zu beeinträchtigen.

Wenn Sie sich fragen, ob dies eine gute Lösung für Ihren Anwendungsfall ist, Weitere Informationen und passende Anwendungsfälle finden Sie in unseren Dokumenten. Wenn Sie eine praktischere Perspektive suchen, können Sie auch damit experimentieren Tiered Storage selbst kostenlos in der Timescale-Plattform über unsere kostenlose Testversion (keine Kreditkarte erforderlich) .

– Geschrieben von Yannis Roussos, Carlota Soto und Ana Tavares.