mysql - 将数据模型从 MySQL 迁移到 Cassandra

Question

MySql 中的结构(为了紧凑性，我使用简化的符号)

表示法:表名->[列1(键或索引)，列2，...]

documents->[doc_id(primary key), title, description]
elements->[element_id(primary key), doc_id(index), title, description]

每个文档可以包含大量元素(1 到 100k+ 之间)

我们有两个关键要求:

• 快速加载给定 doc_id 的所有元素
• 通过 element_id 快速更新单个元素的值

Cassandra 中的结构

第一个解决方案

documents->[doc_id(primary key), title, description, elements] (elements could be a SET or a TEXT, each time new elements are added (they are never removed) we would append it to this column)
elements->[element_id(primary key), title, description]

要加载文档，我们需要:

• 使用给定加载文档并获取所有元素 id:从 doc_id=‘id’ 的文档中选择 *

• 加载具有给定 ID 的所有元素:SELECT * FROM elements where element_id IN(从查询 a 加载的 ID)

更新元素将通过其主键完成。

第二个解决方案

documents->[doc_id(primary key), title, description]
elements->[element_id(primary key), doc_id(secondary index), title, description]

要加载文档，我们需要:

• 从 doc_id=‘id’ 的元素中选择 *

更新元素将通过其主键完成。

有关我们解决方案的问题:

• 第一:在 elements 表中查询 100k+ 主键是否高效？

  SELECT * FROM elements WHERE element_id IN (element_id1,.... element_id100K+)?
  

• 第二:仅通过二级索引查询效率高吗？

任何人都可以提供任何建议，我们将如何为我们的用例创建模型吗？

Answer 1

对于 cassandra 来说，一切都与访问模式有关(我希望我理解正确，如果不正确，请发表评论)

第一

文档不应使用集合，因为集合仅限于 65 535 个元素，并且每次进行更改时都必须完整读取和更新。因为你需要 100k+ 这不是你想要的。您可以使用卡住集合等，但话又说回来，每次读取内存中的所有内容肯定会很慢。

第二

二级索引，好吧，小基数数据可能没问题，但据我了解，每个文档有 100k 个数据，这甚至可能没问题，但话又说回来，这不是最佳实践。我只是在您的具体案例中尝试一下。

第三 - 磁盘是廉价的方法 - 始终以您要读取的方式写入数据 - cassandra 的写入非常便宜，因此在写入时准备 View ，

这个满足读取属于doc_id的所有元素

documents->[doc_id(primary key), title_doc (static), description_doc(static), element_id(clustering key), title, description]

元素几乎保持原样:

elements->[element_id(primary key), doc_id, title, description]

在进行更新时，您可以在文档和元素中更新它(为了保持一致性，您可以使用批处理操作 - 如果需要)如果有 element_id，您可以在获取其文档 ID 后快速发出另一个查询。根据您的更新需要，documentId 也可以是一个集合。 (我可能没有正确理解这一部分，因为不确定更新元素时​​有哪些数据可用，您是否也有 doc_id 以及一个元素可以在更多文档中吗？)

此外，由于检索的原因，在单个分区中拥有 100k+ 元素并不是最好的选择(所有请求都将发送到一个节点)，我建议使用复合分区键(桶)，我认为在您的情况下，一个简单的固定int 就可以了。因此，每次您检索刚刚发出的元素时，都会选择 documentid + (1, 2, 3, 4 ...)，然后在客户端合并结果 - 这会明显更快。

一个棘手的部分是，您不会进入文档中存储的 elementid 的每个存储桶......当我想到这一点时，最好使用以 2 为基数的存储桶。在您的情况下，16 是理想的...那么当您希望更新特定元素时，只需使用您已知的一些简单哈希函数并使用最后 4 位。

现在，当我想到如果元素 id + 文档 id 始终为您所知时，您甚至可能根本不需要元素表。

希望这有帮助