Riak でマスターとディテールの関係をモデル化する一般的な方法は、マスター レコードにディテール レコード ID のリストを含めることです。これには、取得するディテール レコードを決定する際に役立つ可能性があるディテール レコードに関する情報も一緒に含めることができます。
あなたの例では、「本」と「ページ」という 2 つのバケットを持つことができます。「books」バケットのマスター レコードには、本に含まれるページのリストとともに、本全体に関するメタデータと情報が含まれます。各ページには、ページ データを保持する「ページ」レコードの ID と、対応するページ番号が含まれます。たとえば、章ごとにクエリを実行できるようにしたい場合は、特定のページが属する章に関する情報を追加することもできます。
「ページ」バケットには、ページのテキストと、場合によってはそのページに含まれる画像やその他のメディア データへのリンクが含まれます。このデータは、さらに別のバケットに保存できます。
特定のページまたはページの範囲を取得するには、まず「books」バケットからマスター レコードを取得し、次にレコードの内容に基づいて適切なページを取得します。これにはいくつかの GET 操作が必要ですが、それらはすべてキーに基づく直接ルックアップであり、Riak からデータを取得する最も効率的でスケーラブルな方法であるため、パフォーマンスとスケーリングが良好です。
このアプローチでは、マスターレコードのみを更新する必要があるため、ページや章の順序を簡単に変更できます。ただし、ページを追加、削除、または変更するには、マスター レコードと 1 つまたは複数の詳細レコードの両方を更新、追加、または削除する必要があります。
オブジェクトにセカンダリ インデックスを追加し、これに基づいてクエリを実行することで、この問題を確実に解決することもできます。ただし、Riak のセカンダリ インデックス クエリは、リクエストを満たすために、パーティションのカバー セット (通常はリング サイズ / n_val) の処理を含める必要があります。そのため、システムに少し負荷がかかり、一般的に、クエリを取得するよりもレイテンシが高くなります。直接キー検索によるキーを含む単一のオブジェクト (オブジェクトが実際に格納されているパーティションのみが必要です)。
インデックスを含む別のオブジェクトを維持すると、ページ/エントリを挿入または削除するときに少し余分な作業が追加されますが、直接キーの検索のみが必要なため、このアプローチは通常、より効率的な読み取りになります。アプリケーションで読み取りが多い場合は、おそらくこのアプローチを使用するのが理にかなっていますが、書き込みが多いアプリケーションでは、より高価な読み取りを犠牲にして挿入と変更が安価になるため、セカンダリ インデックスの方が効率的です。ただし、オプションを開いたままにしておくために、念のためにいつでもセカンダリ インデックスを追加できます。
このような場合、通常、いくつかのベンチマークを実行してソリューションをテストし、特定のパフォーマンスとスケーリングの要件に最適なソリューションを確認することをお勧めします。