2025年に向けた7つのデータベース
(matt.blwt.io)- さまざまな問題を解決するために注目する価値のあるDBを7つ紹介
- これは「最高のDB」リストではなく、新しく有用な視点を提供するツール群
- 2025年には、それぞれのDBに1週間ずつ投資してみてほしい（7 DBs in 7 Weeks）
1. PostgreSQL: 基本のデータベース
- PostgreSQLは定番として使われる安定した技術
- 「Just use Postgres」というフレーズは、広く知られたミームであり信頼性を象徴する表現
- ACIDに準拠し、物理・論理レプリケーションを含む強力な機能を提供
- 主要ベンダー間で幅広くサポートされている安定したデータベース
- PostgreSQL最大の魅力: 拡張性
- Extensionsによって独自機能を追加できる
- 主な拡張機能の例:
AGE: グラフデータ構造とCypherクエリ言語をサポートTimescaleDB: 時系列データ処理をサポートHydra Columnar: カラム指向ストレージエンジンを提供
- 拡張機能は、PostgreSQLを他のデータベースと差別化する中核要素
- PostgreSQLの有用性と拡張性
- 多様なエコシステムを持ち、デフォルト設定が合理的で使いやすい
- PostgreSQL以外のサービスでもPostgresワイヤープロトコルを使ってクライアント互換性を提供
- WebAssembly(Wasm)環境にもインストールできるほど軽量
- PostgreSQLの学習を推奨
- PostgreSQLの可能性と限界を理解するために、時間を投資する価値がある
- 例: MVCC(Multi-Version Concurrency Control)の複雑さを理解する
- シンプルなCRUDアプリケーションの開発や、PostgreSQL拡張機能の作成などを勧める
2. SQLite: ローカルファーストのデータベース
- SQLiteは「ローカルファースト」のデータベースとして単独で実行可能
- クライアント・サーバーモデルを離れ、アプリケーションと同じ環境で動作する
- 例: WhatsAppとSignalは、端末内でSQLiteを使ってチャットデータを保存している
- SQLiteの進化した活用例
- 基本的なACID準拠データベースを超えた創造的な使い方が可能
- 新しいツールと拡張機能:
Litestream: SQLiteのストリーミングバックアップを提供LiteFS: 分散アクセスをサポートし、より柔軟なトポロジーを実現CR-SQLite: CRDT(Conflict-free Replicated Data Types)を使い、変更セットのマージ時に競合解決の必要をなくす
- SQLite人気の再評価
- Ruby on Rails 8.0のおかげで再び注目を集めている
- 37signals: SQLiteをベースにRailsモジュール（Solid Queueなど）を開発
- Railsの複数SQLiteデータベース管理サポート（database.yml）
- Bluesky: Personal Data Serversとして、ユーザーごとに個別のSQLiteデータベースを使用
- SQLite活用の学習を推奨
- SQLiteを使ったローカル中心アーキテクチャの実験
- 既存のPostgreSQLベースのクライアント・サーバーモデルをSQLiteで置き換えられるか試してみる
3. DuckDB: 何でもクエリできるデータベース
- DuckDBはOLAPに特化した組み込みデータベース
- SQLiteのようにアプリケーションと一緒に動くが、OLTPではなくOLAP処理に重点を置く
- データ分析とクエリ中心に設計されたシステム
- DuckDBの「Query-Anything」特性
- さまざまなデータソースを直接SQLでクエリ可能:
- CSV、TSV、JSONなどの一般的なファイル形式
- Parquetなどの高度なファイル形式もサポート
- この機能は柔軟性をもたらし、たとえばBlueskyのデータストリーム分析にも使える
- さまざまなデータソースを直接SQLでクエリ可能:
- 拡張性とエコシステム
- DuckDBにも拡張機能はあるが、Postgresほど豊富ではない（比較的新しいプロジェクト）
- コミュニティ提供の拡張が多く、
gsheets（Google Sheets連携）は注目に値する
- DuckDB活用の学習を推奨
- PythonノートブックやEvidenceを通じて、データ分析や処理を試す
- SQLiteとの組み合わせ: SQLiteデータベースの分析クエリをDuckDBに委譲して性能を高める
4. ClickHouse: カラム型データベース
- ClickHouseはOLAP処理に特化したデータベース
- OLTPはPostgreSQL、OLAPはClickHouseという組み合わせが理想的
- 大規模な分析ワークロードを処理し、水平スケーリングとシャーディングによって高いデータ挿入速度を支える
- ClickHouseの主な特徴
- 階層型ストレージをサポート:
- 「ホットデータ」と「コールドデータ」を分けて保存できる
- 例: GitLabのドキュメントでは、この活用事例が詳しく説明されている
- 大規模データセット処理とリアルタイム分析:
- DuckDBでは扱いにくい規模のデータセットに適している
- リアルタイム分析が必要な場面で強力な性能を発揮
- 階層型ストレージをサポート:
- 運用のしやすさ
- デプロイ、拡張、バックアップなど運用関連のドキュメントが体系的かつ詳細
- 例: 適切なCPU設定方法まで扱うドキュメントが提供されている
- ClickHouseの学習を推奨
- 大規模分析データセットを試す、またはDuckDBで行った分析をClickHouseへ移行する
- ClickHouseの組み込み版である
chDBを使えば、SQLiteとより直接的に比較できる
5. FoundationDB: レイヤードデータベース
- FoundationDBは「データベースの土台」として機能するユニークなシステム
- キー・バリューストアとして設計されているが、単なるデータベースというよりデータベースを構築するための「基盤」として動作する
- Apple、Snowflake、Tigris Dataのような主要企業で利用されている
- 主な特徴と制限
- 制約事項:
- トランザクションデータは10MBを超えられない
- トランザクションは最初の読み取りから5秒を超えられない
- こうした制約により、大規模環境でも完全なACIDトランザクションを提供できる
- 例: 100TiB超のクラスター運用事例
- 制約事項:
- FoundationDBの設計とテスト
- 特定のワークロード向けに最適化して設計されている
- シミュレーションテストによって安定性と拡張性を実証:
- Antithesisや他のデータベースでも同じテスト手法が使われている
- 関連参考資料: Tyler NeelyとPhil Eatonの文書
- 「レイヤード」データベースとしてのFoundationDB
- ストレージエンジンとデータモデルの結び付きが緩い:
- さまざまなレイヤーでストレージエンジンを再マッピングできる
- 例: Recordレイヤー、Documentレイヤー（FoundationDB組織が提供）
- Tigris Dataが作成したレイヤー設計事例は参考になる
- ストレージエンジンとデータモデルの結び付きが緩い:
- FoundationDBの学習を推奨
- チュートリアルを進めながら、RocksDBのようなシステムを置き換える可能性を探る
- 設計手法（Design Recipes）と関連論文を読む
- Anti-FeaturesとFeaturesの文書を通じて、利用上の制限と解決できる問題を理解する
6. TigerBeetle: 徹底して正確なデータベース
- TigerBeetleは金融トランザクションに特化した単一目的データベース
- 汎用データベースとは異なり、特定用途、特に金融取引に焦点を当てている
- オープンソースで提供され、高い信頼性と正確性を目標に設計されている
- 徹底した正確性のための設計思想
- NASAのPower of Ten RulesおよびProtocol-Aware Recoveryを実装
- strict serialisabilityとDirect I/Oの採用により、カーネルのページキャッシュに関する問題を回避
- Safety docや独特のプログラミングスタイル「Tiger Style」から、その徹底ぶりを確認できる
- Zig言語で実装された革新的アプローチ
- Zigは比較的新しいシステムプログラミング言語だが、TigerBeetleの目標に理想的に合致している
- 簡潔さと性能を最大化するうえで、Zigの利点が活かされている
- TigerBeetleの学習と活用の提案
- ローカル配備環境で金融口座モデリングを試す:
- Quick Startに従ってインストールして使ってみる
- System Architecture docsを参考にしながら、汎用データベースとの組み合わせ可能性を探る
- 例: PostgreSQLやFoundationDBと統合し、ユースケースを広げる
- ローカル配備環境で金融口座モデリングを試す:
7. CockroachDB: グローバルデータベース
- CockroachDBはグローバル分散データベース
- PostgreSQLワイヤープロトコルと互換性があり、水平スケーリングと強整合性をサポート
- Google Spannerに着想を得た設計で、複数リージョンにまたがるデータベース拡張を可能にする
- CockroachDBの主な技術的特徴
- 時刻同期技術:
- Google Spannerは原子時計とGPS時計を使うが、CockroachDBは一般的なハードウェアでも動作するよう設計されている
- NTPベースの同期遅延補正、ノード間のクロックドリフト比較、最大オフセット超過時のメンバー終了
- マルチリージョン構成:
- Table Localities機能によって、読み書きのトレードオフに応じた最適化が可能
- データをユーザーの地理的位置に合わせて分散し、性能とレイテンシを改善する
- 時刻同期技術:
- CockroachDB活用の学習提案
- MovRサンプルの再実装:
- 好きな言語とフレームワークでMovR（分散アプリケーションのサンプル）を実装する
- CockroachDBのマルチリージョン戦略とスケーリング戦略を活かし、グローバルアプリケーション設計を試す
- MovRサンプルの再実装:
- CockroachDBを選ぶ理由
- DynamoDBのような他の分散データベースと違い、ローカル環境で無料で動かせる
- 強整合性とグローバル分散対応という差別化された特性を提供
Wrap Up
- 紹介したデータベースは、それぞれ異なる問題や要件を解決するために設計されている
- 2025年は、これらのデータベースを学びながら、より面白く創造的な問題解決の方法を探ってみよう！
14件のコメント
何でもクエリ！ 😆🐤
DuckDB の分析パフォーマンスが思った以上に優れていて驚きました。
ここ数か月、sqliteで日付別の200万件・5GB規模のデータを処理する作業を行っています。
処理速度には満足しているのですが……これを加工した後、再びExcelにして関係者に提供するまでの時間が長すぎます。
OpenPyXlを使う方法をもう少し調べる必要がありそうです。
どんなマジックがあるのかは分かりませんが、
duckDB+sqliteの組み合わせを使うようですね。意外にも MongoDB には言及されていませんね。
開発者の学習コストが気になる環境なら、SQLiteをおすすめします。ファイルベースなので簡単です。
リモートアクセス要件がないことが確実であれば、本当に満足度の高いソリューションです。DBの管理ポイントがなくなり、データ編集、バックアップ/復旧も簡単で良いです
SQLite を使うと言うと叩かれやすいのに、SQLite を使っていたと話すまでは誰も気づかなかったりもしますね……。SQLite は思っているよりずっと良いです。
もう何十年（？）もMySQLしか使っていないのですが、
PostgreSQLはどうなのか、実務で本番環境にPostgreSQLを使っている方々の多くのコメントを期待しています。
「ゾウはアザラシより優れています」
これはほとんどの場合に当てはまります
笑笑笑笑
2001年にバグだらけのmysql（当時v3.x）からpgsqlに移行しました。
優れていると思う点は多いですが……実際の現場では、Partial Indexの存在が最も強力な機能だと思います。
仕事で Oracle と SQL Server しか使ってこなかったので、MySQL を使おうとしてみると、本当に「なぜこれができないんだ？」と思うことがあまりにも多かったです。私も正確にはもう覚えていません。
結局は Postgres に移行しました。
Postgres を使っていてから MySQL を使う環境に来ると、感覚的に「なぜこれができないんだ？」「なぜこれで性能が出ないんだ？」と思うことがかなりあります。
正確に何だったかはあまり覚えていません（些細なことかもしれないし、そうでないかもしれません）