概要
- DuckDBに新しいリモートプロトコル「Quack」導入
- クライアント・サーバ型で複数同時書き込み対応
- HTTPベースでシンプルかつ高速な設計
- 認証や認可も拡張性を重視
- ベンチマークで高い転送性能を実証
DuckDBのQuackプロトコル発表
- DuckDBチーム が新リモートプロトコル「 Quack」を発表
- DuckDBインスタンス同士が クライアント・サーバ型 で通信可能
- 複数同時書き込み や遠隔地からの利用に対応
- 設定が非常に シンプル で、 HTTP 技術を活用した設計
- 高速通信 を実現し、大規模バルク操作から小規模トランザクションまで対応
従来のデータベースアーキテクチャ
- 1980年代に Sybase がクライアント・サーバ型アーキテクチャを導入
- 以降、多くのDBが クライアント・サーバ型通信プロトコル を採用
- SQLite や DuckDB はインプロセス型で独自路線を維持
- インプロセス型は データサイエンス用途 やアプリ組み込みに最適
- 複数プロセスから同時にDBファイルを操作する用途には 制約
DuckDBにおける課題とワークアラウンド
- DuckDBは メモリ上の状態管理 が重要で、複数プロセスでの同時変更は困難
- カスタムRPCやArrow Flight SQL等で クライアント・サーバ型 を後付けする事例が多発
- MotherDuck なども独自プロトコルを提供
- PostgreSQL拡張（例： pg_duckdb）による間接利用も存在
- 多数のワークアラウンドが存在し、 公式サポートの必要性 が認識される
Quackプロトコルの概要
- Quack はDuckDBインスタンス間の通信専用プロトコル
- DuckDB v1.5.2 以降で利用可能、 core_nightly リポジトリから拡張導入
- インスタンスは クライアント／サーバ両方 の役割を持つ
- 認証トークン によるセキュリティ確保
- localhost バインドがデフォルトで安全性重視
Quackの利用例
- 双方のDuckDBで quack拡張 のインストールとロード
- サーバ側で quack_serve、クライアント側で ATTACH してリモートDB利用
- リモートテーブル の参照やデータコピーが容易
- query関数 で複雑なクエリもリモート実行可能
プロトコル設計と技術的特徴
- HTTPベース で構築、既存のネットワークインフラと親和性高
- リクエスト・レスポンス型 で全通信を管理
- 独自MIMEタイプ application/duckdb で効率的なシリアライズ
- 暗号化 は基本的にローカル用途で不要、公開する場合はnginx等でSSL推奨
- 1ラウンドトリップ でクエリ処理を完結できる低遅延設計
- バルク転送最適化 で数百万行を数秒で転送可能
認証・認可の拡張性
- デフォルトでは ランダム認証トークン を自動生成
- 認証・認可コールバックは ユーザー独自実装 も可能
- SQLマクロ によるコールバックもサポート
- デフォルト認可は全許可だが、細かな制御も実現可能
ポート番号と接続設定
- デフォルトポート9494 でリッスン
- 94は Netscape Navigator リリース年に由来し覚えやすい
ベンチマーク結果
- AWS m8g.2xlarge （8vCPU/32GB RAM/15Gbps帯域）環境で検証
- 同一データセンター内 の異なるマシン間でテスト
- Ping平均0.280msの低遅延ネットワーク
- PostgreSQLプロトコル や Arrow Flight SQL と比較し、Quackが 最速のテーブル転送性能 を発揮
まとめ
- Quackプロトコル によりDuckDBは クライアント・サーバ型 運用が公式サポート
- シンプル・高速・拡張性 を兼ね備え、多様なユースケースに対応
- 詳細は 公式ドキュメント 参照