IO-Geräte und Latenzprobleme

IO-Geräte und Latenz

• Nichtflüchtige Speichergeräte sind ein Kernelement moderner Computersysteme, da sie Daten auch dann speichern können, wenn der Strom ausgeschaltet ist. Anders als flüchtige Speicher wie CPU-Register, CPU-Cache und RAM benötigen sie keine dauerhafte Stromversorgung.

Bandlaufwerke

• Seit den 1950er Jahren verwenden Computer Bandlaufwerke für die nichtflüchtige digitale Speicherung. Bänder eignen sich für die Speicherung langer Datensequenzen und sind passend für Situationen, in denen große Datenmengen sicher gespeichert werden müssen, aber nicht häufig gelesen werden.
• Bänder sind kostengünstig und langlebig und werden weiterhin in großen Datenspeichern wie bei CERN und AWS eingesetzt.

Festplattenlaufwerke (HDD)

• Festplattenlaufwerke bieten im Vergleich zu Bändern einen schnelleren Datenzugriff und speichern Daten auf kreisförmigen Metallscheiben. Da die gesamte Oberfläche der Scheiben jederzeit verfügbar ist, verringert sich die Latenz beim Lesen und Schreiben von Daten.
• HDDs unterstützen Command Queuing, sodass mehrere Befehle parallel ausgeführt werden können.

Solid-State-Drives (SSD)

• Solid-State-Drives lesen und schreiben Daten elektronisch ohne mechanische Bauteile und bieten mit NAND-Flash nichtflüchtige Speicherung.
• SSDs können ihre Leistung durch Parallelverarbeitung und Garbage Collection optimieren. Auch die Anordnung der Daten kann die Performance beeinflussen.

Speicherung in der Cloud

• Die Verlagerung in die Cloud hat die IO-Performance verändert, und viele Unternehmen migrieren ihre Server und Datenbanksysteme in die Cloud.
• In Cloud-Umgebungen ist die Trennung von Storage und Compute üblich. Das bietet Datensicherheit und Flexibilität, kann aber zu Performance-Einbußen führen.

Trennung von Storage und Compute

• Traditionell wurden nichtflüchtige Speichergeräte direkt an Server angebunden, in der Cloud ist jedoch die Anbindung von Storage über das Netzwerk üblich.
• Netzwerkgebundener Storage bietet Datensicherheit, kann sich jedoch negativ auf die IO-Performance auswirken.

Lokaler vs. Netzwerk-Storage

• Lokale NVMe-SSDs bieten sehr hohe IO-Geschwindigkeiten und geringere Latenzen als netzwerkgebundener Storage.
• Bei netzwerkgebundenem Storage kann es Beschränkungen für IO-Operationen geben, was zu Performance-Verlusten führen kann.

Lösung: Metal

• Metal ist eine von PlanetScale angebotene Lösung, die direkt angebundene NVMe-SSDs nutzt und dadurch hervorragende Performance und Skalierbarkeit bietet.
• Ein Metal-Cluster besteht standardmäßig aus einem Primärserver und zwei Replikaten, um die Datenhaltbarkeit sicherzustellen, und die Speicherkapazität lässt sich einfach erweitern.
• Metal-Datenbanken haben keine künstlichen Beschränkungen für IO-Operationen und können diese mit minimaler Latenz ausführen.

[GN⁺]

Hacker-News-Kommentare

• Es wird erwähnt, dass der Autor des Blogs beim Schreiben dieses Artikels offensichtlich viel Freude hatte. Mit Tausenden Zeilen JavaScript wurden interaktive Visualisierungen erstellt.
• Es wird erklärt, dass man SQLite+NVMe schon lange unterstützt. Das ist ein neues Muster, das die Möglichkeit bietet, Probleme ohne horizontale Skalierung zu lösen.
  • Bei Performance-Problemen ist Latenz am wichtigsten.
  • Das ist besonders wichtig, wenn Dinge sequenziell verarbeitet werden müssen.
  • Wenn SQLite auf NVMe läuft, erhält man Latenzvorteile, die andere Anbieter nicht bieten können.
  • In den meisten realen Anwendungsfällen bietet In-Memory-Ausführung keinen wesentlich größeren Vorteil als die Persistenz von NVMe.
