Microsoft Researchs neue Remote-Cache-Speichertechnologie „Garnet“

• Einführung in Garnet

  • Garnet, ein neuer von Microsoft Research entwickelter Remote-Cache-Speicher, bietet mehrere besondere Vorteile.
  • Er basiert auf dem verbreiteten RESP-Wire-Protocol, sodass Redis-Clients, die für die meisten Programmiersprachen verfügbar sind, ohne Änderungen verwendet werden können.
  • Er bietet besseren Durchsatz und bessere Skalierbarkeit bei vielen Client-Verbindungen und kleinen Batch-Aufgaben und trägt so zur Kostensenkung bei großen Apps und Services bei.
  • Mit Azure-Cloud-VMs mit aktiviertem beschleunigtem TCP werden sehr niedrige Client-Latenzen erreicht (bei 99,9 % unter 300 Mikrosekunden).
  • Garnet basiert auf moderner .NET-Technologie, ist plattformübergreifend, skalierbar und modern entworfen.
  • Durch die Nutzung des umfangreichen Bibliotheks-Ökosystems von .NET wird der API-Umfang erweitert und es ergeben sich offene Möglichkeiten zur Optimierung.

• Funktionsübersicht

  • Garnet implementiert verschiedene APIs, darunter rohe Strings, analytische Operationen und Objektoperationen.
  • Multi-Key-Transaktionen können über clientseitige RESP-Transaktionen und serverseitige, in C# geschriebene Stored Procedures verarbeitet werden.
  • Nutzer können mit dem Komfort und der Sicherheit von C# benutzerdefinierte Operationen für rohe Strings und neue Objekttypen definieren.

• Leistungsvorschau

  • Auf der Website werden einige zentrale Ergebnisse präsentiert, die Garnet mit führenden Open-Source-Cache-Speichern vergleichen.

• Design-Highlights

  • Das Design von Garnet denkt den gesamten Cache-Speicher-Stack neu – vom Empfang von Paketen im Netzwerk über das Parsen und Verarbeiten von Datenbankoperationen bis hin zu den Interaktionen mit dem Speicher.
  • Die Netzwerkschicht von Garnet übernimmt ein Shared-Memory-Design, das von der früheren Forschung ShadowFax inspiriert ist.
  • Das Speicherdesign von Garnet besteht aus zwei Tsavorite-Key-Value-Stores, die durch ein einheitliches Operationslog bestimmt werden.

• Cluster-Modus

  • Neben dem Betrieb auf einem einzelnen Knoten unterstützt Garnet einen Cluster-Modus, mit dem Sharding- und Replikations-Deployments erstellt und verwaltet werden können.
  • Der Cluster befindet sich noch in Arbeit.

• Nächste Schritte

  • Man kann zur Dokumentationsseite wechseln oder direkt zum Abschnitt „Getting Started“ oder „Releases“ gehen.

• Lizenz

  • Dieses Projekt ist unter der MIT-Lizenz lizenziert; siehe die Datei LICENSE.

• Datenschutz

  • Informationen zum Datenschutz finden sich auf der Datenschutz-Website von Microsoft.

• Mitwirken

  • Dieses Projekt begrüßt Beiträge und Vorschläge; für die meisten Beiträge ist die Zustimmung zu einer CLA erforderlich.
  • Es wurde der Microsoft Open Source Code of Conduct übernommen; siehe die FAQ zum Code of Conduct oder kontaktiere bei weiteren Fragen oder Anmerkungen [e-mail].

• Marken

  • Dieses Projekt kann Marken oder Logos für Projekte, Produkte oder Services enthalten; die Nutzung von Microsoft-Marken oder -Logos muss den Microsoft-Richtlinien zu Marken und Branding entsprechen.

Meinung von GN⁺

