【问题标题】:Cassandra not returning all matching columns with a "SELECT x WHERE y IN (z)" queryCassandra 没有使用“SELECT x WHERE y IN (z)”查询返回所有匹配的列
【发布时间】:2014-04-05 10:20:29
【问题描述】:

我在 Cassandra 中有以下列族:

CREATE TABLE item_index (
  foo_id text,
  bar_id text,
  bar_metadata text,
  bar_url text,
  PRIMARY KEY (foo_id, bar_id)
) WITH
  bloom_filter_fp_chance=0.010000 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.000000 AND
  gc_grace_seconds=864000 AND
  read_repair_chance=0.100000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'SnappyCompressor'};

我正在尝试在 cqlsh 中使用此查询检索与 25 个特定 bar_id 列表匹配的所有行:

SELECT * FROM stagekeyspace.item_index WHERE foo_id IN ('1947dccc791ace5eb40dd2f00d9d876f') 
AND bar_id IN ('5f715d9f4a1a97b8fb54996bca5b0d91','64a8708d33b426315480b127a36663fd',
'b5f788e2c5b6e0bdfa3fc76d0f3e4fac','b6da801b86fd27e7382f5b6ce6dedf4d',
'c2e6586c0c9867157a4789a2ba3fb3c1','dc784b35764c6a3fbf083a6da59ad475',
'09c436ce046905b018a1e3fa417ee04a','0b4b5bd9c339353f6c16fcd822f50d6b',
'0c8e2e54c4629767b548830e122f295b','106735c6a97f8c8b006b9e0dbe18585e',
'11135d45b78086bc386bd9e538409915','269e2fbb4ce98f74471ec2fd0fffaa7a',
'2d2462fada062a160e60d537ab58ef81','30c617bd0dc41fde670c3796ad98ff65',
'32b458cae9762541a64e5f60b29f064c','36884ff28272675befb800eccc49b691',
'3b7f30db8c6594c5ec677d3465d47735','4054aedd79682a798d862e431be27636',
'4bee7a9cc7fd74a55e640ef6aca3864c','578e241dad54248261c341526563448b',
'59283ec34b7faa9db1c0befa38e34ea2','64a0fdc8019b32a5768900c6c30a6e66',
'65a767a4e7df8a06701c806f417c1de7','6719ab0291205b374cd50577f0a16ad7',
'6bde8f55ddb7764138d4937dfaf85795');

这会返回 21 个“行”,尽管它应该返回 25 行,每个 bar_id 一个。

为了确认所有 25 个 bar_id 的数据都存在,我运行了以下查询,一次使用一个 bar_id:

SELECT * FROM stagekeyspace.item_index WHERE foo_id IN 
('1947dccc791ace5eb40dd2f00d9d876f') AND bar_id IN ('5f715d9f4a1a97b8fb54996bca5b0d91');

所有 25 个查询都返回包含正确数据的一行。

关于为什么第一个查询没有返回它应该返回的所有结果的任何指针?

我在系统中有其他使用 SELECT .. WHERE x in ([LIST]) 的查询在 LIST 中有 100 多个项目,它们运行没有问题。此外,每个数据“行”的大小小于 1kb。

所有这些都在 Ubuntu 映像上运行:

[cqlsh 3.1.6 | Cassandra 1.2.8 | CQL spec 3.0.0 | Thrift protocol 19.36.0]

编辑:根据要求添加跟踪。请注意,一些列数据已更改,结果现在降至 18 而不是 25:

Tracing session: 4245fd80-a457-11e3-9933-19b599adc7ff

 activity                                             | timestamp    | source       | source_elapsed
------------------------------------------------------+--------------+--------------+----------------
                                   execute_cql3_query | 11:14:03,225 | 10.144.3.175 |              0
 Parsing SELECT count(*) FROM stagekeyspace.image_index WHERE domain_id 
 IN ('1947dccc791ace5eb40dd2f00d9d876f') 
 AND image_id IN ('64a8708d33b426315480b127a36663fd', 
 .., '6bde8f55ddb7764138d4937dfaf85795') LIMIT 10000; | 11:14:03,225 | 10.144.3.175 |             47
      Executing single-partition query on image_index | 11:14:03,226 | 10.144.3.175 |            733
                                   Peparing statement | 11:14:03,225 | 10.144.3.175 |            172
                         Acquiring sstable references | 11:14:03,226 | 10.144.3.175 |            750
                          Merging memtable tombstones | 11:14:03,226 | 10.144.3.175 |            776
                         Key cache hit for sstable 76 | 11:14:03,226 | 10.144.3.175 |            945
    Seeking to partition indexed section in data file | 11:14:03,226 | 10.144.3.175 |            959
                         Key cache hit for sstable 75 | 11:14:03,226 | 10.144.3.175 |           1061
    Seeking to partition indexed section in data file | 11:14:03,226 | 10.144.3.175 |           1071
                         Key cache hit for sstable 74 | 11:14:03,226 | 10.144.3.175 |           1263
    Seeking to partition indexed section in data file | 11:14:03,226 | 10.144.3.175 |           1277
                         Key cache hit for sstable 73 | 11:14:03,226 | 10.144.3.175 |           1421
    Seeking to partition indexed section in data file | 11:14:03,226 | 10.144.3.175 |           1433
           Merging data from memtables and 4 sstables | 11:14:03,226 | 10.144.3.175 |           1459
                  Read 18 live and 0 tombstoned cells | 11:14:03,230 | 10.144.3.175 |           5298
                                     Request complete | 11:14:03,230 | 10.144.3.175 |           5845

【问题讨论】:

  • “大”查询中的WHERE foo_id = '1947dccc791ace5eb40dd2f00d9d876f' 有影响吗?
  • 不,它没有。它返回相同的结果。
  • 您能在某处发布该查询的 TRACING 吗?
  • 你能用 COUNT(1) 而不是 * 显示第一个查询的输出吗?
  • COUNT(1) 返回相同的错误计数:18

标签: select cassandra cql3


【解决方案1】:

Cassandra 在进行全表扫描时有点懒惰:附加“ALLOW FILTERING”能解决问题吗? 例如。

SELECT * FROM stagekeyspace.item_index WHERE ... ALLOW FILTERING;

【讨论】:

  • 这个答案是正确的,应该被接受而不是反对。当我使用分区键上的过滤器(即从 id = 1234 的产品中选择计数(*))查询 CF 中的计数或记录时,我遇到了同样的问题,它给出了随机结果。向此查询添加允许过滤总是会产生正确的答案。请接受这个作为答案。
  • 除上述内容外,我还观察到具有复合 PK(即分区键和集群键)的 CF 的计数。这类似于您的 CF。
猜你喜欢
  • 2019-06-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-26
  • 2013-07-19
相关资源
最近更新 更多