スキーマ設計パターン：まとめ
ブログシリーズ「スキーマ設計パターン（原題：Building with Patterns）」の最終回として、各パターンが解決する課題と、長所・短所をまとめます。スキーマ設計に関してよくある質問に「○○を行うためのアプリケーションの設計において、データのモデリングはどうすればよい？」というものがあります。このブログシリーズの過去の回でも解説したように、この質問に回答するには多くの考慮すべき点があります。今回の記事では、一般的なユースケースに対するデータモデリングの各パターンの概要をテーブルにしてみました。
サンプルユースケース
下記のテーブルは、MongoDB が長年の経験から導き出した、さまざまなアプリケーションに採用されているスキーマ設計のパターンの傾向を示しています。これは特定のアプリケーションタイプに対してどのデザインパターンを使用するべきかを示す「固定された」ルールではありません。ご自身のユースケースでよく使用されているパターンを確認することが重要です。ただし、他のパターンも選択肢から完全に除外せずに検討する価値があります。アプリケーションのデータスキーマの設計は、データアクセスパターンによって大きく変わる可能性があります。
設計パターンの概要
近似
近似パターンは、リソースを多く消費する計算を頻繁に行う場合や、計算の精度が最優先でない場合に役立ちます。
長所
- データベースへの書き込み回数が減る。
- 統計的に有効な数字を維持できる。
短所
- 正確な数字が示されない。
- アプリケーション内での実装が必要。
属性
属性パターンは、ドキュメントに多くの類似したフィールドがあり、その中に共通の特性を持つフィールドのサブセットが存在する場合に役立ちます。特に、そのサブセットでソートやクエリを行う必要があるときに効果的です。また、ソートが必要なフィールドがドキュメントの一部にしか含まれていない場合や、状況が混在している場合にも有効です。
長所
- インデックスが少なくて済む。
- クエリの記述がシンプルになり、全般的に実行速度が速くなる。
バケット
バケットパターンは、時系列データ、リアルタイム分析、モノのインターネット（IoT）のアプリケーションなど、ストリーミングデータの管理が必要な場合に最適です。
長所
- コレクション内のドキュメント数を削減できる。
- インデックスの性能が向上する。
- 事前集計を活用することで、データアクセスが簡素化される。
コンピューテッド（計算の再利用）
計算を再利用するコンピューテッドパターン は、データへのアクセスが読み取り中心であり、さらに、読み取ったデータをアプリケーションで繰り返し計算するケースに適しています。
長所
- 頻繁な計算による CPU への負荷を軽減できる。
- クエリの記述がシンプルになり、全体的に実行速度が速くなる。
短所
- コンピューテッドパターンが必要かどうかをの特定が困難。
- 必要な場合を除き、このパターンの過剰な使用は避けるべきである。
ドキュメントのバージョン管理
MongoDB でドキュメントの旧バージョンを管理する必要がある場合は、ドキュメントのバージョン管理パターンが有用です。
長所
- 既存のシステムにも容易に実装できる。
- 最新の修正に対するクエリの性能に影響しない。
短所
- 書き込み回数が 2 倍になる。
- 適切なコレクションに対してクエリを実行する必要がある。
拡張リファレンス
頻繁にアクセスするデータを集約するために JOIN（結合）操作を多用するアプリケーションには、拡張リファレンスパターンが最適です。
長所
- JOIN操作が多くある場合に性能が向上する。
- 読み込みが速くなり、JOIN の回数を削減できる。
短所
- データの重複が発生する。
外れ値
一般的なデータパターンに合わないクエリやドキュメントが一部存在し、これらの例外がアプリケーションに影響を与えている場合には、 外れ値パターンが有効です。
長所
- 一部のドキュメントやクエリがアプリケーションに影響を及ぼすのを防げる。
- クエリは一般的なユースケースに合わせて最適化されており、外れ値にも対応できる。
短所
- 特定のクエリにあわせて作成されていることが多く、アドホッククエリが適切に機能しないことがある。
- 実装にはアプリケーションのコーディングが必要になるケースが多い。
事前割り当て
ドキュメントの構造が事前に決まっており、その構造にデータを当てはめるだけでよいアプリケーションの場合は、事前割り当てパターンが最適です。
長所
- ドキュメントの構造が事前にわかっている場合は、設計を簡素化できる。
短所
- 簡素化できる一方で性能が低下する。
ポリモーフィック
相違点よりも類似点が多いドキュメントが複数あり、それらを 1 つのコレクションに保持する必要がある場合は、ポリモーフィックパターンが有効です。
長所
- 実装が容易。
- クエリを 1 つのコレクション全体に実行できる。
スキーマのバージョン管理
多くのアプリケーションでは、ライフサイクルの中でデータスキーマが頻繁に変更されるため、 スキーマのバージョン管理パターンが役立ちます。このパターンを使用すると、ドキュメントの以前のバージョンと現在のバージョンを同じコレクションに共存させることができます。
長所
- ダウンタイムがない。
- スキーマの移行を制御できる。
- 将来的な技術的負債を軽減できる。
短所
- 移行中に同じフィールドに対して 2 つのインデックスが必要になることがある。
サブセット
サブセットパターンは、大きなドキュメントの中でアプリケーションが使用しないデータが多く、ワーキングセットが RAMの 容量を超えてしまう問題を解決します。
長所
- ワーキングセット全体の大きさを縮小できる。
- 使用頻度の高いデータのディスクアクセス時間を短縮できる。
短所
- サブセットの管理が必要。
- 追加のデータを取得するには、データベースへの追加アクセスが必要。
ツリー
データが階層的な構造を持ち、頻繁にクエリが実行される場合には、ツリーパターンの実装が適しています。
長所
- 複数の JOIN 操作が不要になり、性能が向上する。
短所
- グラフの更新はアプリケーションでの管理が必要。
おわりに
今回のブログシリーズでは、MongoDB のドキュメントモデルがデータモデリングに非常に高い柔軟性を持つことを紹介しました。ただし、この柔軟性を最大限に活用するためには、アプリケーションのデータアクセスパターンに合わせて設計することが重要です。MongoDB でのスキーマ設計は、アプリケーションのパフォーマンスに大きく影響を与えるため、慎重に行う必要があります。多くの場合、パフォーマンスの問題は不適切なスキーマ設計が原因で発生します。
ドキュメントモデルの利点を最大限に引き出すために、適切な状況で複数のスキーマ設計パターンを組み合わせて使用できます。例えば、スキーマのバージョン管理は、アプリケーションの進化にあわせて、他のどのパターンとも併用可能です。本ブログシリーズで紹介した12のスキーマ設計パターンを使用することで、MongoDB のドキュメントモデルの柔軟性を最大限に活用するための必要な技術と知識を習得できます。