目的
本稿では、DuckDBがもたらす新しいシステム設計の可能性を探ります。特に、2024年時点で主流な「スケールアウト」モデルを前提としたデータ処理システムから、よりシンプルで効率的な「スケールアップ」モデルが将来的に主流となり得る理由を説明します。また、DuckDBの技術的特性、注目されている理由、具体的なその用途についても詳しく解説します。
対象読者
- ソフトウェアアーキテクト：システム設計や運用コストの最適化を検討している人
- データエンジニア：アプリケーションデータやログデータなどの様々なデータセットを効率的に処理したい人
- システム管理者・運用者：クラウドコストの削減や効率的なデータ処理システムを模索している人
概要
DuckDBは、シンプルなシステム設計を可能にする列指向データベースエンジンとして注目を集めています。
BigQueryやRedshiftなどを代表とする従来の「スケールアウト」モデルでは、複雑なクラスターの構成や管理が必要であり、費用や運用負荷が増大する問題を抱えています。一方、DuckDBは比較的運用コストの低いシングルノードで動作し、非常に高速なデータ処理を提供します。
これにより、複雑性や運用コストの課題を抱える「スケールアウト」モデルのシステム設計から、シンプルかつ安価で運用しやすい「スケールアップ」モデルのシステム設計が今後の主流となり、DuckDBはその先駆けになると考えられます。
「スケールアウト」モデルの台頭とシステム課題
Googleによるスケールアウト革命
「スケールアウト」モデルの始まりは、2000年代初頭のGoogleにまで遡ります。当時Googleは、年々増加するWebサイト数に対応可能な検索エンジンを構築するために、システム設計の抜本的な改善を図りました。その時に発明された新しい計算モデルが「スケールアウト」モデルです。これは、高価で高性能なハードウェアを導入する代わりに、安価で一般的な性能のハードウェアを大量に利用し、ソフトウェアによって高いスケーラビリティを実現するモデルです。
このようなGoogleのスケールアウト革命は、今日に至るまで私たちのシステム設計に大きな影響を及ぼしています。実際、2024年時点でのシステム開発において、本格的な実行アーキテクチャを設計する場合、スケールアウトによる拡張性や弾力性は重要なアーキテクチャ特性と考えられています。
また、Google CloudにおけるBigQueryやDataflow、AWSのRedshiftやAmazon Managed Service for Apache Flinkなど、パブリッククラウドのマネージドサービスでも「スケールアウト」モデルを利用した製品が多く存在します。
2000年代初頭にGoogleは以下3つの論文を発表し、「スケールアウト」モデルの礎を築きました。
スケールアウトの普及に伴うシステム課題
汎用的なハードウェアを組み合わせてシステム全体の処理能力を高める「スケールアウト」モデルには、その普及と共に以下のような課題点も見つかりました。
- 複数のハードウェア上でスケールアウト可能な処理の設計やシステムの開発が難しい
- 処理をスケールアウトさせるとデータ整合性担保、実行ステータス監視、エラー対応が難しい
このようなシステム課題が「スケールアウト」モデルによってもたらされ、2024年時点でのソフトウェア開発は、処理の複雑化や運用負荷の増大に直面しています。
更に、BigQueryやRedshiftなど一部のクラウドマネージドサービスでは、スキャンしたデータ量に応じて料金が発生します。そのため、一処理あたりの費用を考慮しながらクエリを実行しなければならない、という難しさにも直面しています。
「スケールアップ」モデルへの回帰と将来性
ムーアの法則によるハードウェア性能改善
スケールアウト革命後、ソフトウェア開発者が複雑性と運用コストの増大に直面する中、ハードウェアは目立たずとも刻々と進化を続けてきました。
1965年に提唱されたムーアの法則のとおり、半導体の性能はこれまで指数関数的に向上しています。つまり、Googleが「スケールアウト」モデルを発明した2000年代初頭から2024年時点までの20数年間で、ハードウェアの劇的な性能改善が実現されました。
具体的には、以下の図に示すグラフのとおり、これまでの20年間でトランジスタ密度は1000倍に増加しました。これにより、2002年当初では数千台のハードウェアを必要とした処理が、2020年時点ではわずか1台で実現可能となったのです。
このようなムーアの法則に沿ったハードウェアの性能改善を踏まえて、私たちは自身のシステムにとって「スケールアウト」モデルが本当に最適解なのかを考え直す時が来たと言えます。
引用：Max Roser, Hannah Ritchie and Edouard Mathieu (2023) - “What is Moore's Law?” Published online at OurWorldinData.org. Retrieved from: 'https://ourworldindata.org/moores-law' [Online Resource]
仮想化技術の発展に伴うハードウェア調達効率化
Googleが「スケールアウト」モデルを発明してからの約20年間で、ムーアの法則に沿ったハードウェア自体の性能改善だけでなく、ハードウェア内部の仮想化技術も大きな発展を遂げました。
具体的には、以下の図のとおり、2000年代初頭から普及している仮想マシン技術だけでなく、コンテナやサーバレスといった画期的な仮想化技術も2024年時点では広く一般化しています。
また、パブリッククラウドの普及に伴い、これらの仮想化技術を駆使した様々なタイプのコンピューティングリソースが誰でも簡単に調達可能となりました。
つまり、高性能なハードウェアであっても、必要な時に必要な分のコンピューティングリソースとして、現実的な価格で効率的に利用できるようになったと言えます。
以上のことから、1台の高性能なハードウェア、または用途に合わせて適切に仮想化されたコンピューティングリソースによる「スケールアップ」モデルを採用することで、よりシンプルにシステムを設計し、より効率的に処理を実装できると考えられます。
引用：uzairsaleem90 (2019) - “Cloud Computing Services – Cloud Computing” Published online at usdynamics365.wordpress.com. Retrieved from: 'https://usdynamics365.wordpress.com/2019/09/17/cloud-computing-services-cloud-computing/' [Online Resource]
DuckDBの登場とその特性
DuckDBとは
DuckDBは、大量のデータセットを単一のローカルマシン上で高速に処理できる、モダンで軽量な組み込み分析データベースです。
従来のデータベースとは異なり、列指向のベクトル化されたクエリエンジンによって、データを並列に処理し、ハードウェアに搭載されたマルチコアCPUの性能を十分に引き出すことが可能です。更に、ストリーミング実行エンジンによって、データソースから部分的にデータを読み取り、メモリリソースを効率的に管理しながら、クエリを高速に実行できます。
なお、DuckDBの主な特性としては、以下の3つが挙げられます。
- OLAPに特化し、数百ギガバイトのデータを効率的に処理できる
- 一般的なSQLを利用し、複雑な分析処理でも柔軟かつ簡潔に表現できる
- 異なるデータソースから様々な形式のデータセットを収集し、同一クエリ内でまとめて処理できる
また、DuckDBの典型的な使用方法は、以下の概念図のように整理できます。
引用：Mark Needham, Michael Hunger, Michael Simons (2024) - “An Introduction to DuckDB” Published online at motherduck.com. Retrieved from: 'https://motherduck.com/duckdb-book-summary-chapter1/' [Online Resource]
DuckDBが注目される理由
DuckDBは軽量な組み込みデータベースでありながら、数百ギガバイトの分析データを効率的に処理できるため、以下の図に示す(2025年1月3日時点での)ランキングのように、注目が集まっています。
SQLiteを代表とする従来の組み込みデータベースは、OLTPに特化し、トランザクション制御を必要とする軽量な処理を得意としています。ただし、行指向のクエリエンジンのため、データ量の増加に伴う性能悪化の懸念があります。更に、データセットのファイル形式やデータファイル配置先の柔軟性が低く、軽量なアプリケーションなどに用途が限られてしまいます。
また、OLAPに特化したBigQueryやRedshiftを代表とする従来のDWHは、列指向ストレージとベクトル化されたクエリエンジンを搭載し、大量のデータを高速かつ効率的に処理できます。しかし、複数のハードウェアやコンピューティングリソースから構成される大規模なクラスターのセットアップや管理が必要であり、複雑性や運用負荷増大の懸念があります。更に、スキャンしたデータ量に応じて料金が発生する製品の場合、費用を計算しながらクエリを実行しなければならず、データ分析業務の効率化を妨げる可能性があります。
これらに対し、DuckDBは軽量な組み込みデータベースとしての扱いやすさだけでなく、大量データの分析処理を実現できる高性能なクエリエンジンを搭載し、異なるデータソースからの様々な形式のデータセットを一度に取り扱える柔軟性を有しています。更に、DuckDBはOSSであるため、どれだけクエリを実行しても料金は発生せず、必要なのは動作環境となるコンピューティングリソースの調達費用だけです。
※ Ranking on January 3rd, 2025
引用：“Last 28 Days / Month-to-Month Ranking” Published online at ossinsight.io. Retrieved from: 'https://ossinsight.io/collections/open-source-database/' [Online Resource]
DuckDBの具体的なユースケース
異なるデータソースからのデータセットを組み合わせたETLパイプライン
異なる複数データソースからの大量データセットを取り扱うETLパイプラインを構築する場合、従来ではBigQueryやRedshiftを利用したDWH上での分散クエリ実行、またはDataflowやAmazon Managed Service for Apache Flinkを利用した分散データ処理基盤での分散バッチ処理で実現する方法が一般的でした。
しかし、DWHを利用する場合、クラスターの管理負荷だけでなく、分散クエリの実行単位で費用がかかります。また、分散データ処理基盤を利用する場合、分散バッチ処理を実現するためにApache Beamのようなプログラミングモデルで実装する必要があり、学習コストや設計・開発負荷が増大すると考えられます。
そこで代替策として、DuckDBを用途に合わせて仮想マシン、コンテナ、サーバレス環境にデプロイし、ETLパイプラインをDuckDBのSQLで実装します。
これにより、設計・開発・運用負荷を軽量化しながら、異なるデータソースからのデータセットを組み合わせた処理が実現可能となります。
具体的には、DuckDBの拡張機能を利用し、各種データソースからの読み込みやデータシンクへの書き込み処理をSQLで実装できます。
DuckDBの代表的な拡張機能として、以下のようなものが公式提供されています。
大量のファイルに記録されたアクセスログ解析
AWS上のS3バケットに蓄えられた大量のアクセスログファイルを処理する場合、従来ではRedshiftやAthenaを利用する方法が一般的でした。
しかしながら、これら「スケールアウト」モデルのデータベースは、複雑なクラスター管理に伴う運用負荷が大きく、クエリ実行ごとに費用も嵩む傾向があります。
そこで代替策として、DuckDBをEC2の仮想マシン内にデプロイし、DuckDBから直接S3バケットにクエリを実行します。
これにより、運用コストを抑えつつ高速にデータを処理できます。
具体的には、DuckDB CLIをEC2の仮想マシン内で起動し、以下のようなクエリを実行することで、特定S3バケット内の複数ファイルから、必要なアクセスログのみを高速かつ簡単に取得できます。
-- 特定のS3バケット内からParquet形式のログファイルを複数参照し、日付条件に合致するアクセスログを取得
SELECT * FROM read_parquet('s3://my-bucket/*.parquet') WHERE date = '2025-01-03';
また、エビデンスとして取得結果を所定のファイル形式で提示しなければならない場合、以下のようにデータ形式を指定し、別ファイルにクエリ実行結果を出力可能です。
-- 特定のS3バケット内から日付条件に合致するアクセスログを取得し、CSVファイルとして実行結果を出力
COPY (SELECT * FROM read_parquet('s3://my-bucket/*.parquet') WHERE date = '2025-01-03') TO 'output.csv' (HEADER, DELIMITER ',');
データベース移行期間中の新旧テーブルデータ比較
データベース移行期間中にアプリケーション処理の正常動作を検証する目的で、移行前後の各データベースにおける新旧テーブルデータを比較する場合、従来ではpg_dumpなどを利用して片方のデータベースにテーブルデータを複製する方法が一般的でした。
しかし、この方法では、dumpファイルの作成、及びテーブルデータのリストアにかかるオーバーヘッドや、作業負荷が大きくなる傾向にあります。
また、BigQueryやRedshiftを利用したDWH上でのテーブルデータ比較を実施しても、クラスターのセットアップや管理に伴う追加の運用負荷がかかり、テーブルデータのフルスキャンによってクエリ実行費用も比較的大きくなるため、より良い解決策にはなりません。
そこで代替策として、DuckDBを仮想マシン内にデプロイし、DuckDBから移行前後の各データベースに対して直接クエリを実行します。
これにより、テーブルデータ比較前のデータダンプが不要となるため、高速かつ簡単に新旧テーブルデータの比較処理が実現できます。
具体的には、DuckDB CLIを仮想マシン内で起動し、以下のようなクエリを実行することで、移行前後の各データベースから、新旧それぞれのテーブルを参照し、単一クエリ内で効率的にデータを比較できます。
-- 異なる2つのPostgreSQLデータベース間でテーブルデータの差分を抽出 (新 - 旧)
SELECT *
FROM postgres_scan('host=new_host dbname=new_db user=my_user password=my_password', 'my_schema', 'my_table')
EXCEPT
SELECT *
FROM postgres_scan('host=prev_host dbname=prev_db user=my_user password=my_password', 'my_schema', 'my_table');
-- 上記のクエリ実行結果とは逆向きのデータ差分を抽出 (旧 - 新)
SELECT *
FROM postgres_scan('host=prev_host dbname=prev_db user=my_user password=my_password', 'my_schema', 'my_table')
EXCEPT
SELECT *
FROM postgres_scan('host=new_host dbname=new_db user=my_user password=my_password', 'my_schema', 'my_table');
【補足】DuckDBを使うべきではない場面
以下のような場面では、DuckDBの良さを十分に活かしきれないため、使うべきではないと考えられます。
- テラバイト級のデータ分析処理を実行する場面
- 厳格なトランザクション管理や、並列書き込みに対する排他制御を必要とする場面
- ストリーミングデータをリアルタイム、またはニアリアルタイムに処理する場面
- Message QueueやPub/Subモデルの非同期メッセージング用データソース・データシンクを利用する場面
今後の展望
本稿前半では、複雑性や運用コストの課題を抱える「スケールアウト」モデルに代わり、シンプルかつ安価で運用しやすい「スケールアップ」モデルがシステム設計の主流となり得る理由を説明しました。
そして、「スケールアップ」モデルの先駆けとして注目されている、DuckDBの技術的特性や、その用途について解説しました。
また本稿後半では、主にDuckDBの基礎的な使い方や、単体で利用する場合のユースケースを中心に紹介しました。
しかしながら、DuckDBの真価は、他のソフトウェアと組み合わせることで発揮されます。
具体例としては、以下のようなものが挙げられます。
-
Modern Data Stack：単一マシン上での高速なパイプライン処理を実現できるデータ活用基盤
- DuckDB、Meltano、dbt、Apache Supersetの組み合わせ
-
BemiDB：分析用途に最適化されたPostgreSQL向けリードレプリカ
- DuckDB、Apache Icebergの組み合わせ
これらを踏まえて、今後はDuckDB本体だけでなく、DuckDB周辺の関連ソフトウェア技術も積極的にキャッチアップし、継続的な情報発信に取り組みたいと考えています。