Eine kurze Geschichte von Garnet
Hallo zusammen! Ich möchte diesen Blogbeitrag mit einer kurzen Geschichte von Garnet und seiner Entstehung beginnen. Bei Microsoft Research arbeiten wir seit einiger Zeit an Speichertechnologien. Im Jahr 2016 begannen wir mit einem neuen Key-Value-Store-Design auf Basis von Epoch Protection und einer leistungsstarken Storage-API. Dieses Projekt namens FASTER wurde 2018 als Open Source veröffentlicht und erlangte innerhalb von Microsoft und der größeren Community große Beliebtheit. FASTER hat über 6.000 Sterne und über eine halbe Million NuGet-Downloads. In den folgenden Jahren entwickelten wir weitere Funktionen wie Wiederherstellbarkeit (CPR) und Serverless-Unterstützung (Netherite), und das Projekt wurde weit verbreitet.
Um 2021 herum stellten wir ein riesiges Interesse an Remote-Cache-Stores fest, insbesondere unter Verwendung von APIs wie der RESP-API von Redis. Entwickler liebten die Flexibilität sowohl der API als auch des Bereitstellungsmodells als separater Prozess/Dienst. Die Kosteneinsparungen im Vergleich zum direkten Zugriff auf Cloud-Datenbanken trieben die Einführung von Caching-Schichten voran, und diese wuchsen bald zu einem erheblichen Teil der Betriebskosten großer Dienste heran. Als die Pandemie hereinbrach und die Nutzung von Online-Diensten stark anstieg, gab es einen dringenden Bedarf, die Kosten zu senken und die Leistung (Durchsatz und Latenz) für solche Caching-Schichten zu verbessern.
Wir nahmen die Herausforderung an, ein neues System namens Garnet zu entwickeln, das in einer Client-Server-Konfiguration eine extrem hohe End-to-End-Leistung bieten konnte, während die Clients durch die Übernahme von RESP, den beliebtesten Wire-Protokollen, weitgehend unverändert blieben. Nach viel Designaufwand entwickelten wir ein Server-Threading-Modell, das tatsächlich einen enormen Unterschied in der End-to-End-Leistung, oft um Größenordnungen, bei grundlegenden Get- und Set-Operationen bewirken konnte, mit unverändertem Client-Code. Dies gab uns das Vertrauen, den Funktionsumfang von Garnet für den Einsatz in realen Szenarien auszubauen.
Die nächste Frage war die API-Abdeckung. Die Redis-API ist riesig, und wir waren nur ein kleines Forschungsteam. Glücklicherweise basierte unser Stack auf .NET, was enorme Fortschritte sowohl in Bezug auf die Leistung als auch auf die Fülle der Bibliotheken mit sich brachte. Wir entwarfen eine generische und dennoch leistungsstarke Methode zur Definition und Verwendung benutzerdefinierter Datenstrukturen und konnten durch Wiederverwendung von Datenstrukturen in C# schnell komplexe Datentypen wie Sorted Set, List und Hash implementieren. Wir bauten auch komplexe Strukturen wie HyperLogLog und Bitmap und fügten Transaktions- und Erweiterungsfunktionen hinzu.
Die nächste Anforderung war Scale-out und Wiederherstellung, wofür wir Write-Ahead-Operation-Logging, Sharding-Fähigkeit, Replikation und Key-Migration für dynamisches Scale-out entwarfen. Indem wir die grundlegende Kompatibilität mit der Redis-API beibehielten, konnten wir diese Funktionen so hinzufügen, dass der vorhandene Client-Code weitgehend unverändert bleiben konnte.
Nach Tausenden von Unit-Tests und zwei Jahren der Zusammenarbeit mit First-Party-Teams bei Microsoft, die Garnet in der Produktion einsetzten (mehr dazu in zukünftigen Blogbeiträgen!), waren wir der Meinung, dass es an der Zeit war, es öffentlich zu veröffentlichen, genau wie wir es vor fünf Jahren mit FASTER getan hatten. Wir wollten, dass Entwickler auf der ganzen Welt von dieser leistungsstarken Technologie profitieren und zum Codebase beitragen. Wir waren der Meinung, dass die moderne C#-Codebasis hier besonders attraktiv wäre, in Bezug auf einfache Erweiterung, Wartung und Beitrag. Da wir von MSR kamen, wollten wir auch, dass Leute aus der akademischen Welt Forschung betreiben, mit uns zusammenarbeiten und verschiedene Aspekte des Systems erweitern.
Erkunden Sie also Garnet, sehen Sie, ob Sie es in Ihren Anwendungen verwenden können, helfen Sie uns bei der Erweiterung seiner Fähigkeiten, und wie immer, lassen Sie uns wissen, was Sie denken!