cassandra 上不同的可能搜索参数

Question

我是 Cassandra 的新手。在把我的头撞在墙上几天之后，事情开始变得有意义，除了...... 我总是需要 PK 来执行查询？ ????

因此，我考虑了以下场景：假设我正在构建一个包含数千种食谱的食谱网站。每个食谱都有一个标题、一份配料表和一个类型（早餐、午餐、甜点等） 我想要一个搜索字段，我可以使用这三个参数中的任何一个来查找食谱。我不能将所有 3 个参数都作为 PK，因为我无法仅使用其中一个参数进行搜索 [如果我将一个参数作为 PK 而其他参数则相同作为簇键]。 我知道二级索引不是一个好主意。 因此，如果我希望能够按成分查询食谱，我将必须创建一个成分表，在其中放置一个 recipeId，然后在每一行上放置一个成分列表，对吗？

但是，我将如何按成分查询并按评级排序？我应该将评级添加到成分表中吗？我应该复制那么多数据吗？

如果我想同时按成分和类型查询，我需要执行两个单独的查询并比较它们？

对于用户表：登录时我需要通过电子邮件查找用户。然后，其他用户会按他们的名字搜索他们的朋友。所以我需要一个不同的表来存储登录凭据和用户配置文件？

基本上，我要做的是创建 很多 表。这是预期的吗？这是可取的吗？

我应该以某种方式整合 MySQL 和 Cassandra 吗？

提前致谢。

Answer 1

Henrique - 您正在触及 Cassandra（迄今为止的 C*）的许多最基本概念。

1) 分区键（如您所指的 PK），无论是否复合，都决定了您的数据在 C* 集群上的存储位置。分区器决定了如何将分区键的值转换为令牌。集群中的每个节点负责令牌范围的一部分。因此，当您想查询某些数据时，通过分区键查询，您实际上是在指示 C* 从环中的哪个节点获取数据。

不要考虑使用字节顺序分区器进行范围查询。看到这个答案。 Cassandra ByteOrderedPartitioner

2) 查询设计。 “Cassandra: The Definitive Guide: Distributed Data at Web Scale”一书有一个关于数据建模的优秀章节。花时间阅读一本关于数据建模的 C* 书籍是很值得的。

以您有订单和订单项的系统为例。注意：我并不是一定要提倡将 Cassandra 用于订购系统，它只是一个易于理解的关系模型。

您的用户想要获取所有带有商品的订单，因此您可以构建一个类似的表格；

CREATE TABLE orders_to_items (o_id uuid, item_id uuid, PRIMARY KEY(o_id));

如果您还想查看已添加商品的所有订单，那么您需要/想要一个单独的表格；

CREATE TABLE items_on_orders (item_id uuid, o_id uuid, PRIMARY KEY(item_id));

所以你可以看到这两个单独的查询，最终生成两个单独的表。

有趣的是，这里有几个快速的答案。

是的 - 非规范化，非规范化。这就是 C* 的全部意义所在。

不要被实体化视图所诱惑：除非您真正理解它们，否则我的建议是避免。

3) 对于您的搜索项（按名称搜索），您可能需要考虑在 Cassandra 之上使用 Lucene 等附加工具来执行您所说的“搜索”。我已经看到 Cassandra 的 stratio Lucene 插件在现实世界中取得了一些不错的成功。

注意：我在 AWS 中运行一个 9 节点、3.11.2 C* 集群。