Lufts Weg zur Elastizität – Teil 1: Von Shared Nothing zu Shared Storage
(engineering.ab180.co)Wir teilen unsere Erfahrungen damit, wie wir die Elastizität von Luft, unserer selbst entwickelten Datenbank, verbessert haben, indem wir von einer Shared-Nothing-Architektur zu einer Shared-Storage-Architektur gewechselt sind.
- Zuvor verarbeitete jeder Node Daten mit eigenem, unabhängigem Storage. Bei der Verarbeitung großer Datenmengen fehlte es jedoch an Elastizität, sodass es schwierig war, auf sprunghafte Workloads zu reagieren.
- Wir haben das Konzept der Compute-Storage Separation angewendet, bei dem Compute-Ressourcen und Storage getrennt werden, und uns deshalb für den Wechsel zu einer Shared-Storage-Architektur mit gemeinsam genutztem Storage entschieden.
- Wir haben einen Ansatz erprobt, bei dem FUSE für den Zugriff auf S3 genutzt wird. Aufgrund der Eigenschaften der Go-Runtime traten bei der Verwendung von FUSE jedoch Performance-Probleme auf, sodass wir auf Anwendungsebene selbst einen Buffer Pool Manager implementiert haben.
- Durch diese Verbesserungen wurden direkte Queries an S3 möglich, und die Query-Performance in Fällen, in denen Daten nicht vorab verteilt waren, verbesserte sich um bis zu mehr als 70 %, wodurch sich die Elastizität von Luft deutlich erhöhte.
1 Kommentare
Das ist wirklich spannend – da bekomme ich auch Lust, es selbst auszuprobieren.