cassandra - 虚拟分区键总是坏的吗？

Question

我在 Cassandra 中找不到太多关于虚拟分区键的主题，但我能找到的内容倾向于你应该完全避免使用它们的想法。通过虚拟，我的意思是一个列，其唯一目的是为所有行包含相同的值，从而将所有数据放在一个节点上并提供尽可能低的基数。例如:

dummy  | id   | name
-------------------------
0      | 01   | 'Oliver'
0      | 02   | 'James'
0      | 03   | 'Nicholls'

关于为什么应该避免使用虚拟分区键的两个要点是:

1)你最终得到数据“热点”。 1 个节点上存储了大量数据，因此该节点周围的流量更多，并且集群周围的分布很差。

2) 分区空间是有限的。如果将所有数据放在一个分区上，最终将无法存储更多数据。

我可以理解这些要点，并且我同意您肯定希望避免这些情况，因此我将这个想法从脑海中抛开，并尝试为我的表考虑一个好的分区键。有问题的表存储站点，在我们的系统中查询表有两种常见的方式。请求单个站点或请求所有站点。

这让我陷入了一种尴尬的境地，因为该表要么在任何内容或站点 ID 上都被查询，而将唯一字段设置为分区键会给我在请求所有站点的查询时提供非常高的基数和高延迟。

所以我决定只选择一个给出相对较低基数的任意字段，即使它不能反射(reflect)实际查询数据的方式，只是因为它比基数过高或过低要好.不过这种方法也有问题。

我可以在 x 列上对我的数据进行分区，但是我们有许多客户，他们都以不同的方式使用我们的系统，所以 x 为 1 个客户可以给出我想要的结果，但可能会给另一个客户带来糟糕的结果。

在这一点上，我已经没有选择了。我的表中需要一个对所有客户端都一致的字段，但是这个字段不存在，所以我现在正在考虑使用一个新字段，其中包含一个 1-3 的随机数，然后对该字段进行分区，这本质上只是一个虚拟字段。唯一的区别是我想稍微随机化这些值以避免热点和无限的行增长。

我知道这是一个数据建模问题，它因系统而异，当然在某些情况下你必须选择两个弊端中较小的一个(没有完美的解决方案)，但我真的这个问题的重点是:

在 Cassandra 中，虚拟分区键是完全不应该考虑的，还是在某些情况下它们被认为是可以接受的？如果您认为是前者，那么您将如何处理这种情况？

Answer 1

I can't find much on the subject of dummy partition keys in Cassandra, but what I can find tends to side with the idea that you should avoid them altogether.

我要冒个险，猜你的搜索已经产生了我的文章 We Shall Have Order! ，在那里我非常清楚地表明了我对使用“虚拟”分区键的立场。考虑到这一点，我将尝试提供一些替代解决方案。
我在这里看到两个潜在的问题需要解决。首先:

I need a field in my table that will be consistent for all clients, however this field doesn't exist

通常，这是通过将数据复制到另一个查询表中来解决的。这是提供多种不同查询模式的最佳方式。如果您有一个需要通过站点 ID 查询该表的客户端(服务？)，那么您可以将该表复制到一个名为 sites_by_id 的表中。 .

CREATE TABLE sites_by_id (
  id BIGINT,
  name TEXT,
  PRIMARY KEY (id));

另一个问题是这个查询模式:

all sites are requested

另一个常见的 Cassandra 反模式是未绑定(bind)的 SELECT(没有 WHERE 子句的 SELECT 查询)。我相信你明白为什么这些不好，因为它们需要读取所有节点/分区才能完成(这可能就是你寻找“虚拟” key 的原因)。但是随着支持这些类型查询的表的大小增加，它们只会随着时间的推移变得越来越慢......无论您是执行未绑定(bind)的 SELECT 还是使用“虚拟”键。
这里的解决方案是重新检查您的数据模型和业务需求。也许您的数据可以按地区或国家划分为站点？也许您的客户真的只需要今年已更新的网站？获取有关客户端查询要求的更多详细信息可能会帮助您找到一个好的分区键供他们使用。否则，如果他们真的一直都需要它们，那么 doanduyhai 使用 Spark 的建议将更适合您的用例。