在cassandra中獲取partitionID的所有記錄會導致RPC超時

我正在使用Cassandra 1.2.1，組合鍵並試圖獲取特定分區ID的所有記錄。以下是我使用的架構：在cassandra中獲取partitionID的所有記錄會導致RPC超時

時間戳
設備ID
數據傳輸
位置ID
設備所有者

主鍵是複合鍵：（時間戳，設備ID）。因此TimeStamp是分區鍵。每個記錄將是70-80字節。

有1000個不同的TimeStamp，每個時間戳有500K個設備ID。所以有5億條記錄，我想獲取特定時間戳的所有記錄。類似的東西來：

SELECT * FROM模式其中timestamp =「..」

我的理解是，這個查詢應該能夠獲取所有的記錄速度快，因爲相關的行都存儲在連續的磁盤位置，這意味着很少有磁盤尋道會給我們帶來結果。過濾器在TimeStamp上，這意味着只有一個節點將被查詢命中。另外，數據總量爲500K * 80字節〜40MB，這並不是很糟糕。但是，當我使用CQL（3）或Astyanax運行時，我收到了RPC超時。

我的理解是，partitionID的所有記錄在連續的磁盤位置都是錯誤的？什麼應該是批量獲取這樣的數據的正確方法？

來源

2013-03-19 Ouroboros

最終，磁盤上的列將彼此靠近，因爲它們位於同一行中。但是在壓縮完成之前（即假設您不運行nodetool compact），它們將不會。但是他們應該分成幾個SSTables。

但是，較慢的事情可能是CPU反序列化，比較其他副本的結果並序列化回客戶端。我懷疑你可以爲rpc_timeout中的500k對象做這件事（默認爲10秒）。

要做到這一點，您應該翻閱結果。

對於第一個查詢，做

SELECT * from schema where TimeStamp = '..' limit 1000

然後帶上一個設備ID，並調用它最後：

SELECT 'last'..'' from schema where TimeStamp = '..' limit 1000

，直到你得到的響應少於1000列。

來源

2013-03-19 07:59:38 Richard

理查德，我沒有複製，所以比較其他副本的結果不應該放慢速度。對吧？您能否詳細說明反序列化的含義？您是指通過處理來自數據庫的輸出並在網絡上發送記錄（通過客戶端）引入延遲？我已經運行了緊湊的命令，將會更新如果有幫助。您是否知道我可以從任何其他方式中受益，因爲特定分區ID的數據將按順序存儲在數據庫中，以便我可以用最少的磁盤搜索來獲取它？謝謝。 – Ouroboros 2013-03-19 10:09:04

如果您沒有複製將使其更快。通過反序列化，我的意思是Cassandra必須從磁盤讀取數據並從中構建Java對象。在這種情況下，這可能是您的瓶頸 - 您可以在運行查詢時通過監視您的服務器來進行確認。它是CPU綁定（使用頂部）？它做多少I/O（使用iostat）？ – Richard 2013-03-19 10:11:37

你說的話可能意味着無論我做什麼（壓縮等），我會因Java反序列化而遇到瓶頸？糾正我，如果我錯了。有什麼方法可以改進嗎？我的另一個輸入是使用查詢從模式中選擇計數（*）TimeStamp ='..' 也導致RPC超時。現在，如果反序列化是罪魁禍首，那不應該發生，對吧？你有什麼想法，爲什麼計數（*）會如此緩慢，如果壓縮會有所幫助？另一個輸入是在我的數據庫中只有插入，從未刪除條目。 – Ouroboros 2013-03-19 11:01:06

在cassandra中獲取partitionID的所有記錄會導致RPC超時

回答

相關問題