• Es wird gelobt, dass der Beitrag so informativ war, dass man fast vergisst, dass es sich um Produktwerbung handelt. Die großartigen Visualisierungen und die Interaktivität werden hervorgehoben.
• Beim Ansehen der Animationen zu Disk I/O musste man an Melvin Kaye denken.
  • Mel schrieb keine Delay-Loops.
  • Das galt auch dann, wenn der Flexowriter zwischen ausgegebenen Zeichen eine Verzögerung benötigte.
  • Er platzierte Anweisungen auf der Trommel so, dass sie sich genau dann direkt hinter dem Lesekopf befanden, wenn sie gebraucht wurden.
  • Die Trommel musste eine vollständige Umdrehung machen, um die nächste Anweisung zu finden.
• Es wird gesagt, dass der Blog gut ist. Im Allgemeinen wird darauf hingewiesen, dass Cloud-Speicher "unnatürlich langsam" ist.
  • Es wird erwähnt, dass kürzlich Unterstützung dafür hinzugefügt wurde, inkrementelle Indizes auf S3/Object Storage zu speichern.
  • Der Grund, warum man NVMe länger verwendet hat, seien die Performance-Vorteile aus einem früheren Artikel.
  • Es wird geäußert, dass es schön wäre, wenn jemand diesen Bereich mit einem besseren Angebot revolutionieren würde.
• Es wird darauf hingewiesen, dass verteilte Speicherung in diesem Artikel nicht ausreichend behandelt wurde.
  • Einige Systeme unterstützen Replikation nicht nativ.
  • Cassandra-Cluster und MySQL können Master-Slave-Replikation durchführen, viele Systeme jedoch nicht.
  • Wenn man NVMe-Storage in der Cloud verwendet, muss man Wartungsintervalle und von der Cloud ausgelöste Drains berücksichtigen.
  • Wenn man Storage von Compute trennt, kann der Cloud-Betreiber Compute nach Bedarf verschieben.
  • Da die Daten unabhängig von Compute sind, kann der Cloud-Betreiber Datensysteme und Drains verwalten.
• Metal sieht sehr cool aus. Es wird erwähnt, dass man in einem früheren Job versucht hat, die instance-local SSDs von GCP zu verwenden, dabei aber erhebliche Zuverlässigkeitsprobleme hatte.
  • Es gab ein Problem, bei dem Blöcke auf dem Gerät Daten verloren.
  • Man fragt sich, ob sich diese Situation verbessert hat.
  • Es wird nach dem verwendeten Maschinentyp gefragt.
  • Als Lösung wird die Verwendung von Discords Network Disk erwähnt.
• PlanetScale Metal wirkt sehr robust. Es ist immer interessant zu sehen, wie die Latenz in einem Release deutlich sinkt.
• Ein sehr guter Artikel. Die Visualisierung von Random Writes ist sehr gelungen.
  • Ein weiteres Problem mit netzwerkgebundenem Storage in der Cloud sind IOPS-Limits.
  • Viele Cloud-Anbieter, darunter AWS und Google Cloud, verwenden dieses Modell und begrenzen die Menge an I/O-Operationen, die übertragen werden können.
  • Wenn Storage direkt an die Compute-Instanz angeschlossen ist, gibt es keine künstlichen Begrenzungen für I/O-Operationen.
  • Man kann so schnell lesen und schreiben, wie es die Hardware zulässt.
  • Es wird gefragt, ob das "IOPS"-Limit eine Begrenzung für bestimmten Netzwerkverkehr ist.
  • Es wird gefragt, ob damit der Netzwerkverkehr von EBS-Volumes gemeint ist.
  • Man fragt sich, ob sich damit Kosten sparen lassen, ob das an seltsamer Arbitrage bei AWS liegt oder ob die Effizienz daher kommt, dass weniger EBS-Networking nötig ist.
  • Es ist klar erkennbar, dass es Latenzvorteile hat, Storage und Compute auf derselben Maschine zu haben.
  • Es wird gefragt, ob es auch Vorteile beim Durchsatz pro Kosten gibt.
• Es wird gefragt, wie "serverlose" Datenbankanbieter Zugriff mit "niedriger Latenz" bewerben.
  • Sie verwenden Object Storage wie S3, bei dem zu erwarten ist, dass die Latenz deutlich schlechter ist als bei Network Storage.
  • Es wird erwähnt, dass eine Caching-Schicht aufgebaut wurde und dass die Daten auf lokal angebundenem NVMe gehalten werden sollen.