get_range_slices和CQL查询处理,需要ALLOW FILTERING

Question

我有一个以下的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 +分区号(类似哈希(用户)mod X)聚类键:列分区号(类似哈希(用户)>> 16 mod Y)+用户

对于"列分区否"...我不确定是否真的需要它.我假设如果我使用这个模型,我将为每个域+应用程序组合提供相对较少的行数(X = 1000..10000).如果我愿意,这将允许我查询各个分区,即使是并行查询.但是(假设用户是随机UUID)对于100M用户来说,每行将产生数十或数十万列.在一个请求中读取这样一行是不是一个好主意？我相信它应该为Cassandra造成一些记忆压力.所以也许分组阅读(比如,Y = 10..100)会更好吗？

我意识到我要做的不是Cassandra做得好 - 读取可以预先计算的块中的"全部"或大部分CF数据(如令牌范围或分区键),以便从不同主机进行并行获取.但我试图找到一种对这种用例最有效的模式.

顺便说一下,查询如"select*from ... where TOKEN(user)> X and TOKEN(user)

Answer 1

简短的回答

此警告意味着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来说,数十亿个分区键可能并不算太多.