Das größte Feature von DuckDB war zugleich sein größter Engpass
DuckDB hat sich einen Ruf als leistungsstarke, dateibasierte Analysedatenbank erworben. Wie SQLite läuft sie eingebettet in einer Anwendung, sodass keine separate Server-Einrichtung nötig ist. Dieses Design machte sie für leichtgewichtige, prozessinterne analytische Workloads äußerst attraktiv.
Diese eingebettete Natur hatte jedoch einen erheblichen Haken: die Parallelität. Jeder Anwendungsprozess hält seinen eigenen zwischengespeicherten Zustand der Datenbank im Arbeitsspeicher. Für einen einzelnen Prozess ist das effizient, bedeutet aber, dass jeweils nur ein Prozess in eine Datenbankdatei schreiben kann. DuckDB konnte die zwischengespeicherten Zustände mehrerer Prozesse nicht synchron halten.
Stellen Sie sich ein Team vor, das mehrere Dienste, Dashboards und Anwendungen betreibt, die alle auf dieselben analytischen Daten zugreifen und sie aktualisieren müssen. Mit dem herkömmlichen DuckDB standen sie vor einem Dilemma: entweder selbst eine komplexe Freigabeschicht zur Koordination der Schreibvorgänge zu bauen oder sich für eine ganz andere Datenbank zu entscheiden.
Dieser Engpass zwang viele dazu, die Kernstärken von DuckDB zu umgehen. Manche Nutzer betrieben DuckDB sogar innerhalb von PostgreSQLQL, um einen gemeinsamen Zugriff zu erreichen. Genau das Merkmal, das DuckDB so zugänglich machte – seine eingebettete, serverlose Natur –, wurde zur größten Einschränkung für kollaborative Umgebungen.
Quack gibt DuckDB eine Eingangstür, keine neue Storage-Engine
Quack, im Mai erstmals experimentell eingeführt, gibt DuckDB eine Eingangstür. Eine DuckDB-Instanz öffnet die Datenbankdatei und fungiert als Server. Andere DuckDB-Instanzen verbinden sich über einfaches HTTP mit ihr und senden ihre Lese- und Schreibvorgänge. So können mehrere Anwendungen gleichzeitig mit der Datenbank arbeiten.
Entscheidend ist, dass der Server der einzige Prozess bleibt, der direkt auf die Datenbankdatei zugreift. Diese Architektur vermeidet die Fallstricke uneingeschränkter Dateischreibvorgänge durch mehrere Prozesse, bei denen gleichzeitige Caches zu Beschädigungen führen könnten. Stattdessen teilen sich Clients den Zugriff über einen Koordinator, wodurch die Datenintegrität gewahrt und die Zugänglichkeit erweitert wird.
Das DuckDB-Team stellte fest, dass viele Nutzer bereits eigene Wrapper bauten oder DuckDB sogar innerhalb von PostgreSQLQL betrieben, um einen leichtgewichtigen gemeinsamen Zugriff zu erreichen. Quack, jetzt ein ausgereiftes Feature in DuckDB 2.0, bietet für diesen häufigen Anwendungsfall eine native, offiziell unterstützte Lösung. Entwickler können damit den Zugriff mehrerer Clients ermöglichen, ohne auf maßgeschneiderte, oft fragile Notlösungen zurückgreifen zu müssen.
Diese neue Serverfunktion ändert nichts an der Kernidentität von DuckDB als dateibasierter Analysedatenbank. Sie ergänzt lediglich eine robuste, native Option für koordinierten Zugriff. So kann DuckDB mit Quack 60 Millionen Zeilen in weniger als 5 Sekunden zwischen zwei Rechnern übertragen und übertrifft damit das Protokoll von PostgreSQLQL deutlich, das für dieselbe Aufgabe über 2,5 Minuten benötigte. Winzige Schreibvorgänge erreichen mit 8 Threads zwar ein Plateau bei etwa 5.500 pro Sekunde, das reicht jedoch für mehrere Dienste, die sich ein Dashboard teilen, reichlich aus.
Sechzig Millionen Zeilen in fünf Sekunden sind ein Augenöffner
Die eindrucksvollste Demonstration von Quack betrifft die Datenübertragungsgeschwindigkeit. In einem Video von Better Stack übertrug das DuckDB-Team mit Quack 60 Millionen Zeilen in weniger als fünf Sekunden zwischen zwei Rechnern. Zum Vergleich: Das PostgreSQLQL-Protokoll benötigte für denselben Vorgang über zweieinhalb Minuten (mehr als 150 Sekunden).
Dieser Benchmark verdeutlicht den Vorteil von Quack bei analytischen Workloads. Anders als herkömmliche zeilenorientierte Datenbankprotokolle überträgt Quack native DuckDB-Spaltenvektor-Payloads direkt über HTTP. Dadurch entfällt der erhebliche Mehraufwand, spaltenorientierte Daten in zeilenweise Formate und anschließend wieder zurück umzuwandeln, wie er bei vielen Datenbank-Wire-Protokollen üblich ist.
Die Beschleunigung ist bei analytischen Übertragungen erheblich, bei denen es darauf ankommt, große Datensätze effizient zu verschieben. So beeindruckend das ist: Beachten Sie, dass es sich um einen berichteten Benchmark handelt. Die Leistung in der Praxis kann variieren, abhängig von:
- Ihrem konkreten Workload
- den Netzwerkbedingungen
- den Hardwarekonfigurationen
- der Form der Abfragen
Einen tieferen Einblick, wie Quack dies erreicht, einschließlich seiner Designprinzipien, bietet die offizielle Dokumentation unter Quack: The DuckDB Client-Server Protocol. Dieses Protokoll ist ein Wendepunkt, doch es ist wichtig, seine spezifischen Stärken und Grenzen für Ihren Anwendungsfall zu verstehen.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Die Obergrenze von 5.500 Schreibvorgängen zeigt, wann Schluss ist
Quack überzeugt beim Verschieben großer analytischer Datensätze, doch seine Grenzen bei transaktionalen Workloads sollten Sie kennen. Benchmarks zeigen, dass der DuckDB-Servermodus bei kleinen Schreibvorgängen bis zu etwa acht parallelen Threads PostgreSQLQL übertrifft. Darüber hinaus flacht die Leistung bei etwa 5.500 Schreibvorgängen pro Sekunde ab.
Diese Obergrenze besteht, weil der DuckDB-Server zwar mehrere Clients ermöglicht, aber weiterhin auf einen einzigen Prozess angewiesen ist, der alle Dateischreibvorgänge übernimmt. Man kann es sich wie einen einzelnen, sehr effizienten Kassierer vorstellen, der viele Kunden bedient; er kann nur eine bestimmte Anzahl von Transaktionen pro Sekunde abwickeln.
Diese Architektur eignet sich hervorragend für gemeinsame Analysen, Dashboards und Dienste, die von einem einfachen, zentralen DuckDB-Hub profitieren, insbesondere wenn schnelle Massendatenübertragung Priorität hat. Sie vereinfacht die Datenaufnahme und komplexe Abfragen über Anwendungen hinweg.
Hochfrequente transaktionale Systeme, in denen jeder Schreibvorgang sofort und parallel verarbeitet werden muss, werden diesen Single-Process-Engpass jedoch als limitierend empfinden. Für solche anspruchsvollen OLTP-Szenarien (Online Transaction Processing) bleibt PostgreSQLQL oder eine andere spezialisierte OLTP-Datenbank die geeignetere Wahl. DuckDB 2.0 enthält außerdem weitere Verbesserungen bei Speicherung und Abfragen, aber das Design von Quack ist der entscheidende Faktor für gleichzeitige Schreibvorgänge.
Häufig gestellte Fragen
Was ist Quack in DuckDB 2.0?
Quack ist das Client-Server-Protokoll von DuckDB. Es ermöglicht Client-Instanzen, Abfragen und Schreibvorgänge über HTTP an einen DuckDB-Prozess zu senden, der die Datenbankdatei besitzt.
Können mehrere Anwendungen in dieselbe DuckDB-Datenbank schreiben?
Ja. Mit Quack können mehrere Clients Aufgaben an eine Serverinstanz senden, die der einzige Prozess ist, der direkt auf die Datenbankdatei zugreift.
Ersetzt DuckDB 2.0 PostgreSQL?
Nein. Der DuckDB-Servermodus eignet sich für gemeinsame Analysen und moderate Schreiblasten; PostgreSQL ist für anspruchsvolle transaktionale Workloads mit hoher Parallelität in der Regel besser geeignet.
Wie schnell ist DuckDB Quack?
Laut dem Video werden 60 Millionen Zeilen in weniger als fünf Sekunden zwischen zwei Rechnern übertragen. Der Durchsatz bei kleinen Schreibvorgängen flacht Berichten zufolge bei etwa 5.500 Schreibvorgängen pro Sekunde ab.