私は cassandra と nosql のモデリングは初めてです。注文管理ソリューションをモデル化したいユースケースがありました。これは、RDBM で Cassandra に非常に一般的なユースケースです。私たちのユースケースでは、アプリケーションは異なる期間に複数の注文アイテムを受け取ります。それぞれを監査目的で保存する必要があり、注文の概要やその他のビジネスの詳細を詳しく説明するためにグループ化する必要があります。また、注文アイテムの属性を検索可能にして、これを検索できるようにしたいと考えています。
私は2つのアプローチを考えました：
1)複合キー パターンに基づく: ここでは、すべての注文アイテムの属性を列として、1 つの列ファミリー '注文アイテム' をキーとして (orderid + タイムスタンプ) として、注文アイテムをそのまま保存します。
- oid1:01012012 -> oid:oid1、イベント:新規、タイプ:リクエスト、...
- oid1:01012012 -> oid:oid1、イベント:OK、タイプ:応答、...
- oid1:02012012 -> oid:oid1、イベント:変更、タイプ:リクエスト、...
2)太い行の設計: ここでは orderid を行キーとして保持し、すべての注文項目は json 文字列として保持されます。これは、監査目的で使用されます。別の列ファミリを使用して、構造を (Rowkey -> colA1:a1、colB1:b1、colA2:a2、colB2:b2、...) 1,2.. インデックスで保持します。注文品。
私の友人は、#1 はパフォーマンスがあまり良くないだろうと示唆しています。同じ orderid を持つ異なる行が Cassandra リングの異なるノードに存在する可能性があるためです。＃2は、同じデータの複数のコピーを保持する必要がある不器用な設計であることがわかりました。また、#2 の設計の上に検索を実装する方法も考えられませんでした。
これをより良く設計する方法について何か考えはありますか?