一般的に言えば、スキーマレス データ構造のクエリ (したがってインデックス作成) のベスト プラクティスは何ですか? (つまり、ドキュメント)
MongoDB を使用して、確定的なデータ構造をコレクションに格納およびクエリするとします。この時点で、すべてのドキュメントは同じ構造を持っているため、各ドキュメントにインデックスに必要なフィールドがあることがわかっているため、アプリ内のクエリのインデックスを簡単に作成できます。
構造を変更して新しいドキュメントをデータベースに保存しようとするとどうなりますか? FirstName と Lastname の 2 つのフィールドを FullName に結合したとします。その結果、コレクションには非決定論的なデータが含まれます。ここには 2 つの問題があります。
- 古いインデックスは新しいデータをカバーできないため、古いフィールドと新しいフィールドの両方を処理する新しいインデックスが必要です
- アプリは、ドキュメントの 2 つの表現を処理する必要があります
これは、データベースに多くの変更があり、ドキュメント構造のバージョンが多数になると、大きな問題になる可能性があります。
主なアプローチは 2 つあります。
- 遅延移行。これは、各ドキュメントが必要に応じて (つまり、コレクションからロードされた後にのみ) 最終的な構造に移行され、コレクションに戻されることを意味します。このアプローチは、どの時点でも非決定性を認めているため、実際には問題を解決しません。
- 強制移住。これは、RDBMS の移行と同じアプローチです。アプリが実行されていない間に、ある時点ですべてのドキュメントに対して移行が実行されます。主な短所は、アプリのダウンタイムです。
質問: 特にアプリのダウンタイムなしで、問題を解決する良い方法はありますか?