Patterns)」の最終回として、各パターンが解決する課題と、長所・短所をまとめます。スキーマ設計に関してよくある質問に「○○を行うためのアプリケーションの設計において、データのモデリングはどうすればよい?」というものがあります。このブログシリーズの過去の回でも解説したように、この質問に回答するには多くの考慮すべき点があります。今回の記事では、一般的なユースケースに対するデータモデリングの各パターンの概要をテーブルにしてみました。長年の経験から導き出した、さまざまなアプリケーションに採用されているスキーマ設計のパターンの傾向を示しています。これは特定のアプリケーションタイプに対してどのデザインパターンを使用するべきかを示す「固定された」ルールではありません。ご自身のユースケースでよく使用されているパターンを確認することが重要です。他のパターンも選択肢から完全に除外せずに検討する価値があります。アプリケーションのデータスキーマの設計は、データアクセスパターンによって大きく変わる可能性があります。リソースを多く消費する計算を頻繁に行う場合や、計算の精度が最優先でない場合に役立ちます。データベースへの書き込み回数が減る。統計的に有効な数字を維持できる。正確な数字が示されない。アプリケーション内での実装が必要。ドキュメントに多くの類似したフィールドがあり、その中に共通の特性を持つフィールドのサブセットが存在する場合に役立ちます。そのサブセットでソートやクエリを行う必要があるときに効果的です。ソートが必要なフィールドがドキュメントの一部にしか含まれていない場合や、状況が混在している場合にも有効です。インデックスが少なくて済む。クエリの記述がシンプルになり、全般的に実行速度が速くなる。時系列データ、リアルタイム分析、モノのインターネット(IoT)のアプリケーションなど、ストリーミングデータの管理が必要な場合に最適です。コレクション内のドキュメント数を削減できる。インデックスの性能が向上する。事前集計を活用することで、データアクセスが簡素化される。データへのアクセスが読み取り中心であり、さらに、読み取ったデータをアプリケーションで繰り返し計算するケースに適しています。クエリの記述がシンプルになり、全体的に実行速度が速くなる。コンピューテッドパターンが必要かどうかをの特定が困難。必要な場合を除き、このパターンの過剰な使用は避けるべきである。既存のシステムにも容易に実装できる。最新の修正に対するクエリの性能に影響しない。適切なコレクションに対してクエリを実行する必要がある。JOIN操作が多くある場合に性能が向上する。データの重複が発生する。一部のドキュメントやクエリがアプリケーションに影響を及ぼすのを防げる。クエリは一般的なユースケースに合わせて最適化されており、外れ値にも対応できる。特定のクエリにあわせて作成されていることが多く、アドホッククエリが適切に機能しないことがある。実装にはアプリケーションのコーディングが必要になるケースが多い。ドキュメントの構造が事前にわかっている場合は、設計を簡素化できる。簡素化できる一方で性能が低下する。