cassandra - 如何保持cassandra中多个表的数据一致性？

Question

我无法弄清楚如何维护多个表之间的属性更新以确保数据一致性。

例如，假设 Actor 和粉丝之间存在多对多关系。一个粉丝可以支持很多 Actor ，一个 Actor 也可以拥有很多粉丝。我制作了几个表来支持我的查询

CREATE TABLE fans (
    fan_id uuid,
    fan_attr_1 int,
    fan_attr_2 int
    PRIMARY KEY ((fan_id))
)

CREATE TABLE actors (
    actor_id uuid,
    actor_attr_1 int,
    actor_attr_2 int
    PRIMARY KEY ((actor_id))
)

CREATE TABLE actors_by_fan (
    fan_id uuid,
    actor_id uuid,
    actor_attr_1 int,
    actor_attr_2 int
    PRIMARY KEY (fan_id, actor_id)
)

CREATE TABLE fans_by_actor (
    actor_id uuid,
    fan_id uuid,
    fan_attr_1 int,
    fan_attr_2 int
    PRIMARY KEY (actor_id, fan_id)
)

假设我是一名粉丝，在我的设置页面上，我想将我的 fan_attr_1 更改为其他值。

在 fans 表上，我可以很好地更新我的属性，因为应用程序知道我的 fan_id 并且可以对其进行键入。

但是，如果不先查询与粉丝关联的 actor_ids，我就无法更改 fans_by_actor 上的 fan_attr_1。

每当您想要更新粉丝或 Actor 的任何属性时，都会出现此问题。

我尝试在网上寻找遇到类似问题的人，但找不到他们。例如，在 Datastax 的数据建模类(class)中，他们使用具有多对多关系的 Actor 和视频的示例，其中有表 actors_by_video 和 videos_by_actor。与我咨询过的其他在线资源一样，该类(class)讨论了查询后的建模表，但没有深入探讨如何维护数据完整性。在 actors_by_video 表中，如果我想更改 Actor 的属性，会发生什么情况？是否不必遍历 actors_by_video 的每一行来查找包含 Actor 的分区并更新属性？这听起来效率很低。另一种选择是事先查找视频 ID，但我在其他地方读到，在写入之前读取是 Cassandra 中的反模式。

从数据建模的角度或从 CQL 的角度来看，解决此问题的最佳方法是什么？

编辑: - 固定句子 stub - 添加了背景和先前的研究

Answer 1

Data Modeling

Cassandra 不是关系数据库，数据建模需要遵循某些基本规则，在高层次上，我们的数据模型需要遵循以下目标。

1)在集群周围均匀分布数据

2)最小化读取的分区数量

此外，我们应该选择单个大表，而不是将其分解为多个表并在表之间添加关系。在这种方法中会发生记录重复。记录复制并不是一个成本较高的操作，因为它只需要多一点的磁盘空间，而不是 CPU、内存、磁盘 IOP 或网络。

请注意，列键名称和值有大小限制。最大列键(和行键)大小为 64KB。最大列值大小为 2 GB。但由于没有流式传输，并且在请求时会在堆内存中获取整个值，因此将大小限制为仅几 MB。

更多信息:

http://www.datastax.com/dev/blog/basic-rules-of-cassandra-data-modeling

http://www.ebaytechblog.com/2012/07/16/cassandra-data-modeling-best-practices-part-1/

http://www.ebaytechblog.com/2012/08/14/cassandra-data-modeling-best-practices-part-2/

https://docs.datastax.com/en/cql/3.1/cql/cql_reference/refLimits.html

CQL

可以使用 Batch 来维护表之间的一致性或Materialized Views 。物化 View 从 3.0 版本开始可用

请参阅

How to ensure data consistency in Cassandra on different tables?

My preference would be to change the data model and design it accordingly for our queries and if possible make it as a single big table.

希望有帮助!