Запрос по типу timeuuid не возвращает правильные результаты через cql

Question

Я пытаюсь выполнить запрос, используя timeuuid для извлечения набора результатов.

Таблицы как таковые:

CREATE TABLE mds.arguments_by_id (
    argument_id timeuuid PRIMARY KEY, 
    category text, 
    title text 
) 

Когда я выбираю dateOf() для всех данных в таблице, я получаю следующее:

select dateOf(argument_id),argument_id from arguments_by_id ; 

dateOf(argument_id)  | argument_id 
-------------------------+-------------------------------------- 
2014-12-29 13:50:07-0500 | 81f990c0-8f8b-11e4-abb3-5d7a44c0d8a8 
2014-12-29 14:01:43-0500 | 20def1c0-8f8d-11e4-abb3-5d7a44c0d8a8 
2014-12-29 14:01:58-0500 | 29b50f50-8f8d-11e4-abb3-5d7a44c0d8a8 
2014-12-29 14:03:01-0500 | 4f6b72c0-8f8d-11e4-bc90-abc65998337a 

(4 rows) 

запрос Я хотел бы для запуска должен возвращать результаты, где argument_id (дата) превышает указанную дату:

select dateOf(argument_id),argument_id from arguments_by_id where token(argument_id) > token(maxTimeuuid('2014-12-28 15:31:00-0500')); 

Однако этот запрос г eturns в (казалось бы) неполный набор результатов по сравнению с предыдущим выберите:

dateOf(argument_id)  | argument_id 
--------------------------+-------------------------------------- 
2014-12-29 14:01:43-0500 | 20def1c0-8f8d-11e4-abb3-5d7a44c0d8a8 
2014-12-29 14:01:58-0500 | 29b50f50-8f8d-11e4-abb3-5d7a44c0d8a8 
2014-12-29 14:03:01-0500 | 4f6b72c0-8f8d-11e4-bc90-abc65998337a 

(3 rows) 

Моя цель состояла в том, чтобы свести к минимуму количество ключей - но мне интересно, если я 1) подвергаясь производительность удар, идя по этому пути и 2) пытается сделать слишком много с первичным ключом.

Answer 1

Чтобы использовать столбец timeuuid, подобный этому, вам нужно будет сделать его кластеризованным столбцом, а не ключом раздела (docs). Вы должны адаптировать это, чтобы соответствовать вашей модели данных, но вот пример:

create table sample (
    id int, 
    tid timeuuid, 
    category text, 
    title text, 
    primary key (id, tid) 
); 

Теперь мы можем сделать несколько вставок пару секунд друг от друга:

insert into sample (id, tid) values (100, now()); 
insert into sample (id, tid) values (100, now()); 
insert into sample (id, tid) values (100, now()); 
insert into sample (id, tid) values (100, now()); 

Показать все значения:

select id,tid,dateOf(tid) from sample; 

id | tid         | dateOf(tid) 
-----+--------------------------------------+-------------------------- 
100 | df4387a0-8fa8-11e4-bd3a-97fb52c7ef8c | 2014-12-29 14:20:19-0800 
100 | e085a490-8fa8-11e4-bd3a-97fb52c7ef8c | 2014-12-29 14:20:21-0800 
100 | e2bd6c20-8fa8-11e4-bd3a-97fb52c7ef8c | 2014-12-29 14:20:24-0800 
100 | e475f190-8fa8-11e4-bd3a-97fb52c7ef8c | 2014-12-29 14:20:27-0800 

Показать только часть с помощью timeuuid сравнения:

select id,tid,dateOf(tid) from sample where id=100 and tid>=minTimeuuid('2014-12-29 14:20:24-0800'); 

id | tid         | dateOf(tid) 
-----+--------------------------------------+-------------------------- 
100 | e2bd6c20-8fa8-11e4-bd3a-97fb52c7ef8c | 2014-12-29 14:20:24-0800 
100 | e475f190-8fa8-11e4-bd3a-97fb52c7ef8c | 2014-12-29 14:20:27-0800 

Обратите внимание, что если вы попытаетесь выбрать без указания первичного ключа (id = 100), вы получите предупреждение о том, что для этого запроса потребуется ALLOW FILTERING. Как правило, это неправильно, что нужно сделать, как это нужно будет сделать полное сканирование таблицы:

select id,tid,dateOf(tid) from sample where tid>=minTimeuuid('2014-12-29 14:20:24-0800'); 
Bad Request: Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. If you want to execute this 
query despite the performance unpredictability, use ALLOW FILTERING 

Вот еще один SO answer с подобной ситуацией.