- Nichtflüchtige Speicher haben sich von Tape über HDD und SSD bis hin zu Cloud-Netzwerkspeicher entwickelt, doch Datenort und Datenlayout bestimmen weiterhin die IO-Latenz
- Tape-Speicher ist stark beim sequenziellen Lesen und Schreiben, kann beim Lesen weit entfernter Daten aber bis zu mehrere Dutzend Sekunden benötigen und eignet sich daher nicht für transaktionsorientierte Datenbanken mit hohem Traffic
- HDDs haben die Latenz gegenüber Tape deutlich reduziert, doch wegen rotierender Platter und Kopfbewegungen liegen zufällige Lesezugriffe meist bei 1–3 ms, und die Performance hängt stark von der Reihenfolge der Requests ab
- SSDs arbeiten ohne mechanische Bauteile mit NAND Flash, sodass zufällige Lesezugriffe bis zu 16 μs schnell sein können; wegen der Nutzung von Parallelität und Garbage Collection bleibt das Datenlayout jedoch weiterhin wichtig
- Die Trennung von Storage und Compute in der Cloud erleichtert Skalierung und Ausfallbehandlung, bringt aber Netzwerk-Roundtrips und IOPS-Limits mit sich; PlanetScale Metal will diese Kosten durch direkt angeschlossene NVMe SSDs und Replikation verringern
Grundlegende Faktoren für Speicherlatenz
- Nichtflüchtiger Speicher bewahrt Daten auch bei ausgeschaltetem Strom und ist die Grundlage für Daten wie Fotos, E-Mails, Kontostände und medizinische Aufzeichnungen
- Flüchtiger Speicher wie CPU-Register, CPU-Cache und RAM ist schneller, benötigt aber eine dauerhafte Stromversorgung
- Storage-Performance ist nicht nur eine Frage der Kapazität, sondern hängt davon ab, wie auf Daten zugegriffen wird, in welchen Einheiten gelesen und geschrieben wird, von Queuing, Parallelität und davon, ob Netzwerk-Roundtrips nötig sind
- PlanetScale erklärte zur Einführung von PlanetScale Metal, dass Metal Cloud-Datenbanken mit lokalen NVMe-Laufwerken statt mit netzwerkverbundenem Storage betreibt
Tape-Speicher: stark bei sequenziellem Zugriff, schwach bei zufälligem Zugriff
- Computer nutzen seit den 1950er-Jahren Tape Drives als nichtflüchtigen digitalen Speicher
- Eine Tape-Kassette besteht aus mehreren Tracks und vielen Zellen; der magnetische Polarisationszustand jeder Zelle repräsentiert binäre Daten
- Wenn die Kassette in den Reader eingelegt und per Motor gespult wird, liest der IO head die vorbeilaufenden Daten
- Liegt die Lese- oder Schreibposition nahe am Kopf, ist der Zugriff schnell; liegt sie weit entfernt, steigt die Latenz
- Auch bei modernen Tape-Systemen müssen zum Lesen weit entfernter Daten unter Umständen Hunderte Meter gespult werden
- In solchen Fällen kann ein Lesevorgang mehrere Dutzend Sekunden dauern
- Selbst bei derselben Anzahl von Lese- und Schreibvorgängen dauert es deutlich länger, wenn die Daten verstreut liegen, als bei sequenzieller Anordnung
- Das Beispiel im Artikel zeigt eine Situation, in der verstreute Lese- und Schreibvorgänge bei gleicher Arbeitsmenge etwa 7-mal länger dauern
- Tape hat schlechte Latenzen bei zufälligen Lese- und Schreibzugriffen, eignet sich aber weiterhin für lange sequenzielle Lese- und Schreibvorgänge
- Die Kosten pro GB sind niedriger als bei SSDs und HDDs, und die Archivierungslebensdauer ist lang
- CERN verwaltet über 400 PB Daten in einem Tape-Storage-Data-Warehouse
- Auch AWS bietet einen Tape-Archivierungsdienst an
- Für transaktionale Datenbanken mit hohem Traffic ist Tape nicht geeignet
HDD: Kompromiss aus rotierenden Disks und Command Queuing
- HDDs speichern Daten statt auf Tape auf runden Metallscheiben, den sogenannten Plattern
- Die Platter rotieren schnell in einem Gehäuse; als gängige Geschwindigkeit wird im Beispiel 7200 RPM genannt
- Die Tracks einer HDD sind kreisförmig, und eine einzelne Disk kann über 100.000 Tracks haben
- Jeder Track enthält Hunderttausende Pages, wobei jede Page ungefähr 4 KB Daten enthält
- Eine HDD richtet Lese- und Schreibpositionen durch Kopfbewegung und Platter-Rotation aus
- Anders als bei Tape sind die Bits der gesamten Oberfläche jederzeit zugänglich
- Es ist nicht nötig, ein Band zu spulen, bis die gewünschten Daten freiliegen
- Typische zufällige Lesezugriffe können in 1–3 ms ausgeführt werden
- Die Reihenfolge der Requests hat großen Einfluss auf die Performance
- Lese- und Schreibvorgänge mit hoher Sequenzialität werden schnell abgeschlossen
- Werden dieselben sechs Lese- und Schreibvorgänge durcheinander angeordnet, steigt die Wartezeit, bis der Platter an der richtigen Position ist
- Magnetische Disks unterstützen seit Langem Command Queuing
- SCSI bietet entsprechende Funktionen seit den 1980er-Jahren, SATA seit den 2000er-Jahren
- Das Betriebssystem kann mehrere Befehle so senden, dass sie parallel oder in anderer Reihenfolge ausgeführt werden
- Der Disk-Controller kann die Aufgabenwarteschlange nutzen, um Lese- und Schreibvorgänge passend zur Disk-Struktur zu planen
- HDDs sind eine Verbesserung gegenüber Tape, können aber insbesondere bei zufälligen Lese- und Schreibzugriffen weiterhin langsam sein
SSD: Performance-Variablen bleiben auch ohne mechanische Bauteile
- SSDs beziehungsweise Flash-Speicher wurden in den 1980er-Jahren erfunden, wurden als Consumer-Speicher aber erst in den 2000er-Jahren zum Mainstream
- SSDs sind beim Lesen von Daten nicht auf mechanische Bauteile angewiesen
- Sie verwenden nichtflüchtige Transistoren namens NAND Flash
- Einsen und Nullen werden ohne Bewegung physischer Bauteile über elektrische Signale gelesen, geschrieben und gelöscht
- Eine SSD besteht aus einem oder mehreren Targets; jedes Target enthält mehrere Blocks, und ein Block enthält mehrere Pages
- SSDs lesen und schreiben in Page-Einheiten
- Selbst wenn nur ein Teil der Daten benötigt wird, ist die Request-Einheit des Laufwerks eine Page
- In der Beispielkonfiguration ergeben eine Page mit 4096 Bit, ein Block mit 16K Pages, ein Target mit 16K Blocks und ein Gerät mit 8 Targets insgesamt
4k * 16k * 16k * 8 = 8,796,093,022,208Bit, also 8 TB - Zufällige Lesezugriffe auf SSDs können je nach Modell bis zu 16 μs schnell sein
- Auch ohne mechanische Bauteile ist das Datenlayout wichtig
- Zu den Performance-Faktoren von SSDs gehören Parallelität und Garbage Collection
SSD-Parallelität: Target-Verteilung verändert den Durchsatz
- In der Regel hat jedes Target eine eigene Line, die mit der Control Unit verbunden ist
- Jede Line verarbeitet Lese- und Schreibvorgänge, kann aber jeweils nur eine Page auf einmal übertragen
- Die Page-Übertragung ist sehr schnell, benötigt aber dennoch eine kleine Zeitspanne
- Wenn acht Writes auf vier Targets verteilt sind, können vier Lines parallel genutzt werden, sodass in zwei Zeitscheiben geschrieben werden kann
- Wenn alle acht Writes auf dasselbe Target fallen, wird nur eine Line genutzt, während die übrigen Lines ungenutzt bleiben
- Reihenfolge der Lese- und Schreibvorgänge sowie Datenlayout beeinflussen auch bei SSDs die Performance
- Beim Design von Software wie MySQL muss darauf geachtet werden, in welcher Struktur Daten gespeichert und wie sie auf der Disk angeordnet werden
SSD-Garbage-Collection: die Kosten des Löschens vor dem Schreiben
- SSD-Pages können mehrfach gelesen werden, doch eine einmal beschriebene Page kann nicht mit neuen Daten überschrieben werden, bevor die vorhandenen Daten explizit gelöscht wurden
- Einzelne Pages können nicht gelöscht werden; es muss der gesamte Block gelöscht werden
- Eine SSD benötigt interne Algorithmen zur Verwaltung von Empty, In-use und Dirty Pages
- Eine Dirty Page ist eine Page, die beschrieben wurde, deren Daten aber nicht mehr benötigt werden und die zum Löschen bereit ist
- Um neue Writes anzunehmen, müssen Daten manchmal umplatziert werden; der Algorithmus dafür ist der Garbage Collector
- Wenn genügend unused Pages vorhanden sind, können neue Daten direkt geschrieben werden
- Wenn zu wenige unused Pages vorhanden sind und viele Dirty Pages existieren, muss zuerst Garbage Collection ausgeführt werden
- Im Beispiel werden zwei non-dirty Pages an eine andere Stelle verschoben, um fünf neue Pages zu schreiben
- Danach werden alle Pages des betreffenden Targets in den Dirty-Zustand versetzt, damit sie gelöscht werden können
- Diese zusätzlichen Schritte können die Write-Performance stark verlangsamen
- Auf einer stark ausgelasteten SSD mit vielen Lese-, Schreib- und Löschvorgängen kann Garbage Collection andere Arbeiten verlangsamen
Veränderung durch die Cloud: Trennung von Storage und Compute
- Der Wechsel von Tape zu HDD und SSD hat die Performance dauerhafter IO deutlich erhöht
- Der Wechsel in die Cloud brachte eine weitere Veränderung der IO-Performance
- AWS wird als Dienst dargestellt, der seit seinem Start 2006 die Migration in die Cloud stark verbreitet hat
- In Cloud-Umgebungen mieten Nutzer virtualisierte Server auf beliebiger Hardware in großen Rechenzentren
- Server können aus verschiedenen Gründen jederzeit beendet werden, etwa durch Hardwareausfälle, Austausch oder Netzwerkunterbrechungen
- Wer Systeme auf gemieteter Cloud-Infrastruktur baut, muss häufigere Ausfälle tolerieren können
- Diese Bedingungen und der Bedarf an dynamisch skalierbaren Storage-Volumes führten zur Trennung von Storage und Compute
Vorteile und Kosten von netzwerkverbundenem Storage
- Traditionell sind nichtflüchtige Speicher direkt an Server, Desktops, Laptops und Smartphones angeschlossen
- Verwendet werden SATA-Kabel, PCIe-Interfaces oder eine Integration im selben SoC
- Direkt angeschlossener Storage ist schnell, hat aber zwei Einschränkungen
- Wenn der Server ausfällt, sind auch die Daten nicht mehr verfügbar
- Die Storage-Größe ist fest
- Application-Server passen meist gut zu temporären, ephemeral Umgebungen, und viele Arbeiten finden im Speicher statt, daher ist dieses Problem dort weniger groß
- Datenbanken dürfen keine Daten verlieren, wenn ein Server ausfällt, und ihre Datengröße kann schnell wachsen und Storage-Grenzen erreichen
- Viele Cloud-Anbieter ermöglichen es, Compute-Instanzen separat konfigurierbaren netzwerkverbundenen Storage anzuhängen
- Die Grundkonfiguration von EC2 hängt üblicherweise ein EBS-Netzwerk-Storage-Volume an
- Auch Datenbankdienste wie Amazon RDS, Amazon Aurora, Google Cloud SQL und PlanetScale stützen sich auf Systeme, bei denen Compute und Storage über das Netzwerk getrennt sind
- Dieser Ansatz erlaubt es, Storage-Volumes dynamisch an wachsende oder schrumpfende Datenmengen anzupassen
- Selbst wenn ein Server ausfällt, bleiben die Daten sicher erhalten und können erneut an einen anderen Server angehängt werden
- Dafür entstehen Performance-Kosten durch Netzwerk-Roundtrips und IOPS-Limits
Latenzunterschied zwischen lokalem NVMe und Netzwerk-Storage
- Eine direkt angeschlossene NVMe SSD ist eine SSD, die die Non-Volatile Memory Host Controller Interface Specification nutzt und schnelle IO-Geschwindigkeit sowie hohe Bandbreite bietet
- Der Roundtrip von der CPU zum RAM wird mit etwa 100 ns angegeben
- Der Roundtrip von der CPU zu einer lokal angeschlossenen NVMe SSD beträgt etwa 50.000 ns, also 50 μs
- Ein netzwerkverbundenes Storage-Volume benötigt einen kurzen Netzwerk-Roundtrip innerhalb des Rechenzentrums
- Für netzwerkverbundenen Storage wie EBS wird die Roundtrip-Zeit mit etwa 250.000 ns, also 250 μs oder 0,25 ms, angegeben
- Selbst bei Verwendung derselben modernen SSD dauert die Verarbeitung einzelner Lese- und Schreib-Requests über eine Netzwerkverbindung um eine einstellige Größenordnung länger
- Bei großen sequenziellen IOs lässt sich der negative Einfluss reduzieren, aber nicht beseitigen
- Netzwerkverbundener Storage erzeugt bei jedem Zugriff auf das Storage-System zusätzliche Latenz
IOPS-Limits und der Unterschied zu direkt angeschlossenem Storage
- Viele Cloud-Anbieter, darunter AWS und Google Cloud, begrenzen im Modell mit netzwerkverbundenem Storage die Anzahl der IO-Operationen, die über die Leitung gesendet werden können
- Amazons GP3-EBS-Instanz erlaubt standardmäßig 3000 IOPS pro Sekunde
- Höhere Einstellungen sind möglich, kosten aber zusätzlich
- Frühere GP2-EBS-Volumes funktionierten über einen IOPS-Pool, der aufgebaut wurde, um gelegentliche Bursts zu ermöglichen
- Wird Storage direkt an die Compute-Instanz angeschlossen, gibt es keine künstlichen Limits für IO-Operationen
- Bei direkter Anbindung kann so viel gelesen und geschrieben werden, wie die Hardware zulässt
Dauerhaftigkeit und Skalierbarkeit erhalten
- Problem 1 bei direkt angeschlossenen SSDs, Datenhaltbarkeit, lässt sich durch Replikation lösen
- Ein üblicher Ansatz besteht darin, einen Server als Primary zu betreiben, der alle Write-Requests annimmt, während zwei oder mehr zusätzliche Server die Daten replizieren
- Wenn Daten an drei Orten liegen, sinkt die Wahrscheinlichkeit eines Datenverlusts
- Unter der Beispielannahme einer monatlichen Server-Ausfallwahrscheinlichkeit von 1 % gilt:
- Bei einem einzelnen Server beträgt die Wahrscheinlichkeit eines Datenverlusts pro Monat 1 %
- Bei drei Servern sinkt sie auf
1% × 1% × 1% = 0.0001%, also auf 1 zu 1.000.000
- PlanetScale erkennt und ersetzt ausgefallene Nodes automatisch und erstellt Datenbank-Backups häufig und zuverlässig
- Problem 2, die Skalierbarkeit der Laufwerke, erfordert mehr manuelle Eingriffe
- Monitoring und Benachrichtigungen sind nötig, wenn sich eine Disk der Kapazitätsgrenze nähert
- Es werden Tools benötigt, um die Kapazität bei Bedarf einfach zu erhöhen
Ansatz von PlanetScale Metal
- Metal bietet Datenbank-Cluster mit direkt angeschlossenen NVMe SSDs
- Jede Datenbankinstanz läuft mit direct-attached NVMe SSD
- Ein Metal-Cluster besteht standardmäßig aus einem Primary und zwei Replicas
- Unterstützte Datenbank-Cluster sind Vitess oder Postgres
- Wenn die Storage-Grenze erreicht ist, kann mit wenigen Klicks auf einen Server mit größeren Laufwerken skaliert werden
- Intern wird ein neuer Node gestartet und die Daten werden von der bestehenden Instanz auf die neue Instanz migriert; dieser Prozess erfolgt mit zero downtime
- Metal-Datenbanken haben keinen künstlichen IOPS cap
- Nutzer können IO-Operationen mit niedriger Latenz ausführen und ohne teure IOPS-Klassen oder Throttling des Cloud-Anbieters so viel nutzen, wie die Hardware zulässt
1 Kommentare
Meinungen auf Hacker News
Ich bin der Autor des Blogposts. Das Schreiben dieses Beitrags hat mir wirklich Spaß gemacht, und er war mit Abstand der komplexeste, den ich bisher erstellt habe.
Für die interaktiven Visualisierungen habe ich buchstäblich Tausende Zeilen JavaScript geschrieben; ich hoffe, ihr findet sie unterhaltsam.
Allerdings wirkt die Formulierung „1 zu 1 Million“ zur Haltbarkeit auf mich zu pessimistisch, wenn man bedenkt, dass die Ausfallzeit kurz ist, bis ein neuer Server dazukommt und wieder repliziert wird.
Wenn die Wiederherstellung zum Beispiel 10 Minuten dauert, läge die Wahrscheinlichkeit, dass alle drei Server überlappend ausfallen, selbst dann schon bei etwa 1 zu 2 Millionen, wenn jeder der drei Server garantiert einmal im Monat ausfällt. Wenn die monatliche Ausfallwahrscheinlichkeit 1 % beträgt, wird die Chance, dass sich drei Ausfälle überschneiden, extrem gering.
Bei 1 Million Kunden ist 1 zu 1 Million kein besonders guter Wert, deshalb wollte ich das ergänzen.
Mir ist klar, dass die Zeit an der Tastatur und die Zeit, in der man im Kopf daran arbeitet, ziemlich unterschiedlich sein können.
Mit dem Thema bin ich sehr vertraut, daher habe ich zum Inhalt selbst nichts hinzuzufügen; beim Überfliegen sieht er gut aus. Ich plane allerdings Animationen für meinen eigenen Blog, und ein paar Libraries, die ich zuletzt ausprobiert habe, haben mir nicht gefallen.
Ich habe eine Zeit lang die Kombination SQLite+NVMe propagiert. Für mich wirkt sie wie ein neues Pattern, mit dem man viel weiter kommt als gewohnt, und in manchen Fällen kann man damit bis zum Ende ohne horizontale Skalierung durchhalten.
Bei Performance ist Latenz König, besonders wenn Einträge seriell verarbeitet werden müssen. Wenn man SQLite auf NVMe betreibt, erhält man einen Latenzvorteil, den andere Anbieter nicht liefern können.
Für die meisten realistischen Anwendungsfälle glaube ich auch nicht, dass die Ausführung im Speicher wesentlich besser ist als persistenter Speicher auf NVMe.
Auf einem einzelnen Host mag es etwas schneller sein, aber sobald aus einem Webserver zwei werden und beide in die Datenbank schreiben müssen, macht man es sich meiner Meinung nach selbst schwerer.
Auch die Aussage, Latenz sei wichtig, ist missverständlich. Ohne Konsistenz ist Performance bedeutungslos, und sobald es mehrere Webserver gibt, muss man diese Konsistenz selbst lösen.
Außerdem ist Datenbanklatenz normalerweise viel kleiner als ein Internet-Roundtrip, und selbst diese Internetlatenz ist klein im Vergleich zu der „Latenz“, die durch das Warten auf das Laden von Page Assets wie Bildern oder Code-Libraries entsteht.
Serielle Datenbankabfragen sollte man ohnehin so weit wie möglich vermeiden, wenn möglich Joins verwenden und, wenn das nicht geht, Abfragen möglichst asynchron gleichzeitig abschicken, damit sie parallel ausgeführt werden.
Um Probleme mit parallelen Schreibvorgängen zu vermeiden, kann man neben dem Setzen eines bestimmten, etwas unbeholfenen Betriebsmodus in der Anwendung den Trick verwenden, einen einzelnen dedizierten Schreib-Thread zu nutzen.
Dadurch wird ohnehin komplexer paralleler Code meist noch etwas komplexer. Mit einem einzigen Schreib-Thread funktioniert SQLite wirklich hervorragend.
fsync()auf eine Datei in einem ext4-Dateisystem ausführt, misst man selbst auf einer NVMe-SSD immer noch 1–2 ms Latenz.Auf neueren Systemen waren es etwa 800 µs.
Die Informationsdichte war so gut, dass ich beim Lesen völlig vergessen habe, dass es eigentlich Produktwerbung ist. Visualisierung und Interaktion sind hervorragend.
Die Animation der Disk-I/O hat mich an Melvin Kaye erinnert.
Mel verwendete selbst dann keine Zeitschleifen, wenn der langsame Flexowriter eine Verzögerung zwischen ausgegebenen Zeichen brauchte.
Stattdessen passte er die Position der Instruktionen auf der Trommel so an, dass der Lesekopf immer gerade an der nächsten Instruktion vorbeigelaufen war, wenn sie benötigt wurde, und die Trommel eine weitere Umdrehung machen musste, um die nächste Instruktion zu finden.
https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/The...
Metal sieht wirklich großartig aus, aber als ich bei meinem vorherigen Arbeitgeber Instance Local SSDs von GCP verwendet habe, gab es gravierende Zuverlässigkeitsprobleme, etwa dass Geräteblöcke Daten verloren.
Ich frage mich, ob sich die Lage inzwischen geändert hat und welche Maschinentypen ihr verwendet.
Der damalige Workaround war dieser: https://discord.com/blog/how-discord-supercharges-network-di...
Allerdings betreiben wir ein redundantes System mit semi-synchroner MySQL-Replikation, sodass alle Schreibvorgänge auf zwei Maschinen in unterschiedlichen Availability Zones persistiert werden, bevor sie dem Client bestätigt werden.
Der Kubernetes-Operator und der
vtorc-Prozess von Vitess arbeiten zusammen, um ausgefallene oder verdächtige Replikate aktiv zu erkennen und zu ersetzen.Auf GCP haben wir mit n2d-highmem-Maschinen die besten Ergebnisse gesehen, und auf AWS verwenden wir fast durchgehend Typen der neuesten Generation mit Instance Storage.
Guter Artikel. Generell gibt es auch das Problem, dass Cloud Storage ungewöhnlich langsam ist.
Das wurde anderswo zwar schon behandelt, aber dieser Beitrag fasst das Problem gut zusammen: http://databasearchitects.blogspot.com/2024/02/ssds-have-bec...
Kürzlich wurde in https://github.com/feldera/feldera Unterstützung dafür hinzugefügt, inkrementelle Indizes in S3/Object Storage zu speichern; NVMe wurde wegen der im vorherigen Beitrag genannten offensichtlichen Performance-Vorteile schon deutlich früher unterstützt.
Es wäre schön, wenn jemand diesen Bereich mit einem besseren Bereitstellungsmodell aufmischen würde.
In diesem Artikel wird ein Aspekt von Distributed Storage nicht ausreichend gewürdigt.
Erstens bringen manche Systeme keine Replikation von Haus aus mit. Cassandra-Cluster oder MySQL können Master-Slave-Replikation, viele Systeme aber nicht.
Zweitens wird der Betrieb deutlich schwieriger, wenn man in der Cloud NVMe Storage nutzt, weil man Wartungsfenster und von der Cloud initiierte Drains berücksichtigen muss.
Wenn man sich nicht in solche Systeme einklinkt und die Daten auf andere Nodes verschiebt, verschwinden sie.
Wenn Storage und Compute getrennt sind, kann der Cloud-Betreiber Compute bei Bedarf leeren und verschieben; die Daten sind unabhängig vom Compute, und da der Cloud-Betreiber auch dieses Datensystem und die Drains verwaltet, kann er die Platzierung von Workloads ohne Eingriff des Kunden anpassen.
Replizierter, über das Netzwerk angebundener Storage, der wie eine „lokale“ Dateisystem-API aussieht, ist ein leistungsfähiger Weg, Systemen ohne eingebaute Replikation — wie dem, das wir haben — Durability zu geben.
Wirklich cool, und PlanetScale Metal sieht ebenfalls ziemlich solide aus. Besonders gefällt mir, in dem Release den deutlichen Rückgang der Latenz zu sehen: https://planetscale.com/blog/upgrading-query-insights-to-met...
Jahrelang habe ich nicht verstanden, warum replizierte Datenbanken immer an EBS festhalten und diese Latenz in Kauf nehmen. Wenn bereits Replikation vorhanden ist, warum dann nicht mutig lokale Disks verwenden?
In einer früheren Organisation, als wir Elasticsearch als temporären Speicher für Logs/Metriken betrieben, habe ich vorgeschlagen, genau das zu tun, zumal die Reliability-Anforderungen nicht besonders hoch waren. Ich konnte aber niemanden überzeugen, und am Ende nutzten wir das schlechtere AWS Elasticsearch.
Ich weiß, dass die Kapazität lokaler Disks begrenzt ist, aber das Verhältnis von Cores/Memory/Disk dürfte für die meisten Use Cases ausreichen. Es gibt auch viele Local-Disk-Instanzen mit anderen Verhältnissen, sodass man eine passende Balance finden kann.
Mit Local-Hard-Disk-Instanzen ab 20 TB könnte man sogar Hot/Cold Storage umsetzen.
Großes Lob an das PlanetScale-Team: Sie tun endlich etwas, das Sinn ergibt. Nicht einmal AWS betreibt Elasticsearch auf lokalen Disks — dabei muss man sich nur vorstellen, all diese Dinge wie ClickHouse oder Cassandra auf lokalen Disks zu betreiben.
Das Kernproblem war, dass die Disks nach einem Stop-Start-Event gelöscht werden. Selbst wenn der Rest des Clusters in Ordnung ist und es nutzbare Replicas gibt, kann SQL Server damit nicht automatisch umgehen.
Da initialisierte Nodes nicht automatisch wiederhergestellt werden, wären Scripting und Tests, um das zu umgehen, in der Produktion für alle außer den kühnsten und fähigsten Organisationen kaum tragbar.
Wir betreiben Hunderte ClickHouse-Cluster nach diesem Modell. Größenanpassungen zur Behebung von Performance-Problemen sind deutlich häufiger als wegen Ausfällen.
Wenn zum Beispiel an einem Sonntagmorgen US-Zeit ein Performance-Problem bei einem Tenant auftritt, ist die einfachste Lösung, für das Wochenende auf eine größere VM zu wechseln und das Kernteam am Montagmorgen die Ursache untersuchen zu lassen.
Die Zusatzkosten sind gering, und man vermeidet den viel teureren Burnout von Mitarbeitern.
Wirklich ausgezeichneter Artikel, und die Visualisierung zufälliger Schreibvorgänge ist sehr gut gemacht.
Zu den IOPS-Limits von Network-Attached Storage habe ich ein paar vielleicht dumme Fragen.
Erstens frage ich mich, ob ein „IOPS“-Limit eigentlich ein Rate Limit für eine bestimmte Art von Netzwerkverkehr ist, nämlich den Traffic zu und von EBS-Volumes. Anders gesagt: Bedeutet „IOPS“ hier am Ende „EBS-Volume-Netzwerkverkehr“?
Zweitens frage ich mich, ob dieser Ansatz Kosten spart. Falls ja: Liegt das an einer merkwürdigen AWS-Preisarbitrage oder an Effizienzgewinnen, weil weniger EBS-Networking anfällt?
Es scheint klar, dass es bei der Latenz strukturell einen Hop spart, Storage und Compute auf derselben Maschine zu haben. Mich würde aber interessieren, ob es auch beim Durchsatz pro Dollar Vorteile bringt.
Ich sehe das eher als anderes Modell: Ein EBS-Volume ist kein Stück physischer Platine an einem PCIe-Bus, sondern eher ein Anteil an einem großen verteilten System aus sehr vielen physischen Laufwerken, ungefähr wie ein SAN mit dedizierter Netzwerkkapazität zu und von Compute.
Es kann Kosten sparen, ist am Ende aber ein Bündel mehrerer Trade-offs.