1

我有一个以下 CQL 表（为了清楚起见，稍微简化了一点）：

CREATE TABLE test_table (
    user        uuid,
    app_id      ascii,
    domain_id   ascii,
    props       map<ascii,blob>,
    PRIMARY KEY ((user), app_id, domain_id)
)

这个想法是该表将包含许多用户（即行，例如，数千万）。每个用户都会有几个感兴趣的域，每个域会有几个应用程序。对于每个用户/域/应用程序，都会有一小组属性。

我需要扫描整个表并为给定的 app_id 和 domain_id 分块加载其内容。我的想法是使用 TOKEN 函数能够在多次迭代中读取整个数据集。所以，像这样：

SELECT props FROM test_table WHERE app_id='myapp1'
  AND domain_id='mydomain1'
  AND TOKEN(user) > -9223372036854775808
  AND TOKEN(user) < 9223372036854775807;

我假设这个查询会很有效，因为我指定了行键的范围，并且通过指定集群键的值，我有效地指定了列范围。但是，当我尝试运行此查询时，我收到错误消息“错误请求：无法执行此查询，因为它可能涉及数据过滤，因此可能具有不可预测的性能。如果您想在性能不可预测的情况下执行此查询，请使用 ALLOW FILTERING” .

我对 Cassandra 的经验有限，我假设这种查询将映射到 get_range_slices() 调用，该调用接受切片谓词（即由我的 app_id/domain_id 值定义的列范围）和由我的令牌范围定义的键范围. 似乎我误解了这种查询的处理方式，或者我误解了 get_range_slices() 调用的效率。

更具体地说，我的问题是： - 如果这个数据模型对我想到的查询类型有意义 - 如果这个查询预计是有效的 - 如果它是有效的，那么为什么我会收到这个错误消息我允许过滤

我对最后一个的唯一猜测是需要从结果中跳过没有给定 app_id/domain_id 组合的行。

- - 更新 - -

感谢所有的评论。我一直在对此进行更多研究，但仍有一些我不完全理解的东西。

在给定的结构中，我试图从我的数据集中获得一个矩形区域（假设所有行都具有相同的列）。其中矩形的顶部和底部由标记范围（范围）确定，左侧/右侧定义为列范围（切片）。因此，这应该自然地转换为 get_range_slices 请求。我的理解（如果我错了，请纠正我）CQL 要求我放置 ALLOW FILTERING 子句的原因是因为会有不包含我要查找的列的行，因此必须跳过它们。而且由于没有人知道在找到符合我的标准（在给定范围内）的行之前是否必须跳过每隔一行或前一百万行 - 这就是导致不可预测的延迟甚至可能超时的原因。我对吗？我试图编写一个执行相同类型查询但使用低级 Astyanax API 的测试（在同一张表上，我必须读取使用 CQL 生成的数据，结果非常简单）并且这个测试确实有效- 除了它返回没有列的键，其中行不包含我要求的列切片。当然，我必须根据起始令牌和限制来实现某种简单的分页，以便以小块的形式获取数据。

现在我想知道 - 再次考虑到我需要处理数以千万计的用户：部分“旋转”这个表并将其组织成这样会更好：

行键：domain_id + app_id + 分区号（类似于 hash(user) mod X） 聚类键：列分区号（类似于 hash(user) >> 16 mod Y）+ 用户

对于“列分区号”......我不确定它是否真的需要。我假设如果我使用这个模型，每个域 + 应用程序组合的行数会相对较少（X=1000..10000）。这将允许我查询各个分区，即使我愿意也可以并行查询。但是（假设用户是随机 UUID）对于 100M 用户，它将导致每行数十或数十万列。在一个请求中读取一个这样的行是一个好主意吗？我敢肯定，这应该会给 Cassandra 带来一些内存压力。所以也许分组阅读它们（例如，Y = 10..100）会更好？

我意识到我想要做的并不是 Cassandra 做得好的事情——以块的形式读取“所有”或大的 CF 数据子集，这些数据可以预先计算（如令牌范围或分区键），以便从不同的主机并行获取。但我试图找到一种对这种用例最有效的模式。

