是否可以避免卡桑德拉的墓碑問題？

我正在爲使用Cassandra作爲數據庫系統的CMS編寫代碼。是否可以避免卡桑德拉的墓碑問題？

CMS的優勢之一是使用後端計算機預先計算各種東西，該計算機可以針對CMS中更改的數據永久運行。

例如，CMS告訴列表系統已創建或更改頁面。列表系統將該信息保存在名爲list的表中。這些信息只是一個班輪，它告訴我哪些頁面需要處理。

Column family: list 
    Row: concerned website (i.e. http://www.example.com/) 
    Column: full URI (i.e. http://www.example.com/this/page) 
     Value: true (because you need something for the column to exist)

在一段時間後（通常小於一個簡單的頁面編輯之後的第二次），該名單後端系統喚醒並看到某一個頁面改變，並開始通過更新所有包含名單的工作就可以了（或不再包含）該頁面作爲元素。這使得前端立即知道列表中元素的個數並沒有在當時的名單是需要運行復雜的查詢非常快速地讀取列表（反對什麼，許多做CMS使用SQL ...）

實際上，我使用list表作爲TODO列表。我必須處理的一組頁面。所以前端添加了對該列表的頁面引用，並且後端在完成後刪除它們。因此，我可以在list表中獲得大量的墓碑。真實世界的影響：我有墓碑失敗，系統開始失敗隨機地方。一旦列表停止工作，系統中的許多其他內容就會停止工作，網站將無法使用。

我減少了Cassandra在特定表格（以及其他一些表格）中處理墓碑的時間，但我想知道我是否按預期使用了Cassandra。在這種環境下是否有更好的方式來處理這種TODO列表？

作爲一個附註：TODO列表可能來自各種不同的後端計算機。在一個小型系統中，您可能只有一個後端對列表數據運行，而在擁有數千用戶的大型系統上，您不可能只有2或3個後端來處理列表。所以擁有Cassandra中的數據非常實用，可以在計算機之間快速分享。

來源

2016-03-26 Alexis Wilke

如果寫一個新的應用程序應該可能避免節儉，它的棄用。 –

@ChrisLohfink，我從Cassandra 0.8開始，但我們正在努力讓Cassandra 3.x獲得CQL而不是節儉。這就是說，我仍然想知道排序是否工作不同或不... –

你基本上實現這被認爲是對Cassandra的一個反模式隊列： http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets

有變通和東西的人做，使他們更好，但它的硬遊戲。一定要使用LeveledCompactionStrategy而不是默認值，這對於較小的工作負載會有很大的幫助。考慮周圍的工作，例如裝箱分區（舊節儉術語中的行）和上面鏈接的文章中的內容，但您可能需要尋找不同的解決方案。

來源

2016-03-27 02:30:57

*「隊列示例可能極端」* - 除非這正是我們遇到的問題......我們的會話表具有類似問題，儘管並不比真正的完整隊列差。 –

降低您的gc_grace_seconds也許是個好主意，但設置爲零是不好的，因爲您可能會丟失刪除。 –

是的，我把它放在3600的幾張桌子上......在這一點上，它似乎並沒有引起問題，但是一旦我們有了它，我們將不得不看到它如何與3.x一起。 –

是否可以避免卡桑德拉的墓碑問題？

回答

相關問題