Quack: DuckDBにクライアント・サーバー・アーキテクチャをもたらす

長年にわたり、DuckDBはインプロセス・アーキテクチャを支持してきました。クライアントとサーバーの境界を排除することで、データサイエンティストや開発者に、アプリケーションやノートブック内で直接動作する低レイテンシで高性能なツールを提供してきました。しかし、この設計は根本的な制限を生み出しました。それは、単一のデータベースファイルを複数のプロセスから同時に変更することの難しさです。

これを解決するために、DuckDBチームは専用のクライアント・サーバー・プロトコルであるQuackを導入しました。Quackにより、DuckDBインスタンス同士が通信可能になり、DuckDBは厳密なローカルツールから、中央集権的な状態と並行したリモートアクセスをサポートできる多才なシステムへと変貌を遂げます。

リモート・プロトコルの必要性

インプロセス・システムはインタラクティブな分析には優れていますが、複数のプロセスが同じデータセットに書き込む必要があるテレメトリ収集やダッシュボード作成では苦戦します。以前は、カスタムRPCレイヤー、Arrow Flight SQLプロトコル、あるいはDuckDBをPostgreSQLでラップする（いわゆる「EleDucken」アプローチ）といった回避策に頼っていましたが、ネイティブなソリューションへの需要は否定できないものとなっていました。

Quackは「ユニバーサルなデータ・ラングリング・ツール」として設計されており、ユーザーがDuckDBに期待するシンプルさとスピードを維持しつつ、サーバー管理によるミュータブルな状態のメリットを提供します。

Quackの仕組み

Quackを使用すると、任意のDuckDBインスタンスをクライアントまたはサーバーとして動作させることができます。セットアップはDuckDB拡張機能を通じて行われ、ユーザーはシンプルなSQLコマンドを使用して、データベースをサーバーとして提供したり、リモートからアタッチしたりすることが可能になります。

コア技術設計

  • HTTPベース: QuackはHTTP上に構築されており、既存のロードバランサー、ファイアウォール、および認証システムとの互換性を確保しています。この選択により、DuckDB-WasmもQuackをネイティブに話すことが可能になり、ブラウザベースのインスタンスがリモートサーバーに直接接続できるようになります。
  • リクエスト・レスポンス・パターン: プロトコルはクライアント主導のリクエスト・レスポンス・モデルに従います。低レイテンシ向けに最適化されており、1回のラウンドトリップでクエリを完了させることができます。
  • カスタム・シリアライゼーション: 外部の交換フォーマットを使用する代わりに、Quackは新しいMIMEタイプ application/duckdb を使用します。これはDuckDBの内部シリアライゼーション・プリミティブ（Write-Ahead Logで使用されるものと同じ）を活用しており、チームが外部フォーマットに制限されることなくデータ型を革新できることを可能にします。
  • セキュリティ: デフォルトでは、Quackは起動時にランダムな認証トークンを生成し、localhost にバインドします。本番環境では、チームはSSL終端を処理するためにNginxのようなリバースプロキシの使用を推奨しています。

拡張可能な認証と認可

厳格な権限システムを構築するのではなく、Quackはコールバックベースのモデルを採用しています。認証（ユーザーが誰であるかを確認すること）と認可（ユーザーができることを決定すること）の両方を、ユーザーが提供するコードや単純なSQLマクロによってオーバーライドすることができ、LDAPやカスタムのテキストファイルベースの認証との統合が可能です。

パフォーマンス・ベンチマーク

プロトコルを検証するため、チームはAWS m8g.2xlargeインスタンス上で、PostgreSQLおよびArrow Flight SQLと比較してQuackをテストしました。

バルク・データ転送

Quackは、大量のデータを移動する際に大きな優位性を示します。TPC-Hの lineitem テーブルを転送するテストでは、Quackは6,000万行（CSV形式で76 GB）をわずか4.94秒で転送し、Arrow Flight (17.40s) や PostgreSQL (158.37s) を大幅に上回る結果を出しました。

小規模な書き込みスループット

複数のスレッドにわたる小規模でランダムな INSERT トランザクションのテストでは、Quackは低コンカレンシー（並行性）のシナリオにおいて、驚くべきことにPostgreSQLを上回り、8スレッド全体で約5,500トランザクション/秒に達しました。PostgreSQLは8スレッドを超えるとより良くスケールしますが、Quackは、オブザーバビリティとテレメトリ・データの集約に非常に効率的なパスを提供します。

なぜArrow Flight SQLではないのか？

Arrow Flight SQLプロトコルの存在を考慮すると、カスタムプロトコルを構築するという決定は意図的なものでした。チームは主に2つの理由を挙げました。

  1. イノベーションへの制御権: 外部の交換フォーマットを使用すると、DuckDBの新しいデータ型やプロトコル・メッセージを迅速に追加する能力が制限されてしまいます。
  2. ラウンドトリップの効率性: Arrow Flight SQLは、すべてのクエリに対して少なくとも2回のラウンドトリップ（CommandStatementQuery と DoGet）を必要とします。Quackは、レイテンシに敏感な小規模な更新のために、シングル・ラウンドトリップ実行用に設計されています。

今後の展望

Quackは現在 core_nightly リポジトリで利用可能であり、DuckDB v2.0 と共に2026年秋に本番リリースされる予定です。 今後の開発には以下が含まれます:

  • DuckLake Integration: リモートDuckDBサーバーをDuckLakeカタログとして使用し、パフォーマンスとデータのインライン化を向上させること。
  • Scaling Concurrency: コア・エンジンを改良し、8つ以上の並列挿入スレッドを大幅ににサポートすること。
  • Replication: Quackの上にレプリケーション・プロトコルを開発し、、リード・レプリカのクラスターを可能にすること。

インプロセス・エフィシェンシー（効率性）とクライアント・サーバーの柔軟性の間のギャップを埋めることで、QuackはDuckDBを、単なるローカル分析用のニッチなツールから、現代のデータ・アーキテクチャの核となる構成要素へと位置づけます。

Sources