如果主键包含(timeuuid 和时间戳)，带有时间戳的 Cassandra 集群无法按预期工作

Question

我使用的是 Cassandra 2.1.5。

我正在使用以下方法创建表格:

create table dummy2(  
  id timeuuid,  
  time timestamp,  
  primary key (id, time) 
) with clustering order by (time desc);

我在表中插入了四条记录:

insert into dummy2 (id, time) values (now(), 1000000);  
insert into dummy2 (id, time) values (now(), 2000000);  
insert into dummy2 (id, time) values (now(), 3000000);  
insert into dummy2 (id, time) values (now(), 4000000);  

我得到结果:

 id                                   | time  
--------------------------------------+--------------------------  
 e1fa7a80-1e64-11e5-8bf5-55cdf06f740f | 1970-01-01 08:33:20+0800  
 e3bbb280-1e64-11e5-8bf5-55cdf06f740f | 1970-01-01 08:50:00+0800  
 e5ceb400-1e64-11e5-8bf5-55cdf06f740f | 1970-01-01 09:06:40+0800  
 e0719090-1e64-11e5-8bf5-55cdf06f740f | 1970-01-01 08:16:40+0800  

看起来像树状图顺序，或者随机......

如果我将 id 类型从“timeuuid”更改为“text”，那么排序就可以正常工作:

 id    | time
-------+--------------------------
 hello | 1970-01-01 09:06:40+0800
 hello | 1970-01-01 08:50:00+0800
 hello | 1970-01-01 08:33:20+0800
 hello | 1970-01-01 08:16:40+0800

这是设计使然还是错误？或者我以错误的方式使用它？

Answer 1

是的，这就是 Cassandra 的设计工作方式。集群顺序仅在分区内起作用。这是因为每个分区键都被散列到一个 token 中，以确定它应该存储在集群中的位置(以提供最佳的数据分布)。然后，每个分区中的行按照其集群顺序写入磁盘上。

因此，在第一个示例中，每行都按每个 id 内的时间排序。当然，由于每个分区键 (id) 都不同，因此您无法看到这一点。但在第二个示例中，分区键相同，因此结果按时间进行聚类。

"which looks like a tree map order, or random..."

它们按哈希 token 值排序，您可以使用 token 函数查看这一点:

aploetz@cqlsh:stackoverflow2> SELECT token(id),id,time FROM dummy3;

 token(id)            | id    | time
----------------------+-------+--------------------------
 -3758069500696749310 | hello | 1969-12-31 19:06:40-0600
 -3758069500696749310 | hello | 1969-12-31 18:50:00-0600
 -3758069500696749310 | hello | 1969-12-31 18:33:20-0600
 -3758069500696749310 | hello | 1969-12-31 18:16:40-0600

(4 rows)

或者也许是一个更好的例子:

aploetz@cqlsh:stackoverflow2> SELECT token(id),id,time FROM dummy2;

 token(id)            | id                                   | time
----------------------+--------------------------------------+--------------------------
 -5795426230130619993 | e1fa7a80-1e64-11e5-8bf5-55cdf06f740f | 1969-12-31 18:33:20-0600
 -2088884548269216731 | e3bbb280-1e64-11e5-8bf5-55cdf06f740f | 1969-12-31 18:50:00-0600
  8496311684589314797 | e5ceb400-1e64-11e5-8bf5-55cdf06f740f | 1969-12-31 19:06:40-0600
  8930307282139899213 | e0719090-1e64-11e5-8bf5-55cdf06f740f | 1969-12-31 18:16:40-0600

(4 rows)

今年早些时候，我为 PlanetCassandra 写了一篇关于这个经常被误解的主题的文章:We Shall Have Order!读一读，看看是否能帮助您指明正确的方向。