【问题标题】:Cassandra cqlsh not working with where clause on non-partition keyCassandra cqlsh 不适用于非分区键上的 where 子句
【发布时间】:2017-09-08 02:08:15
【问题描述】:

我的表描述是:

CREATE TABLE user (
    id text,
    CustID int static,
    UpdateDate date,
    DateOfBirth date static,
    Gender text static,
    Address text static,
    City text static,
    State text static,
    Zip text static,
    Email  text static,
    Phone text static,
    OverallAssets double,
   PRIMARY KEY (id,UpdateDate)
); 

select * from user 工作正常。

select * from user where partition key 也可以正常工作。

但是如果我将非分区键放在 where 子句中会低于错误。可能是什么原因?

ReadFailure: Error from server: code=1300 [Replica(s) failed to execute 
read] message="Operation failed - received 0 responses and 1 failures" info=
{'failures': 1, 'received_responses': 0, 'required_responses': 1, 
'consistency': 'ONE'}

【问题讨论】:

  • 我增加了tombstone_failure_threshold 的值。还是不行。
  • 您在日志中看到了什么吗?它仍然可能是墓碑(如果你有更多)。
  • 我认为我们可以使用允许过滤来查询非分区键。我试过了。
  • 使用允许过滤执行查询可能不是一个好主意,因为它会占用大量计算资源。不要在生产中使用允许过滤阅读有关使用 ALLOW FILTERING 的 datastax 文档

标签: cassandra cql cqlsh


【解决方案1】:
select * from user where CustID =0 allow filtering;

在 Cassandra 中,您需要采用基于查询的建模方法。解决此问题的最佳方法是使用专门设计用于处理该查询的表

CREATE TABLE users_by_custid (
    id text,
    CustID int,
    UpdateDate date,
    DateOfBirth date static,
    Gender text static,
    Address text static,
    City text static,
    State text static,
    Zip text static,
    Email  text static,
    Phone text static,
    OverallAssets double,
   PRIMARY KEY (cust_id,id,UpdateDate)
); 

这行得通,分布良好,并且不需要伴随ALLOW FILTERING 进行的全表扫描。

是的,我正在做cqlsh --connect-timeout=100000000 --request-timeout=10000000000

我不能警告你不要这样做。这些超时默认值的存在是有原因的。它们可以保护您的集群/节点不会因查询性能不佳而翻倒。当您遇到问题并想增加查询超时时,请仔细查看您的查询,看看是否有更好的方法来构建它。

【讨论】:

  • 所以cust_id 是我的partition keyid,UpdateDate 是集群键吗?现在我想知道如果我还想查询其他多个列上的 where 子句,我应该将它们添加为集群键还是更好地设计多个表来达到目的。我正在考虑这里的表现。
  • 你会想要走多桌路线。这是与 Cassandra(或任何分布式数据库,就此而言)的权衡。查询灵活性总是难以实现。这归结为一个问题,在使用不同的数据存储更有意义之前,您希望有多少表保持同步。
  • @curiousguy 另一个想法:如果您使用的是 Cassandra 3.x,则可以通过使用物化视图或(在某些情况下)SASI 索引来减轻一些查询表开销。如果您愿意在读取性能方面受到一点影响,这些工具可以帮助您提高查询的灵活性。
  • 是的,正如 -Ashraful 所建议的那样,正在查看 datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views
【解决方案2】:

您正在使用allow filtering。当心。使用允许过滤执行此查询可能不是一个好主意,因为它可能会占用大量计算资源,并且可能由于超时而不会返回任何结果。不要在生产中使用允许过滤阅读有关使用 ALLOW FILTERING 的 datastax 文档

https://docs.datastax.com/en/cql/3.3/cql/cql_reference/select_r.html?hl=allow,filter

而不是使用允许过滤创建物化视图或索引。

查看有关创建和使用物化视图的链接:https://www.datastax.com/dev/blog/new-in-cassandra-3-0-materialized-views

查看有关创建和使用索引的链接:http://docs.datastax.com/en/cql/3.1/cql/cql_reference/create_index_r.html

何时不使用索引
在这些情况下不要使用索引:

  • 在高基数列上,因为您随后会针对少量结果查询大量记录。请参阅下面的使用高基数列索引的问题。
  • 在使用计数器列的表中 在经常更新或删除的列上。请参阅下面在频繁更新或删除的列上使用索引时遇到的问题。
  • 除非经过严格查询,否则在大分区中查找行。请参阅使用索引在大分区中查找行时遇到的问题,除非在下面进行了严格查询。

来源:http://docs.datastax.com/en/cql/3.1/cql/ddl/ddl_when_use_index_c.html

【讨论】:

    猜你喜欢
    • 2016-06-02
    • 2018-02-20
    • 2018-01-07
    • 2019-12-12
    • 2014-09-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多