cassandra使用心得

Apache Cassandra是一種快速且可擴展的數據庫，多年來，它變得與傳統SQL數據庫一樣容易使用。 至少在表面上。

您使用類似SQL的查詢，但是它們有很多限制； 您有一個模式，但是修改它并不像在SQL數據庫中那樣靈活； 您具有帶主鍵的相同表格結構，但是由于分區鍵和排序鍵之間的區別，因此更加復雜。 乍看之下，有很多底層細節并不重要，但對于性能和數據一致性至關重要，例如墓碑，SSTable壓縮等。

但是我想討論“列表”列類型，因為最近我們遇到了一個非常難以捉摸的問題。 我們致力于保證數據的完整性，這就是為什么我們的記錄永遠不會更新的原因。 這對于Cassandra非常適合，因為要正確地進行更新很棘手。 但是，在我們的其中一個部署中，我們注意到了一些奇怪的事情-極少數情況是，與索引數據進行比較后，成千上萬個特定條目中的數據哈希值不匹配。 經過調查，我們注意到“列表”類型的列具有重復值。 這不是代碼的問題，因為在這種特殊情況下，代碼始終使用Collections.singletonList(..)

看起來Cassandra試圖變得聰明，當它在批處理插入中看到相同的條目時，它試圖合并它們，而不是覆蓋另一個，而是試圖將它們合并，從而產生具有重復條目的列表。 有關問題的報告在此處和此處 。

現在，批處理是一個困難的話題，而其中的一些事情看起來直截了當卻不是。 在大多數情況下， 批次是反模式 。 在某些情況下，批處理是有用的 ，但是它比預期的少得多。 那是由于Cassandra的分布式性質。 另一個麻煩來自于您使用的是令牌感知客戶端還是令牌感知客戶端策略，即您的客戶端是否知道每個記錄所屬的位置以便向其發送請求。 我不會詳細介紹批處理，因為在這兩篇鏈接的文章中對批處理進行了很好的解釋。

返回列表–由于在我們的案例中我們沒有相同的記錄，因此該問題很可能是由于網絡超時而導致的，此時客戶端未收到對寫入的確認，并再次嘗試再次發送相同的語句。 我不確定是否批量處理。 但是，假設有批處理或無批處理可能會更安全。 即列表可以在意外情況下合并。

這是根本不使用列表的嚴重原因。 沃爾瑪給出了其他參數

集應優先于列表，因為集（和地圖）應避免
寫前讀模式用于更新和刪除

這僅適用于少量物品。 對大量（例如數千個）項目使用集合是另一個問題，因為您無法分批加載項目-可以一次讀取所有項目。

例如，在Java應用程序中，即使基礎列的類型為List，您也可以輕松地用Set替換List，這將暫時避免出現問題-數據仍然可以在數據庫中重復，但是至少應用程序會使用獨特的價值觀。 但是請記住，Java Set不能保證排序，因此，如果這對您的邏輯很重要，請確保按照一些定義明確的比較標準進行排序。

“避免使用清單”（和“避免使用批次”）的一般建議可以準確地描述Cassandra。 它看起來易于使用，但是一旦投入生產，您可能會意識到存在一些次優的設計決策。

翻譯自: https://www.javacodegeeks.com/2019/02/avoid-lists-cassandra.html

cassandra使用心得

總結

以上是生活随笔為你收集整理的cassandra使用心得_避免在Cassandra中使用清单的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。