0

私は 1 つのプロジェクトに Cassandra を使用することに決めました。多くのドキュメントを調べた後でも、連想データをモデル化する適切な方法が思い浮かびません。

システムは、データを型およびそれらの型のインスタンスとして格納することになっています。同時に、インスタンスを関連付ける方法を定義するカスタム関連付けを通じて、型を関連付けることができます。

より具体的な例として、次のデータを検討してください。

  • 関連: a1、a2、a3
  • タイプ: t1、t2、t3
  • インスタンス: t1-i1、t1-i2、t2-i3、t3-i4、t3-i5、t3-i6

次に、ユーザーはタイプを関連付ける方法を定義できます。

  • t1 - a1 - t2
  • t2 - a2 - t3
  • t3 - a3 - t3

上記は、インスタンスがどのように関連付けられるかを後で定義します。

  • t1-i1 - t2-i3 ( t1 - a1 - t2に基づく)
  • t2-i3 - t3-i5 ( t2 - a2 - t3に基づく)
  • t3-i5 - t3-i6 ( t3 - a3 - t3に基づく)
  • t3-i6 - t3-i6 ( t3 - a3 - t3に基づく)

上記に関するいくつかの注意事項：

  1. 2 つの型の間には n 個の関連があり得る
  2. 同じタイプ/インスタンス間に関連性がある場合があります(上記の例) 。
  3. タイプ間の関連付けは、インスタンスの関連付け 方法を定義します

クエリは次のようになります。

  1. システムは、個々の関連付け、タイプ、およびタイプのインスタンスを CRUD できる必要があります。
  2. タイプの関係。(例: GET /t-assoc/t1-> [ t1 - a1 - t2 ])
  3. 関連付けのタイプの関係。(例: GET /t-assoc/t2/a1-> [ t1 - a1 - t2 ])
  4. 上記と同じですが、完全な関係があります
  5. たとえば関係 (例: GET /i-assoc/t1/t1-i1-> [< t1 , t1-i1 >- a1 -< t2 , t2-i3 >])
  6. 関連のインスタンスの関係 (例: GET /i-assoc/t1/t1-i1/a1-> [< t1 , t1-i1 >- a1 -< t2 , t2-i3 >])
  7. 型への関連付けのインスタンスの関係 (例: GET /i-assoc/t1/t1-i1/a1/t3-> [])
  8. 上記と同じ、完全な関係を持つ
  9. 3.と同様に、リレーションを返す代わりに、実際の関連する型を返す必要があります (例: GET /types/t1/a1-> [ t2 ])。
  10. 7.と同様に、インスタンスを返します (例: GET /instance/t1/t1-i1/a1/t2-> [< t2 , t2-i3 ]>)

上記の構造を実装するためにいくつかの反復がありましたが、上記のすべての操作を単一のクエリで実行できる構造で表現することに失敗しました。CQL バージョンは次のとおりです。

CREATE TABLE association (
  bucket_id timeuuid,
  id text,
  data map<text,text>,
  PRIMARY KEY (bucket_id, id)
);

CREATE TABLE type (
  bucket_id timeuuid,
  id text,
  data map<text,text>,
  PRIMARY KEY (bucket_id, id)
);

CREATE TABLE instance (
  bucket_id timeuuid,
  type_id text,
  id timeuuid,
  data map<text,text>,
  PRIMARY KEY ((bucket_id, type_id), id)
);

CREATE TABLE type_association (
  bucket_id timeuuid,
  from_type_id text,
  association_id timeuuid,
  to_type_id text,
  reverse boolean,
  data map<text,text>,
  PRIMARY KEY (bucket_id, from_type_id, association_id, to_type_id, reverse)
);

CREATE TABLE instance_association (
  bucket_id timeuuid,
  from_type_id text,
  from_instance_id timeuuid,
  association_id timeuuid,
  to_type_id text,
  to_instance_id timeuuid,
  reverse boolean,
  data map<text,text>,
  PRIMARY KEY (bucket_id, from_type_id, from_instance_id, association_id,
    to_type_id, to_instance_id, reverse)
);

リバース フィールドは、両方向から関係を発見できるハックでした。これは、 t1 - a1 - t2を次のように挿入することを意味します。

  1. t1-a1-t2-真
  2. t2-a1-t1-false

この実装は、9 番と 10 番のクエリを優先しません。9 の場合、2 番目のクエリがクエリである 2 つのクエリを実行する必要がありINます。これらは最も一般的なクエリになるため、これは最適ではありません。

1 つのクエリで上記を実行できる別の設計に関する提案はありますか?

編集:グラフ構造として、これはグラフ データベースに適しています。ただし、Cassandraでこの問題を解決しようとしています。

4

1 に答える 1

0

グラフ データベースは、この問題に対するより優れたソリューションです。基本的に自分でやろうとしていることは、Vertex-Edge システムを作成することです。Aurelius の TitanDB を見てみましょう。http://thinkaurelius.github.io/titan/ ThinkAurelius は最近 DataStax に買収され、現在 DataStax の Enterprise バージョンにグラフ機能を統合しています。

cassandra をバックエンド ストレージとして使用するように Titan を構成できます。DB にクエリを実行するための柔軟性とより多くの関数が必要な場合は、検索エンジンとして solr または Elastic を使用するように構成することもできます。TitanDB は実際には「唯一の」計算エンジンであるため、クライアントで直接使用できます。これは Tinkerpop3 スタックを実装しているため、基になるグラフ データベースを、このスタックを実装する他のシステムに変更できます。マスターレスのスケーラビリティを失うことはありません。

于 2015-10-29T06:36:16.043 に答える