Auf der Suche nach einem schnelleren SQLite

• SQLite ist bereits ein schnelles Datenbanksystem, doch Forschende suchen nach Wegen, es noch schneller zu machen.
• Forschende der Universität Helsinki und Cambridge veröffentlichten die Arbeit „Co-Design of Serverless Runtime/Database through Asynchronous I/O“ und zeigten damit, dass sich die Tail-Latenz um bis zu das 100-Fache reduzieren lässt. Diese Arbeit bildet die Grundlage für Limbo, eine in Rust neu geschriebene Version von SQLite.

io_uring

• Erklärung zu io_uring: Das io_uring-Subsystem des Linux-Kernels stellt eine Schnittstelle für asynchrones I/O bereit. Es reduziert den Overhead durch das Kopieren von Puffern über Ringpuffer zwischen User Space und Kernel Space. Anwendungen können I/O-Anfragen absenden und bis zur Benachrichtigung über deren Abschluss durch das Betriebssystem andere Aufgaben ausführen.

• Abfrageausführung in SQLite: SQLite verwendet Dateien zur Datenspeicherung, öffnet die Datenbank mit der Funktion sqlite3_open() und wandelt SQL-Anweisungen mit sqlite3_prepare() in Bytecode um. Die Funktion sqlite3_step() führt die Bytecode-Befehle aus und verarbeitet so die Abfrage.

Annahmen

• Der Aufstieg von Serverless-Computing: In Serverless-Umgebungen kann Datenbanklatenz zum Problem werden. Wird die Datenbank direkt in die Edge-Runtime eingebettet, entfällt diese Latenz, und SQLite eignet sich gut für solche Umgebungen.

• Probleme von SQLite: Durch die Nutzung von synchronem I/O werden Ressourcen nicht optimal ausgenutzt, was zu Problemen bei Parallelität und Multi-Tenancy führt.

• Der Umstieg auf io_uring: Das Ersetzen von POSIX-I/O-Aufrufen durch io_uring ist nicht einfach; SQLite muss für ein asynchrones I/O-Modell neu entworfen werden.

Limbo

• Unterstützung für asynchrones I/O: Die VM- und BTree-Komponenten wurden angepasst, um asynchrones I/O zu unterstützen, und synchrone Bytecode-Befehle wurden durch asynchrone ersetzt. Asynchrones I/O beseitigt Blockierungen und verbessert die Parallelität.

• Trennung von Query- und Storage-Engine: Um die Ressourcennutzung zu maximieren, wird vorgeschlagen, Query Engine und Storage Engine zu trennen.

Bewertung und Ergebnisse

• Benchmarking: Es wurde eine mandantenfähige Serverless-Runtime simuliert, in der jeder Tenant seine eigene eingebettete Datenbank besitzt. Beim Vergleich der Abfragelatenz von SQLite und Limbo reduzierte Limbo die Tail-Latenz bei p999 um das 100-Fache.

• Zukünftige Arbeit: Weitere Benchmarks mit mehreren Leser:innen und Schreiber:innen sind geplant; der Leistungsvorteil fällt allerdings erst ab p999 deutlich auf.

• Open-Source-Code: Der Code von Limbo ist als Open Source verfügbar: Limbo GitHub

[GN⁺]

Hacker-News-Kommentare

• Es gibt eine Diskussion darüber, dass bestimmte Anwendungsfälle von serverlosem Computing, etwa AWS Lambda und eine zentrale Datenbank, nicht immer gut zu Apps passen, die serverlos aufgebaut sind

  • Ich habe vor 6–7 Jahren an der Lösung eines Problems gearbeitet, bei dem komplexe hierarchische Dateien verarbeitet und bestimmte Informationen extrahiert werden mussten
  • FaaS ist für rechenintensive Aufgaben teuer, und große XML-Dateien jedes Mal zu laden und zu parsen war ineffizient
  • Als Lösung wurde eine zentrale Funktion mit Timer verwendet, die Dateien liest und parst, sie in eine SQLite-Datenbank lädt und indexiert und die Datei dann in S3 speichert
  • Die Lambda-Funktion lud die Datei aus S3 herunter und führte Abfragen aus, wenn sie neuer als die lokale Kopie war oder bei einem Cold Start
  • Es wurde festgestellt, dass Lambda ein lokales Verzeichnis /tmp hat und SQLite in der Python-Laufzeit enthalten ist, sodass außer der Funktion kein zusätzlicher Code hochgeladen werden musste
  • Es ist interessant, dass an Arbeiten geforscht wird, die diese Art von Lösung noch schneller machen könnten

• Es könnte erwähnenswert sein, dass einer der beiden Forscher der Vorgesetzte des Autors ist

  • Ich hatte fälschlicherweise angenommen, dass Autor und Forscher nichts miteinander zu tun haben

• Ich stimme der Aussage zu: „Erst ab p999 und darüber hinaus ist ein Vorteil sichtbar, bei p90 und p99 ist die Performance fast identisch mit SQLite“

  • Ich mag SQLite und Optimierungen, aber das stimmt einfach

• SQLite hat eine umfangreiche Test-Suite und ist sehr gründlich getestet

  • Ich frage mich, ob ein Rewrite ähnlich getestet werden wird, insbesondere wenn er schnelle, aber schwer zu schreibende und potenziell fehleranfällige Features wie io_uring verwendet

• Für das Benchmarking wurde eine Multi-Tenant-Serverless-Runtime simuliert, in der jeder Tenant seine eigene eingebettete Datenbank hat

  • SQLite hat pro Tenant einen eigenen Thread und misst, indem in jedem Thread Abfragen ausgeführt werden
  • Ich frage mich, ob ein serverloses SQLite-Setup pro Request einen eigenen SQLite-Prozess verwenden würde

• Es gab früher Versuche, asynchrones I/O in Postgres einzuführen, die aber eingestellt wurden

  • Ein jüngerer Vorschlag ist, den Storage Manager austauschbar zu machen, ohne die Codebasis forken zu müssen
  • An diesem neuen Vorschlag besteht großes Interesse; er hängt mit der Bewegung zusammen, Storage und Compute zu trennen

• Es gibt eine Frage zu der Idee, während asynchrones I/O läuft, andere Arbeit zu erledigen

  • Es wird infrage gestellt, ob man bei Datenbankarbeit nicht dennoch auf den Abschluss der Transaktion warten muss

• Als Autor des Blogposts hatte ich nicht erwartet, dass dieser Beitrag auf der Startseite landet

  • Ich arbeite bei Turso; das Paper wurde im April 2024 veröffentlicht, und seitdem wurden viele Verbesserungen vorgenommen

• SQLite ist Open Source, aber der wichtige Test-Harness ist es nicht

  • Es gibt die Frage, wie Alternativen die Kompatibilität garantieren wollen

• Ich hatte versucht, einen einfachen Weg zu finden, aus einer strikten Teilmenge des SQLite-Dateiformats ein JSON-ähnliches Format zu machen, bin aber gescheitert

  • Das Dateiformat wirkt an vielen Stellen willkürlich, weshalb ich das Interesse verloren habe, aber jemand anders könnte damit Erfolg haben