DuckDB-Wasm bereitstellen

Eine DuckDB-Wasm-Bereitstellung benötigt Zugriff auf die folgenden Komponenten:

die Hauptbibliothek von DuckDB-Wasm, als TypeScript verteilt und zu JavaScript-Code kompiliert
die Worker-Komponente von DuckDB-Wasm, zu JavaScript-Code kompiliert, in Thread-Umgebungen möglicherweise mehrfach instanziiert
das DuckDB-Wasm-Modul, als WebAssembly-Datei kompiliert und vom Browser instanziiert
alle relevanten DuckDB-Wasm-Erweiterungen

Hauptbibliothek

Sie wird entweder als TypeScript-Code oder als CommonJS-JavaScript-Code im npm-Paket duckdb-wasm verteilt und kann zusammen mit einer Anwendung gebündelt, in einer Same-Origin-(Sub-)Domain ausgeliefert und zur Laufzeit eingebunden oder von einem Drittanbieter-CDN wie jsDelivr bereitgestellt werden. Eine Form der Transpilierung ist erforderlich; sie kann nicht unverändert ausgeliefert werden, da der Speicherort der nachfolgenden Dateien bekannt sein muss, damit alles funktioniert. Die Details hängen von Ihrer Umgebung ab; Beispiele finden Sie unter https://github.com/duckdb/duckdb-wasm/tree/main/examples. Ein Beispiel-Deployment ist https://shell.duckdb.org, das die Hauptbibliothek zusammen mit dem Shell-Code transpiliert (erster Ansatz). Oder das Beispiel bare-browser unter https://github.com/duckdb/duckdb-wasm/tree/main/examples/bare-browser.

JS-Worker-Komponente

Sie wird als JavaScript-Datei in 3 Varianten verteilt, mvp, eh und threads, und muss unverändert ausgeliefert werden. Die Hauptbibliothek muss über den tatsächlichen Speicherort informiert werden.

Es gibt 3 Varianten für 3 verschiedene platforms:

mvp zielt auf die WebAssembly-1.0-Spezifikation
eh zielt auf die WebAssembly-1.0-Spezifikation mit Wasm-Level-Exception-Handling, was die Leistung verbessert
threads zielt auf die WebAssembly-Spezifikation mit Exception- und Threading-Konstrukten

Sie können alle 3 ausliefern und per Feature Detection wählen oder eine einzelne Variante bereitstellen und die duckdb-wasm-Bibliothek anweisen, welche sie verwenden soll.

Wasm-Worker-Komponente

Wie bei der JS-Worker-Komponente gibt es 3 Varianten, mvp, eh und threads; jede wird von der zugehörigen JS-Komponente benötigt. Diese WebAssembly-Module müssen unverändert unter einer beliebigen [Sub-]Domain ausgeliefert werden, die von der Hauptdomain erreichbar ist.

DuckDB-Erweiterungen

DuckDB-Erweiterungen für DuckDB-Wasm werden, analog zum nativen Fall, signiert am Standard-Erweiterungsendpunkt ausgeliefert: https://extensions.duckdb.org. Wenn Sie DuckDB-Wasm bereitstellen, können Sie relevante Erweiterungen an einem anderen Endpunkt spiegeln und so beispielsweise abgeschottete Deployments in internen Netzen ermöglichen.

SET custom_extension_repository = '⟨https://some.endpoint.org/path/to/repository⟩';

Damit wird das Standard-Erweiterungsrepository vom öffentlichen https://extensions.duckdb.org auf das angegebene umgestellt. Beachten Sie, dass Erweiterungen weiterhin signiert sind. Am besten laden Sie die Erweiterungen herunter und stellen sie in einer ähnlichen Struktur wie das Original-Repository bereit. Siehe unsere zusätzlichen Hinweise unter Ein eigenes Repository erstellen.

Community-Erweiterungen werden unter https://community-extensions.duckdb.org ausgeliefert und mit einem anderen Schlüssel signiert. Sie können daher mit einer einmaligen SQL-Anweisung deaktiviert werden:

SET allow_community_extensions = false;

Damit werden nur Core-DuckDB-Erweiterungen geladen. Beachten Sie, dass der Fehler zur Zeit von LOAD auftritt, nicht zur Zeit von INSTALL.

Allgemeine Informationen zu Erweiterungen finden Sie auf der Seite Extension Distribution.

Sicherheitsaspekte

Warning Wenn Sie DuckDB-Wasm mit Zugriff auf Ihre eigenen Daten bereitstellen, kann jeder, der SQL ausführen kann, auf die Daten zugreifen, auf die DuckDB-Wasm zugreifen kann. Außerdem kann DuckDB-Wasm in der Standardeinstellung entfernte Endpunkte erreichen und so auch aus der Sandbox heraus sichtbare Auswirkungen auf die Außenwelt haben.