Heute starten,  .   Sie können dynamische PostgreSQL-Datenbanken auf Timescale erstellen  Dynamic   ist die natürliche Weiterentwicklung von Cloud-Datenbanken und löst die Probleme sowohl bereitgestellter Datenbanken als auch serverloser Datenbanken. Es wird durch Dynamic Computing unterstützt, eine Timescale-Innovation, die Ihre verfügbare Rechenleistung innerhalb eines vordefinierten Min/Max-Bereichs entsprechend Ihrer Auslastung sofort skaliert. Anstatt für Ihre Spitzenlast bereitzustellen (und ständig dafür zu bezahlen), können Sie jetzt einen Rechenbereich auswählen: Ihre Datenbank arbeitet mit der Basiskapazität und greift nur bei Bedarf sofort auf die Spitzenlast zu. Kaufen Sie die Basis, mieten Sie den Gipfel. PostgreSQL  Dies führt zu einem beispiellosen Preis-Leistungs-Verhältnis: Kunden, die Produktions-Workloads ausführen, sparen 10–20 % bei der Migration von AWS RDS für PostgreSQL und 50–70 % bei der Migration von AWS Aurora Serverless.  Sie können Dynamic PostgreSQL noch heute ausprobieren. Wir bieten eine kostenlose Testversion an – keine Kreditkarte erforderlich – mit der Sie 30 Tage lang vollen Zugriff auf die Plattform haben.  Um einen dynamischen PostgreSQL-Dienst zu erstellen, wählen Sie einfach die PostgreSQL-Option aus, wenn Sie sich bei Timescale anmelden:   Ihre Anwendung ist immer aktiv. Warum sollte das auch bei Ihrer Datenbank nicht der Fall sein?  Willkommen in der Zukunft.  Problem 1: Entwickler stellen weit mehr Rechenleistung bereit, als sie benötigen  In den letzten Jahren, seit wir Timescale zum ersten Mal auf den Markt gebracht haben, haben wir in der ersten Reihe miterlebt, wie Entwickler Datenbanken nutzen. Gerade in den letzten Monaten beispielsweise  als Teil unseres Insights-Produkts.   Wir haben über eine Billion Anfragen analysiert   Wir haben gelernt, dass Entwickler oft weit mehr Rechenleistung bereitstellen, als sie tatsächlich benötigen.  Das macht einerseits Sinn: Sie möchten sich nie um Ihre Datenbank kümmern. Die meisten Datenbank-Workloads sind kontinuierlich, typischerweise mit einer gewissen Variabilität oder Stoßhäufigkeit. Zum Beispiel ein Spiel, das nachts häufiger genutzt wird, eine Geschäftsanwendung, die tagsüber häufiger genutzt wird, oder ein vernetztes Heimgerät, das am Wochenende häufiger genutzt wird als unter der Woche.   Sie möchten nie, dass Ihrer Datenbank die Ressourcen ausgehen. Wenn Ihre Datenbank die maximale Kapazität erreicht, führt das zu einem schrecklichen Kundenerlebnis (oder zu keinem Kundenerlebnis!). Daher stellen die meisten Entwickler letztendlich die Spitzenlast und einen Puffer bereit. Dies führt dazu, dass Entwickler für viel mehr Rechenleistung zahlen, als sie tatsächlich benötigen.  Auf der anderen Seite kommt uns das verrückt vor. Für welche andere Geschäftsressource wären Unternehmen in Ordnung, weit mehr auszugeben, als sie benötigen? Verschwendete Rechenleistung ist gleichbedeutend mit verschwendetem Geld.  Problem 2: Serverlose Datenbanken reichen für Produktions-Workloads nicht aus  Einige von Ihnen fragen sich vielleicht: „Was ist mit serverlosen Datenbanken?“  Das Konzept der Serverlosigkeit entstand mit zustandslosen Workloads. Nach dem Erfolg virtueller Maschinen in der Cloud, bei denen sich Benutzer keine Gedanken mehr über die Hardware machen müssen, fragten sie sich als Nächstes, warum sie sich überhaupt Gedanken über den Betrieb von Anwendungsservern machen sollten. Schließlich wollten viele Benutzer nur Funktionen ausführen und nur für die Ausführungszeit dieser Funktionen Gebühren zahlen. Und es ist einfach und nahtlos, Funktionen nach Bedarf hochzufahren, und zwar fast genau deshalb, weil sie zustandslos sind. Serverlos – und Function-as-a-Service oder FaaS – wurde zum Hit, wobei AWS Lambda die Führung übernahm.  Die Entwickler fragten sich dann: „Warum für meine Datenbank bezahlen, wenn ich sie nicht nutze?“ Die eigentliche Frage ist gut: Verschwendete Ressourcen sind ein massives Datenbankproblem. Und die Praxis, eine AWS RDS-Datenbank auf einer bestimmten Serverinstanz (z. B. db.m6gd.2xlarge) bereitzustellen, fühlt sich sicherlich weder modern noch flexibel an: feste CPU, fester Arbeitsspeicher, feste lokale Festplatte. Das meiste davon wird die meiste Zeit nicht ausreichend genutzt.  Doch hier wird es knifflig: Datenbanken unterscheiden sich stark von Lambda-Funktionen.   Heutzutage sind serverlose Datenbanken für die meisten Produktions-Workloads aus zwei Hauptgründen falsch:  Serverlose Datenbanken konzentrieren sich auf die Extreme der Skalierung nach oben und unten, sogar auf Null.  Serverlose Datenbanken führen zu viel höheren Preisen, um den „Spielraum“ der Ressourcen zu berücksichtigen, der für die Bedienung sich ändernder Anforderungen reserviert ist (und schlimmer noch, oft mit Preismodellen, die schwer zu verstehen oder vorherzusagen sind).  Beginnen wir mit der Diskussion des aktuellen Themas „Skalierung auf Null“. Die Realität ist, dass die meisten Produktionsdatenbanken keine Skalierung auf Null benötigen und auch nicht wirklich davon profitieren.  Nun gibt es einige Anwendungsfälle, in denen eine „Skalierung auf Null“ sinnvoll ist. Zum Beispiel Proof-of-Concept-Demos oder eher Hobby-Anwendungen. Die Möglichkeit, gelegentlich eine Ad-hoc-Abfrage für Ihren Datensatz auszuführen (AWS Athena und Google BigQuery sind ein starkes Argument für ein kostengünstiges, serverloses Cloud-Data-Warehouse für die sehr zeitweilige Nutzung). Ein weiterer geeigneter Anwendungsfall wäre, zu vermeiden, dass man vergisst, eine Cloud-Entwicklungsinstanz herunterzufahren, sobald sie fertig ist – es ist sinnvoll, eine Nicht-Produktionsdatenbank „automatisch anzuhalten“ (obwohl dies eine viel einfachere Funktionalität erfordert, als bei Serverless vorgesehen).   Aber für Ihre Produktionsdatenbank und in eher betrieblichen Umgebungen? Sie möchten nicht auf Null skalieren.  Eine Skalierung auf Null bedeutet einen „Kaltstart“ beim Neustart: leere gemeinsame Datenbankpuffer, leerer Betriebssystem-Cache, leere Katalog-Caches (im Fall von PostgreSQL).  (Ja, einige serverlose Datenbanken verkürzen die Zeit, die zum Starten der Datenbank benötigt wird, aber sie tun dies in einem leeren Zustand. In einer relationalen Datenbank wie PostgreSQL kann es Minuten (oder länger!) dauern, bis wieder ein warmer Arbeitssatz erstellt ist. insbesondere für größere Datenbanken.)  Der Leistungseinbruch beim Kaltstart ist noch größer, da viele serverlose Datenbanken unterschiedliche Cloud-Speicherarchitekturen verwenden, bei denen die Kosten und die Latenz beim Abrufen von Datenbankseiten vom Remote-Speicher in den Speicher noch höher sind. Dieser Overhead führt wiederum zu schlechterer Leistung oder zwingt Plattformanbieter dazu, dies durch den Einsatz größerer physischer Ressourcen auszugleichen (z. B. haben Amazon Aurora-Datenbanken doppelt so viel Speicher wie RDS), ein Kostenfaktor, der letztendlich an die Benutzer weitergegeben wird.  Daher führen serverlose Datenbanken in vielen Szenarien zu höheren und unvorhersehbaren Preisen.  Wenn Sie beispielsweise Aurora Serverless mit Amazon RDS vergleichen, werden Sie feststellen, dass 8 vCPU-Rechenleistung und 500 GB Speicher bei Serverless 85 % teurer sind als RDS (1.097 $ gegenüber 593 $). Und zwar mithilfe von Aurora I/O Optimized und seinen vorhersehbareren Speicherpreisen, die erst vor sechs Monaten eingeführt wurden. (Allerdings müssen wir auch hier immer noch auf die tatsächliche Rechenkapazität schließen, da die Preise für Aurora Serverless durch die Verwechslung undurchsichtiger „Aurora-Kapazitätseinheiten“ ermittelt werden, die nach unseren besten Schätzungen 1 ACU = 0,25 vCPU sind.)    Wir werden in Kürze einen vollständigen Benchmark veröffentlichen, der diese Ergebnisse untermauert. Bleiben Sie dran. Anmerkung des Herausgebers:  Bisher mussten Benutzer bei Aurora Standard auch für jeden internen I/O-Vorgang bezahlen, was kaum vorhersehbar oder budgetierbar war. Viele serverlose Datenbanken erheben weiterhin Gebühren für solche Lese- und Schreibvorgänge. Tatsächlich haben wir beim Benchmarking des serverlosen AWS Timestream gesehen  als bei Timescale aufgrund all dieser höheren Grenzkosten. Die Unvorhersehbarkeit und Variabilität der Kosten waren das Gegenteil von Sorgenfreiheit.   Kosten, die am Ende um mehr als das Hundertfache höher ausfielen  Kurz gesagt, serverlose Datenbanken sind mit zunehmender Arbeitslast anfällig für schlechtere Leistung, unvorhersehbare Rechnungen und hohe Kosten. Sie eignen sich nur gut für intermittierende Arbeitslasten, die nur gelegentlich hochfahren, und vertragen Kaltstarts aufgrund der fehlenden Datenzwischenspeicherung im Arbeitsspeicher.  Das Entwicklerdilemma   Hier sind wir gelandet:  Viele Entwickler entscheiden sich immer noch für traditionelle DBaaS-Dienste mit Bereitstellung für Produktionsanwendungen aufgrund ihrer zuverlässigen Leistung, Kontrolle und Verständlichkeit, hassen jedoch die Verschwendung, die durch die Notwendigkeit einer Überbereitstellung entsteht.  Einige Entwickler entscheiden sich aufgrund ihrer offensichtlichen Kosteneinsparungen, Flexibilität und Benutzerfreundlichkeit für serverlose Datenbanken, hassen jedoch die Leistungseinbußen und die unvorhersehbaren, unklaren Preise (die oft dazu führen, dass die Rechnungen auf mysteriöse Weise höher sind als für eine bereitgestellte Instanz).  Da wir selbst Entwickler sind, ist keine dieser Optionen sehr verlockend! Es gibt eine Chance zum Besseren.  Lösung: Einführung von Dynamic PostgreSQL  Deshalb haben wir Dynamic PostgreSQL entwickelt.  Dynamic PostgreSQL unterstützt konsistent Ihre Basislinie und skaliert die Rechenleistung bei Bedarf nahtlos bis zu einem definierten Maximum. Dadurch eignet es sich perfekt für die Bandbreite an kontinuierlichen Arbeitslasten, die Sie normalerweise in Produktionsumgebungen sehen (gleichbleibend, variabel oder stoßweise).  Dynamic PostgreSQL ist zu 100 % PostgreSQL und bietet alle Vorteile der PostgreSQL-Community und des PostgreSQL-Ökosystems sowie die  . Um Dynamic PostgreSQL aufzubauen, haben wir die Art und Weise, wie wir unsere PostgreSQL-Infrastruktur betreiben, erneuert, anstatt die Interna von PostgreSQL zu ändern. Dadurch erhalten Sie Zugriff auf alles, was PostgreSQL – und die Timescale-Plattform – bietet, ohne befürchten zu müssen, auf einer abgespaltenen PostgreSQL-Abfrage- oder Speicher-Engine ausgeführt zu werden.   Reifegrad der Datenbankplattform von Timescale  Mit Dynamic PostgreSQL wählen Sie einen   (eine minimale und maximale CPU), der Ihren Arbeitslastanforderungen entspricht. Dieser Rechenbereich verfügt außerdem über effektiven Speicher, der dem entspricht, was die meisten DBaaS-Dienste traditionell am „maximalen“ Ende des Rechenbereichs bieten. Rechenbereich  Die Basis (Minimum) Ihres CPU-Bereichs verhält sich genau wie das bereitgestellte DBaaS-Modell: Die minimale CPU ist jederzeit für Ihren Dienst zum Ausführen Ihrer Anwendung reserviert. Wenn Ihre Auslastung zunimmt – entweder aufgrund der Nachfrage Ihrer externen Anwendung oder sogar aufgrund gelegentlicher interner Datenbankaufgaben wie inkrementelle Sicherungen oder automatische Tabellenbereinigung – kann Ihre Datenbank ohne Verzögerung bis zur Spitze (Maximum) Ihres CPU-Bereichs genutzt werden.  Wie erreichen wir eine Nullverzögerung? Dynamisches Computing funktioniert anders als einige andere serverlose oder automatisch skalierende Datenbankangebote, sodass es nicht zu der langsamen Skalierung (und Leistungseinbuße) kommt, die normalerweise bei Remote-Migrationen auftritt. Stattdessen stellen unsere Algorithmen zur Infrastrukturkonfiguration und Workload-Platzierung sicher, dass Datenbanken auf ihrem zugrunde liegenden Knoten ohne Neustarts oder Neukonfiguration skaliert werden können. Ihre Instanz hat bei Bedarf immer Zugriff auf die maximale Rechenleistung.  Und das Beste daran ist, dass Sie nur für die Basis und die darüber hinausgehende Nutzung bezahlen. Wir nennen dieses Modell der Auswahl eines Rechenbereichs und der Skalierung zwischen ihm „   “.  Kaufe die Basis, miete die Spitze  Wenn Sie sich beispielsweise für eine Option mit 4–8 CPUs entscheiden, stehen Ihnen immer 4 CPUs für Ihren Dienst und 32 GB effektiver Speicher zur Verfügung. Dadurch ist jederzeit eine gute Basisleistung gewährleistet. Wenn Ihre Auslastung zunimmt, kann Ihre Anwendung bei Bedarf sofort bis zu 8 CPUs nutzen – gemessen und abgerechnet auf Teil-CPU-Basis – und nie mehr als 8 CPUs, wenn dies Ihr Maximallimit ist.  Mit dem dynamischen Modell können Sie die Größe Ihrer Datenbank kostengünstiger und sorgenfreier anpassen. Sie können einen Rechenbereich wählen, bei dem Ihr Standardbedarf dem Minimum entspricht, Sie können ihn jedoch je nach Bedarf erweitern oder bis zum Maximum (Maximum) steigern. Dieser Höchstwert führt zu einer inhärenten Obergrenze für jede Nutzung, die über Ihre Basis-Rechenleistung hinausgeht, was zu einer leicht verständlichen Kostenobergrenze führt. Darüber hinaus berechnen wir den gleichen Tarif pro (Bruchteil-)CPU-Stunde sowohl für Ihre Basis als auch für jede darüber hinausgehende gemessene Nutzung: Es gibt keinen Aufpreis für die Nutzung über Ihrer Basis und daher keine Preisnachteile für die Skalierung.  Wenn Sie schließlich feststellen, dass Sie einen Größenbereich bereitgestellt haben, der zu niedrig oder zu hoch ist, können Sie Ihren Rechenbereich problemlos auf eine Größe anpassen, die den Anforderungen Ihrer Anwendung besser entspricht.   Entwickelt, um Ihnen Geld zu sparen  Wir bieten derzeit fünf verschiedene Rechenbereiche basierend auf der Größe Ihrer Arbeitslast an, wobei Sie unabhängig von Ihrer momentanen Nutzung den entsprechenden effektiven Speicher für den Bereich erhalten.   Dynamic PostgreSQL nutzt außerdem den nutzungsbasierten Speicher von Timescale, bei dem Sie nur für das gespeicherte Datenvolumen (in GB-Stunden) zahlen, nicht für die bereitgestellte Festplattengröße. Machen Sie sich keine Sorgen darüber, dass Sie mit einer überdimensionierten Festplatte Geld verschwenden oder dass Ihnen der Speicherplatz ausgeht. Die dynamische Cloud-Infrastruktur von Timescale stellt sicher, dass Sie bei Bedarf über ausreichend Speicherkapazität verfügen und nur für das bezahlen, was Sie nutzen.  Wir haben Dynamic PostgreSQL absichtlich entwickelt, um Ihnen Geld zu sparen. Kunden, die Produktions-Workloads ausführen, sparen in der Regel 10–20 % bei der Migration von AWS RDS für PostgreSQL und 50–70 % bei der Migration von AWS Aurora Serverless.  Am Ende des Monats besteht Ihre Rechnung aus zwei einfachen, leicht verständlichen Kennzahlen: (1) Ihren Rechenkosten, die als stündliche Basis-Rechenleistung zuzüglich etwaiger darüber hinausgehender CPU-Nutzung, jedoch nicht mehr als Ihre Spitzenleistung, abgerechnet werden; und (2) Ihre Speicherkosten, die als Datenverbrauch in GB-Stunden abgerechnet werden. Es gibt keine neuen Metriken oder abgeleiteten Einheiten, die gemessen oder verstanden werden müssen.  Zahlen Sie einfach für das, was Sie nutzen. Keine zusätzlichen Kosten oder versteckten Gebühren.  Berechnen: vorhersehbar, basierend auf einem definierten Bereich  Lagerung: Zahlen Sie nur für das, was Sie einlagern  Keine verschwendeten Ressourcen. Keine Überzahlung. Kein Schlafverlust in der Nacht. Eine Rechnung, die Sie Ihrem Chef erklären können.  Probieren Sie es noch heute aus  Sie können Dynamic PostgreSQL noch heute ausprobieren!  – keine Kreditkarte erforderlich – damit haben Sie 30 Tage lang vollen Zugriff auf die Plattform. Um einen dynamischen PostgreSQL-Dienst zu erstellen, wählen Sie einfach die PostgreSQL-Option aus, wenn Sie sich bei Timescale anmelden:    Timescale bietet eine kostenlose Testversion an  Die Plattform bietet jetzt zwei Servicetypen, um den spezifischen Anforderungen Ihrer Datenbanken gerecht zu werden:    sind darauf ausgelegt, die Abfragegeschwindigkeit und Skalierbarkeit für Ihre anspruchsvollsten Arbeitslasten zu steigern. Sie bieten wichtige Timescale-Funktionen wie Hypertabellen, Spaltenkomprimierung, kontinuierliche Aggregate und mehrstufigen Speicher. Verwenden Sie sie zum Hosten Ihrer Sensordaten, Energiemetriken, Finanzdaten, Ereignisse und anderer datenintensiver Arbeitslasten. Zeitreihendienste    sind dynamische Postgres-Dienste, die auf Kosteneffizienz und Benutzerfreundlichkeit optimiert sind. Verwenden Sie sie für Ihre rein relationalen Datenbanken, z. B. Geschäftsunterlagen. PostgreSQL-Dienste  Sobald Sie „PostgreSQL“ ausgewählt haben, ist die Konfiguration Ihres dynamischen PostgreSQL-Dienstes ganz einfach. Wählen Sie Ihre Region, Ihren dynamischen Rechenbereich und Ihre Optionen für Hochverfügbarkeit und Verbindungspooling – boom! 💥 Sie verfügen jetzt über eine dynamische PostgreSQL-Datenbank, die Sie in der Produktion verwenden können.   Wenn Sie irgendwelche Fragen haben,  . Wir würden uns über Ihr Feedback freuen und Ihnen bei Ihrem PostgreSQL-Anwendungsfall (Zeitreihe oder nicht) helfen!   Kontaktieren Sie uns  Das ist erst der Anfang. Wir befinden uns mitten in drei aufeinanderfolgenden Startwochen und dies ist erst der Anfang von Woche 2: Dynamic Infra Week. Bleiben Sie dran für mehr in dieser Woche, in diesem Monat, in diesem Jahr und in den vielen kommenden Jahren. 🙂   – Geschrieben von Mike Freedman und Grant Godeke.  Auch  hier veröffentlicht.

Stop database overprovisioning with Dynamic PostgreSQL. Try it out for free

Stop database overprovisioning with Dynamic PostgreSQL Try it out for free

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Zu lang; Lesen

Make resilience your competitive advantage

Lernen Sie Dynamic PostgreSQL kennen: die natürliche Entwicklung von Cloud-Datenbanken

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Wir feiern die Community unserer Technologieunternehmen!

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

HackerNoon Decoded 2024: Celebrating Our Data Science Community!

HackerNoon Decoded 2024: Celebrating Our Programming Community!

HackerNoon Decoded 2024: Wir feiern die Community unserer Technologieunternehmen!

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

HackerNoon Decoded 2024: Celebrating Our Data Science Community!

HackerNoon Decoded 2024: Celebrating Our Programming Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps