2017-04-08 11 views
2

您好我創建了一個表,用於存儲這樣的卡桑德拉聚類ORDER BY不能正常工作,並在正確的結果顯示

CREATE TABLE keyspace.test (
name text, 
date text, 
time double, 
entry text, 
details text, 
PRIMARY KEY ((name, date), time) 
) WITH CLUSTERING ORDER BY (time DESC); 

並插入數據到table.But這樣的查詢提供了一個無序結果數據。

SELECT * FROM keyspace.test where device_id name ='anand' and date in ('2017-04-01','2017-04-02','2017-04-03','2017-04-05') ; 

我的桌子設計有什麼問題。

+0

顯示例子,而您沒有得到排序結果 –

+2

不要自我宣傳或任何東西,但我在2015年寫了一篇關於此主題的文章,可能有所幫助:http://www.datastax。com/dev/blog/we-shall-order – Aaron

+0

@Aaron我讀過你的博客。有沒有其他辦法可以解決我的問題? –

回答

2

我想你是誤解cassandra集羣的關鍵順序。 Cassandra使用單個分區內的集羣密鑰對數據進行排序。

這是爲你的情況cassandra排序數據與集羣關鍵時間在一個單一的名稱和日期。

例子:讓我們插入一些數據

INSERT INTO test (name , date , time , entry) VALUES ('anand', '2017-04-01', 1, 'a'); 
INSERT INTO test (name , date , time , entry) VALUES ('anand', '2017-04-01', 2, 'b'); 
INSERT INTO test (name , date , time , entry) VALUES ('anand', '2017-04-01', 3, 'c'); 
INSERT INTO test (name , date , time , entry) VALUES ('anand', '2017-04-02', 0, 'nil'); 
INSERT INTO test (name , date , time , entry) VALUES ('anand', '2017-04-02', 4, 'd'); 

如果我們選擇與您的查詢數據:

SELECT * FROM test where name ='anand' and date in ('2017-04-01','2017-04-02','2017-04-03','2017-04-05') ; 

輸出:

name | date  | time | details | entry 
-------+------------+------+---------+------- 
anand | 2017-04-01 | 3 | null |  c 
anand | 2017-04-01 | 2 | null |  b 
anand | 2017-04-01 | 1 | null |  a 
anand | 2017-04-02 | 4 | null |  d 
anand | 2017-04-02 | 0 | null | nil 

你可以看到時間3,2,1不到單個分區anand:2017-04-01按照desc和時間排序4,0在單個分區內anand:2017-04-02是按照desc。卡桑德拉不會照顧不同分區之間的分類。

這裏是DOC:

在該表中定義,聚類列是列,它是所述化合物的主鍵定義的一部分,而不是第一列,它是爲分區保留的位置鍵。列在單個分區內聚集成多行。聚類順序由複合主鍵定義中列的位置確定。

來源:http://docs.datastax.com/en/cql/3.1/cql/ddl/ddl_compound_keys_c.html

通過,爲什麼你的數據字段是text類型和timedouble類型的方法是什麼?
您可以使用date字段作爲date類型和time作爲timestamp類型。

+0

這些字段是根據用例設計的。我有一些問題1.我是否需要更改我的餐桌設計才能獲得結果? 2.當我們通過分頁查詢數據時,是否有任何性能問題? –

+0

查詢中可以有多少個日期? –

+0

這取決於100左右。 –

2

您正在使用的查詢是o.k.但它可能不會像預期的那樣行事,因爲協調員不會根據分區對結果進行排序。我也偶然遇到這個問題。

它的解決方案非常簡單,基本上在客戶端執行需要的4個獨立查詢,然後在那裏合併結果要好得多。總之在運營商施加了很大的壓力,集羣中的協調器節點,有關於這個問題的一個很好的閱讀:

https://lostechies.com/ryansvihla/2014/09/22/cassandra-query-patterns-not-using-the-in-query-for-multiple-partitions/

+0

這是很難運行單獨的查詢。 –

+0

不應該那麼辛苦,除非你使用了一些奇特的框架,即使那樣。如果你使用期貨,你可以很容易地鏈接它們。一般而言,您只需遍歷「IN」中的參數即可。就像我剛開始的那一天的故事一樣如果我向我的導師抱怨循環,他會對我說,其中一個是很多的特例:) –