顺便说一句，像“select * from ... where TOKEN(user)>X and TOKEN(user)

4

2 回答 2

5

简短的回答

此警告意味着 Cassandra 必须读取非索引数据并过滤掉不满足条件的行。如果您添加ALLOW FILTERING到查询的末尾，它会起作用，但是它会扫描大量数据：

SELECT props FROM test_table 
WHERE app_id='myapp1' 
AND domain_id='mydomain1' 
AND TOKEN(user) > -9223372036854775808 
AND TOKEN(user) < 9223372036854775807
ALLOW FILTERING;

更长的解释

在您的示例中，主键由两部分组成：user用作分区键，并<app_id, domain_id>形成剩余部分。不同用户的行分布在集群中，每个节点负责特定范围的令牌环。

单个节点上的行按分区键的哈希排序（token(user)在您的示例中）。单个用户的不同行存储在单个节点上，按<app_id, domain_id>元组排序。

因此，主键形成树状结构。分区键增加了一层层次结构，主键的每个剩余字段都增加了一层。默认情况下，Cassandra 只处理从树的连续范围（或者如果使用key in (...)构造，则返回多个范围）中返回所有行的查询。如果 Cassandra 应该过滤掉一些行，ALLOW FILTERING必须指定。

不需要的示例查询ALLOW FILTERING：

SELECT * FROM test_table 
WHERE user = 'user1'; 
//OK, returns all rows for a single partition key

SELECT * FROM test_table 
WHERE TOKEN(user) > -9223372036854775808 
AND TOKEN(user) < 9223372036854775807; 
//OK, returns all rows for a continuos range of the token ring

SELECT * FROM test_table 
WHERE user = 'user1'
AND app_id='myapp1'; 
//OK, the rows for specific user/app combination 
//are stored together, sorted by domain_id field

SELECT * FROM test_table 
WHERE user = 'user1'
AND app_id > 'abc' AND app_id < 'xyz'; 
//OK, since rows for a single user are sorted by app

确实需要的示例查询ALLOW FILTERING：

SELECT props FROM test_table 
WHERE app_id='myapp1';
//Must scan all the cluster for rows, 
//but return only those with specific app_id

SELECT props FROM test_table 
WHERE user='user1'
AND domain_id='mydomain1';
//Must scan all rows having user='user1' (all app_ids), 
//but return only those having specific domain

SELECT props FROM test_table 
WHERE user='user1'
AND app_id > 'abc' AND app_id < 'xyz'
AND domain_id='mydomain1';
//Must scan the range of rows satisfying <user, app_id> condition,
//but return only those having specific domain

该怎么办？

在 Cassandra 中，不可能在主键部分创建二级索引。有几个选项，每个都有其优点和缺点：

  • 添加一个具有主键的单独表，((app_id), domain_id, user)并在两个表中复制必要的数据。它将允许您查询特定app_id或<app_id, domain_id>组合的必要数据。如果您需要查询特定域和所有应用程序 - 第三个表是必要的。这种方法称为物化视图
  • 使用某种并行处理（hadoop、spark 等）为所有应用程序/域组合执行必要的计算。由于 Cassandra 无论如何都需要读取所有数据，因此可能与单个数据对没有太大区别。如果其他对的结果可能会被缓存以供以后使用，它可能会节省一些时间。
  • ALLOW FILTERING如果查询性能可以满足您的需求，请使用。数以万计的分区键对于 Cassandra 来说可能并不算多。
于 2013-10-17T00:05:00.260 回答
2

假设您正在使用 Murmur3Partitioner（这是正确的选择），您不想对行键运行范围查询。该键被散列以确定哪个节点保存该行，因此不按排序顺序存储。因此，执行这种范围查询需要进行全面扫描。

如果要执行此查询，您应该存储一些已知值作为行键的标记，以便您可以查询相等而不是范围。从您的数据看来，app_id 或 domain_id 都是不错的选择，因为听起来您在执行查询时总是知道这些值。

于 2013-10-16T20:26:27.337 回答