ハクソク

世界を動かす技術を、日本語で。

クワック: DuckDB クライアント-サーバープロトコル

10時間前原文(duckdb.org)

概要

  • 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は クライアント・サーバ型 運用が公式サポート
  • シンプル・高速・拡張性 を兼ね備え、多様なユースケースに対応
  • 詳細は 公式ドキュメント 参照

Hackerたちの意見

DuckDBは好きだけど、何を目指しているのかよくわからないな。使い方が常に新しくて、正しい使い方を見つけるのが難しい。

└

+1 これとArrow Flightの使い道って、データを移動させる以外にあまり思いつかないな。

└

私たちのデータパイプラインは、アプリがダウンロードする.duckdbファイルを生成してるんだ（S3のアセットを監視して、etagが変わったら引っ張ってくる）。これで、BQやClickhouseみたいなパフォーマンスを、インフラを運用したりお金を払ったりせずに得られるから楽だよ。すべてのケースに完璧ではないけど、思っている以上に多くのことをこなしてくれる。

└

「DuckDBがPostgresになりたい」ってよりは、DuckDBが大きなワークフローの中の実行レイヤーになっていく感じかな。エンジン自体はもうそんなに苦痛じゃないし、周りのことが問題なんだよね。ライブDBやS3パス、Parquetファイル、認証情報、繰り返し実行、エクスポート、バリデーション、そして一度きりのスクリプトがいつの間にかインフラになる瞬間。Quackはリモートやサーバー部分をクリーンにしてくれるけど、全体的な流れとしてはDuckDBがツールの中のSQLレイヤーになっていく感じで、必ずしも最終的なユーザー向けのツールになるわけじゃないと思う。

└

DuckDBはスタンドアロンでもあり、コンポーネントでもある。この取り組みは実際にとても整合性があって、伝統的なクライアントサーバーRDBMSの使い方に戻してくれるね。RDBMSは常にマルチユーザーの同時システムだったし。DuckDBは非常に高速なローカルエンジンで、他のシステムに埋め込めるから、使い道がたくさんあるんだ。SQLiteが何になりたいかって言ってるようなもんだよね。スマホやブラウザ、デスクトップアプリ、IoTデバイスに入ってて、人々は色んな方向に拡張してる。ここでの唯一の違いは、これはファーストパーティーであってサードパーティーじゃないってこと。でも、私にとっては非常に分かりやすい動きだと思う。

チームの共有サーバーに置きたい小規模な内部分析用データセットには便利そうだね。ホームラボで使うのを探ってみるのもアリかも。

└

ducklakeを使えば、マルチテラバイトのデータセットにもスケールするよ。このサーバープロトコルの大きな利点は、高メモリサーバーを共有して、最近のデータに対して共有キャッシュを活用できることだね。

DuckDBをDuckLakeのカタログデータベースとしてQuackと一緒に使えますか？ > まだだけど、今取り組んでるよ！ニッチな使い方みたいだけど、私が一番興味あるやつだね。私たちのレイクハウスは、カタログとしてPostgresを使ってducklakeを利用してる。DuckDB/Quackのカタログは素晴らしい代替手段になりそう。

└

そうなんだ、実際に取り組んでるよ: https://github.com/duckdb/ducklake/pull/1151 だから、数日中にはテストできるようになるよ。

└

Quackは将来的にDuckLakeのカタログの主要な選択肢になると思う。いくつか理由を挙げると、1. インライン時の型の不一致がない。非DuckDBカタログを使うと、多くの型が1:1のマッピングがなくて、データ型を操作する際に追加のオーバーヘッドが発生する。2. カタログに対してDuckDBの分析（今はトランザクションも）をそのままのパフォーマンスで得られる。DuckDBがDuckDBを読むのは、私たちのPostgres/SQLiteスキャナーよりも単純に速い。3. リトライのための往復がない。DuckDBサーバー側で完全なリトライロジックを簡単に（tm）実行できる。今は、これらのリトライがPostgresで複数の往復を引き起こしていて、高い競合のワークロードではパフォーマンスのボトルネックになってる。注意：私はduckdb/ducklakeの開発者です。

これ、すごいね！うちの会社の内部アプリフレームワークでDuckDBを使おうと思ってたんだけど、「どうやって水平スケールするの？」って問題が解決したよ。DuckDBの人たちに感謝！プロトコル名の「Quack」も好きだな。

C++のアプリを持ってるんだけど、実行中は全てメモリにあるんだ。セッション間でXMLとしてディスクに保存してる。すごくうまくいってるけど、厳密に言うとシングルユーザー専用で、顧客の中には複数の同時ユーザーが読み書きできるようにしてほしいって人もいるんだ。パフォーマンス要件はかなり低くて、数千レコードを2、3人が同時に更新する程度なんだけど。DuckDB + Quackはこれに良い選択肢になるかな？それとも他にもっといい選択肢がある？SQLiteも見たけど、クライアントサーバーとしては動かないって聞いた。

└

DuckDBは主に分析用だよね。サーバーサイドでホスティングしない限り、同時ユーザーを扱えるDBの良い選択肢は見つからないと思う。確かに可能だけど（例えば、いくつかのゲームが直接マルチプレイヤー用のクライアントサーバーを作るように）、正直、PostgresやSQLiteをホスティングするのはめちゃくちゃ安くて簡単だし、何よりこの問題に対する標準的なアプローチだよ。

└

あなたが探している用語は「ローカルファースト」だと思うよ。

└

https://firebirdsql.org は、数十年にわたってSQLiteと本格的なPostgreSQLの間で目立たない存在だったけど、クライアントサーバー型のデータベースを選ぶなら、PostgreSQLがデフォルトのおすすめだよ。

最初に思ったのは、SSH越しに自己複製するDuckDBラッパーを設定して、どのコンピュータでもクエリを実行できるようにすることだね。これで遊ぶのが待ちきれない！

これ、素晴らしいね。DuckDBを使ってExcelのようなカラム型スプレッドシートアプリを作ってるんだけど、クラシックなHTTPレイヤーを通して「クライアント」を再発明しなきゃいけなかった。

先週、こんなのがあればいいなって思ってたばかりなのに、タイミング最高だね。今、DenoサーバーでセンサーのデータをDuckDBに流し込んでるんだけど、サーバーをシャットダウンしないとDuckDBの-uiでデータを確認できなくて困ってたんだ。サーバーを使ってDBの中身を見るつもりはなかったから、今はそれで我慢しようと思ってたけど、これで完璧に解決できるし、DuckDBで遭遇した他の似たような問題も一緒に解決できそう。DuckDBは2025/26年の僕のお気に入り技術だよ。僕のワークフローにめっちゃ組み込まれてる。LLMとの作業、いろんなデータの保存、分析、データパイプライン…ほんと好きなんだ。

「DuckDBは何になりたいのか」って質問がよく出るけど、もう答えは明らかだと思う。分析のためのSQLiteになりたいんだよ。埋め込み型で、設定不要、どこでも動く。Quackは「どこでも」の部分をリモートも含めるための要素なんだ。

これはめっちゃワクワクするね。今度はPostgres用にもこれが必要だね。