• Garnet ist ein neuer Cache-Speicher, der mit bestehenden Redis-Clients kompatibel ist und zugleich höhere Leistung und bessere Skalierbarkeit bietet, was ihn für Unternehmen attraktiv machen könnte, die große Cloud-Services betreiben.
• Es werden langfristige Daten dazu benötigt, wie stabil diese Technologie in realen Umgebungen arbeitet und welche praktischen Vorteile sie im Vergleich zu bestehenden Cache-Lösungen tatsächlich bietet.
• Dass sich der Cluster-Modus von Garnet noch in Entwicklung befindet, könnte für Nutzer, die große Deployments in Betracht ziehen, ein wichtiger Faktor sein.
• Da Garnet als Open Source bereitgestellt wird, besteht die Möglichkeit, dass durch Beiträge aus der Community zusätzliche Funktionen und Verbesserungen entstehen, was zur Reife der Technologie beitragen kann.
• Vor der Einführung von Garnet sollten die Kompatibilität mit bestehenden Systemen, die Kosten im Verhältnis zum Leistungsgewinn sowie potenzielle Migrationskosten berücksichtigt werden.

[GN⁺]

Hacker-News-Kommentare

• Laut der Benchmark-Leistungsgrafik ist der Durchsatz des GET-Befehls von Garnet mehr als zehnmal höher als der von Dragonfly. Die Latenz beim 50. Perzentil ist etwas höher als bei Dragonfly, die Latenz beim 99. Perzentil jedoch etwas niedriger. Durchsatz und Latenz von Garnet und Dragonfly sind Redis deutlich überlegen, was darauf hindeutet, dass Redis eine erhebliche Leistungsoptimierung benötigt.

  Tsavorite, die Speicher-Engine von Garnet, ist von OSS FASTER abgeleitet und umfasst leistungsstarke Datenbankfunktionen wie Thread-Skalierbarkeit, Unterstützung für hierarchischen Speicher (Arbeitsspeicher, SSD, Cloud-Speicher), schnelles nicht blockierendes Checkpointing, Wiederherstellung, Write-Ahead-Logging für Haltbarkeit, Unterstützung für Multi-Key-Transaktionen sowie besseres Speichermanagement und Wiederverwendung.

• Gute Nachrichten für alle, die Redis unter Microsoft Windows Server direkt ausführen müssen, ohne auf WSL2 angewiesen zu sein, oder etwas Redis-Kompatibles brauchen. Zuvor gab es einen inzwischen nicht mehr unterstützten Redis-Port mit Problemen beim Speicherverbrauch, vermutlich hauptsächlich wegen speicherabgebildeter Dateien.

  Es ist sehr interessant zu sehen, dass es in C# geschrieben wurde, und ich hätte Interesse daran, Zeit in die Erkundung des Codes zu investieren.

• Eine beeindruckende Redis-Alternative, wenn sie in einem echten Nicht-Azure-Stack betrieben wird. Ich bin gespannt, wie sie sich in der Praxis schlägt.

• Es ist interessant zu sehen, wie Microsoft und das .NET-Team sehr beeindruckende Infrastrukturprojekte bauen. Yarp deckt Reverse Proxy/API Gateway und Ähnliches ab, und jetzt gibt es mit Garnet auch etwas für In-Memory-Cache.

  Offenbar gibt es intern viele Bedürfnisse, und sie scheinen bereit zu sein, das zu teilen.

• Da Garnet multithreaded ist, ist MSET nicht atomar. Wenn man eine atomare Version von MSET möchte, muss man sie als Transaktion (Stored Procedure) ausdrücken.

  Ich habe Schwierigkeiten zu verstehen, warum der Befehl nicht intern in eine Transaktion verpackt wird, um ihn atomar zu machen. Ich frage mich, welche anderen Fallstricke bei der Atomarität es noch gibt.

• Wenn man sich die Kommentare hier ansieht, scheint niemand mehr memcached zu benutzen?

• Microsoft Research bringt gelegentlich beeindruckende Projekte hervor. Es muss Spaß machen, für R&D bezahlt zu werden. Ich wünschte, große Unternehmen würden mehr Projekte im Stil von R&D machen, die der Branche helfen. Falls Hashicorp auf den Markt kommt, hoffe ich, dass ein gutes Unternehmen es übernimmt.

• Dieses Projekt sieht wirklich gut aus. Ich hoffe, es ersetzt letztlich die Ressource „Azure Cache for Redis“. Der Dienst ist derzeit langsam, ein Redis-Fork, der dafür gebaut wurde, unter Windows zu laufen, und das Hochfahren einer Instanz dauert fast eine Stunde.

• Ich frage mich, wo dieses System keine gute Leistung bringt. Ich würde auch gern Benchmarks auf kleineren Instanztypen sehen. 72 vCPU ist schon eine ziemlich große Instanz.