追加サービスなしでS3上で完全なDuckDBデータベースを実行

エンジニアたちは、Amazon S3などのオブジェクトストレージ上で完全なDuckDBデータベースを直接実行する手法を開発しました。これにより、個別のデータベースサーバーや複雑なデータレイクカタログが不要になります。2026年10月に発表されたこのアプローチでは、duckdb_objfsというカスタム拡張機能を使用し、DuckDBの内部ストレージエンジンをクラウドオブジェクト向けに設計された埋め込み型キーバリューストアであるSlateDBにマッピングします。

何が起きたか

核心的な革新は、データベースがS3バケットをプライマリディスクとして扱えるようにするDuckDB拡張機能です。異なるエンジン間でParquetテーブルを共有することに焦点を当てたIcebergやDuckLakeといった既存のソリューションとは異なり、この手法はDuckDBの全機能を維持します。これには、高度なインデックス、制約、ビュー、マクロ、そしてオープンテーブルフォーマットへの変換時に失われたり不適切にマッピングされたりすることが多い特定のデータ型が含まれます。

このシステムでは、単一の書き込みプロセスがデータベースを更新している間、他の複数のプロセスが同じデータを読み取り専用モードでアタッチできます。これらのリーダーは、バケット内のデータに対してジョインや集計を含む複雑なSQLクエリを直接実行できます。アーキテクチャは、リーダーが最新の書き込みからわずかに遅れていても、データベースの一貫した状態を常に参照できるように保証し、更新中の部分的または破損した読み取りを防ぎます。

仕組み

この拡張機能は、DuckDBのストレージエンジン自体を変更するのではなく、基盤となるディスク層を置き換えることで動作します。duckdb_objfs://スキーム用のカスタムファイルシステムハンドラーを登録します。DuckDBがファイルの読み取りや書き込みを試みると、リクエストはCインターフェースを介してSlateDBを管理するRustコアに転送されます。SlateDBはアダプターとして機能し、Apache OpenDALを使用してファイル操作をオブジェクトストレージ呼び出しに変換します。OpenDALは、S3、MinIO、ローカルディレクトリなど、さまざまなバックエンドをサポートしています。

DuckDBのインプレースファイル更新と、不変性を持つオブジェクトストレージとの間のミスマッチを処理するため、システムはデータチャンクを正確に整列させます。各256 KiBのDuckDBブロックは、12 KiBヘッダーの後に開始されるSlateDB内の単一の256 KiBチャンクにマッピングされます。この幾何学的配置により、ブロックの書き込みには1回のput操作のみが必要となり、読み取りには1回のget操作のみで済むため、高コストな読み取り-修正-書き込みサイクルを回避できます。耐久性は、汚れたチャンクとメタデータを単一の書き込みバッチにまとめ、ファイル同期呼び出しが返る前にバケットへフラッシュすることで維持されます。

主要な詳細

• フルSQLサポート: このソリューションは、ARTインデックス、空間Rツリー、および標準的なParquetベースのテーブルフォーマットではサポートされていない実験的なHNSWベクトルインデックスなど、すべてのDuckDB機能を保持します。
• 単一書き込みモデル: データベースへの書き込みは一度に1つのプロセスのみ可能です。ライターフェンシングにより、より新しいライターが引き継いだ場合、古いライターにI/Oエラーが発生するようにして競合を防ぎます。
• 一貫した読み取り: 読み取り専用のアタッチメントは、フェンシングを行わないリーダーを使用し、10秒ごとにマニフェストのビューを更新することで、書き込み側をブロックせずに一貫性を保証します。
• パフォーマンス指標: Apple M4上では、コールドS3読み取りはネイティブHTTPFSより約1.2倍遅く、ネットワーク遅延のため、ローカル書き込み速度はネイティブローカルディスク書き込みの約0.19倍です。
• 追加サービスなし: デプロイメントにはS3バケットのみが必要です。SlateDBは書き込みプロセス内で調整、コンパクション、ガベージコレクションを処理するため、外部カタログサービスが不要になります。
• Duckherderとの統合: このストレージ層は、複数のワーカーが同じバケットからパーティション化されたデータを読み取り、並列クエリ処理を行う分散実行エンジンであるDuckherderの基盤となります。

なぜ重要なのか

ソフトウェアエンジニアやデータチームにとって、このアプローチはデータベースサーバー、バックアップ、高可用性クラスタの管理に伴う運用負荷を排除することでインフラストラクチャを簡素化します。バケットが唯一の信頼できる情報源（Single Source of Truth）となり、プロビジョニング、セキュリティ確保、監視が必要なコンポーネントの数が減少します。これは、従来のデータベース管理の複雑さなしにリレーショナルデータベースのパワーを求めるセルフホスト型アプリケーションや小規模なチームにとって特に価値があります。

しかし、トレードオフには遅延と書き込みスループットが含まれます。すべてのコミットにはオブジェクトストレージへの往復が必要になるため、書き込みが多いワークロードはローカルディスク操作よりも大幅に遅くなります。エンジニアはアプリケーションを設計する際に、小さな書き込みをバッチ処理し、読み取り専用レプリカが最大10秒遅れる可能性があることを受け入れる必要があります。このモデルは、データの追加や更新が頻繁ではなく、複数のユーザーやサービスによって頻繁にクエリされる分析ワークロードに最適です。

実施可能なこと

• ワークロード適合性の評価: アプリケーションがS3書き込みの遅延と10秒の読み取り遅れを許容できるかどうかを判断してください。このモデルは、高頻度のトランザクションシステムよりも分析ダッシュボードに適しています。
• 書き込み操作のバッチ処理: 小さな更新をより大きなトランザクションにグループ化し、オブジェクトストレージバケットへの往復回数を最小限に抑えて、全体の書き込みスループットを向上させてください。
• 読み取り専用アタッチメントの使用: 同じデータベースに複数の読み取り専用プロセスをアタッチすることで、クエリ容量をスケールアウトし、書き込み側に影響を与えずに同時分析を可能にします。
• IO統計の監視: 提供されているduckdb_objfs_io_stats()およびduckdb_objfs_cache_stats()関数を使用して、リクエスト数、遅延、キャッシュパフォーマンスを追跡し、デバッグと最適化に役立ててください。
• 移行計画: バケットには標準的な.duckdbファイルではなくSlateDBオブジェクトが含まれているため、移行を計画してください。