我决定在一个项目中使用 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)
以上几点注意事项:
- 2种类型之间可以有n个关联
- 同一类型/实例之间可以存在关联(上面的示例)
- 类型之间的关联定义了如何关联 实例
查询是什么:
- 系统应该能够对单个关联、类型和实例类型进行 CRUD。
- 类型的关系。(例如:
GET /t-assoc/t1
-> [ t1 - a1 - t2 ]) - 关联类型的关系。(例如:
GET /t-assoc/t2/a1
-> [ t1 - a1 - t2 ]) - 与上述相同,但具有完整的关系
- 例如关系(例如:
GET /i-assoc/t1/t1-i1
-> [< t1 , t1-i1 >- a1 -< t2 , t2-i3 >]) - 关联实例的关系(例如:
GET /i-assoc/t1/t1-i1/a1
-> [< t1 , t1-i1 >- a1 -< t2 , t2-i3 >]) - 关联实例与类型的关系(例如:
GET /i-assoc/t1/t1-i1/a1/t3
-> []) - 同上,关系完整
- 类似于3.只是它应该返回实际的相关类型,而不是返回关系(例如:
GET /types/t1/a1
-> [ t2 ]) - 类似于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为:
- t1-a1-t2-真
- t2-a1-t1-假
此实现不支持查询号:9 和 10。对于 9,我需要执行 2 个查询,其中第二个是IN
查询。这不是最优的,因为这些将是最常见的查询。
关于允许在 1 个查询中执行上述内容的不同设计的任何建议?
编辑:作为图形结构,这将非常适合图形数据库。我正在尝试在 Cassandra 中解决这个问题。