私の使用例は次のとおりです。複数のサードパーティ ソースからのデータを保存およびクエリする必要があります。私が持っている唯一の事前定義されたスキーマの知識は、それが Entity-Attribute-Value タプルと追加の Source コンポーネントで構成されているということです: (E, A, V, S). どの属性が存在するかは事前にわかりません (そのため、実際の属性自体を列として使用するのは問題があります)。組み合わせ(E,A,V)は一意でなければならないため、これを複合キーとして使用することがこれをモデル化する最良の方法であると考えたので、次のようになります。
CREATE TABLE t1 (
E text,
A text,
V text,
S text,
PRIMARY KEY(E, A, V)
);
これにより、次のようなクエリを実行できます。
- E が与えられた場合、すべての属性 A と値 V、およびそれらが発生するソース S を表示します
- E と A が与えられたとき、すべての V を与えます。
次の形式のクエリにも回答できるように、異なる順序の複合キーを使用してこのテーブルのミラーを作成する計画です。
- A が与えられた場合、すべてのエンティティ E と値 V を表示します。
- S が与えられた場合、すべての E、A、V タプルを表示します。
などなど（事実上、ミラーテーブルはインデックスの役割を果たし、完全なインデックス作成を行うには、事実上同じデータの6つのコピーが必要になります-そのアプローチのスケーラビリティについてはまだわかりませんが、それは別の質問です推測してみて）。
ここまでは順調ですが、私が苦労している部分は次のとおりVです。実際には、それ自体が複数のプロパティを持つオブジェクトです。これがリレーショナル モデルである場合、たとえば、フィールドとフィールドにVマッピングされるリレーションを指す外部キー フィールドになります。しかし、外部キー (およびそれらに伴う結合) を取り除くことは、私が推測する BigTable アプローチの要点であるため、これをテーブルに組み込む方法を探しています。idtypevaluet1
もちろん、次のようなこともできます。
CREATE TABLE t1 (
E text,
A text,
V_id text,
S text,
V_type text,
V_value text,
PRIMARY KEY(E, A, V_id)
);
しかし、私が見る問題は、これが の id、型、および値の間の (逆の) 機能的関係を捉えることがVできないことです: 上の表では、たとえば、次のようになります:
E | A | V_id | V_type | V_value
---+----+------+--------+--------
a1 | b1 | 1 | X | foo
a1 | b1 | 2 | X | foo
a1 | b2 | 1 | Y | bar
与えられた a 、型と値が一意であることを保証できるようにしたいのですがV_id、その逆も同様です。私が求めているのは、古い Cassandra バージョンではネストされたスーパー カラムになるということですが、CQL3 で必要なことを達成しようとしています。
コレクションの型について簡単に調べてみましたが、私のユース ケースにはあまり適していないようです。
(E, A, V)理想的には、できるだけ少ないクエリで取得できるようにしたいということを念頭に置いて、これをモデル化するためのより良い方法を誰かが提案できますか? または、私はそれを考えすぎているだけで、現在のアプローチは実際には問題ありません(もちろん、アプリケーションレベルで一意性を確保することはできます)?