我的桌子是時間系列之一。查詢將處理最新的條目，TTL將在成功處理後過期。如果他們沒有成功處理，TTL將不會被設置。用cassandra查詢時間序列數據的最佳方法是什麼？
我計劃在此上運行的唯一查詢是爲給定的entry_type選擇所有條目。它們將被處理並且對應於處理的條目的記錄將會過期。
這樣每次我運行這個查詢時，我都會得到表中所有未處理的記錄，並且處理完成。這是一個合理的方法嗎？
將我自己的執行程序使用listenablefuture添加任何值，考慮到執行select的線程正在處理。
我很關心TTL和墓碑。但是如果我使用timeuuid類型的聚簇鍵，這是否正確？
你是對的一個重要的事情，你的方式將是墓碑。默認情況下，你將保持他們10天左右。根據您的訪問模式，這可能會導致嚴重問題。您可以通過直接在表上設置或在cassandra yaml文件中將其更改來降低此值。那麼這將是適用於所有新創建的表gc_grace_seconds
http://docs.datastax.com/en/cql/3.1/cql/cql_reference/tabProp.html
，你要確保你正在運行的整個羣集上的修復此期限內，一旦它是非常重要的。因此，如果您將此設置降低爲2天，那麼在兩天內您必須在羣集上完成一次完整修復。這非常重要，因爲處理的數據會收割。我看到這種情況多次發生，並且從未令人愉快，特別是如果您將cassandra用作隊列，並且在我看來您可能會在解決方案中使用它。我會在答案的最後給出一些提示。
我有點擔心你動態地根據結果設置ttl。插入ttl-ed數據是成功的，並且永遠保留那些沒有的數據。我想一些審計或類似的東西。再次，這是一個隊列模式，儘可能避免這種情況。還有一件事要記住的是，你幾乎總是會在開始時插入一次數據，然後再次使用ttl來處理數據。
同樣獲取所有條目可能有點棘手。對於非常適中的負載10-100 req/s，這可能是合理的，但如果每秒有數千次獲得所有請求，那麼每次都可能不是一個好主意。至少不是如果你把它們放入單個分區。
分離工作量也是個好主意。因此，使用可聽的未來似乎完全合法。
將聚簇鍵設置爲timeuuid通常是時間序列的情況，我和這個人完全同意你的觀點。
實際上，正如我前面提到的，你必須考慮到你將會保存10天的數據（除非你調整了它），無論你做什麼，它都無關緊要。它仍然會是，並且每次cassandra掃描分區都必須讀取ttl-ed列。總之這只是痛苦。如果我是你，我會認真考慮實際使用卡夫卡這樣的東西，因爲你所描述的只是看起來像一個隊列。
如果你仍然想堅持cassandra，那麼請考慮使用桶（添加日期信息分區鍵和有一個複合分區鍵）。根據您所期望的負載，您將不得不按月，周，日，小時甚至幾分鐘進行存儲。在某些情況下，您甚至可能需要添加人造列以減少羣集上的負載。但是，這又可能超出了這個問題的範圍。
使用cassandra作爲隊列時非常小心，它是一個已知的反模式。你可以做到這一點，但是有很多變量，它非常依賴於你使用的負載。我曾經諮詢過一支像卡桑德拉隊一樣排隊的隊伍。由於基本上使用cassandra，所以我必須推薦他們在一天之內收集數據（做了一些計算，證明這是正確的時間單位），我也看到了這個解決方案https://github.com/paradoxical-io/cassieq基本上這個回購中有很多好東西使用cassandra作爲隊列，數據模型等基本上這個團隊有殭屍行，由於墓碑等緩慢閱讀等。
此外，你描述它的方式可能會發生，你有「熱行」基本上是因爲你只會有一個寬分區，所有的數據都會在集羣中的某些節點上使用，甚至沒有那麼好用。這可以通過人造色譜柱來避免。
當使用cassandra作爲隊列時，很容易混淆了很多東西。 （但是對於中等工作負載是可能的）