Cassandra multitenant配置選項

Question

我們正在評估是否要將構建於PostGres上的多租戶EAV系統移至Cassandra，並且希望通過我們的架構方法獲取輸入以查看Cassandra是否合理。我們的多租戶系統分層結構由帳戶 - >應用程序組成，帳戶可以運行多個應用程序。查詢需要根據應用程序或帳戶進行分隔（聚合帳戶的所有應用程序數據）。帳戶可以在我們的EAV模型中使用自己的自定義字段創建自己的數據對象。

有兩種方法，我考慮採用卡桑德拉。首先是在1列系列中保存一定數量的應用程序（比如20）（以減少使用的列族數量）。每行將由accountid-> appid-> dataobjectid-> recordid的組合列標識。根據應用的需要，將爲每個應用的數據對象實時添加列。這意味着如果列家族有兩個應用程序，第一個應用程序的1行可能定義了20列，而第二個應用程序可能定義了30列。這意味着這兩個應用程序總共會有50個可能的列。目前，應用程序的平均列數爲19.這意味着列系列中的平均列數將爲400.看起來合理並利用了Cassandra的廣泛列支持。實際上，我們可能很容易爲每個列族支持更多的應用程序。缺點是二級索引會很困難，因爲我們不允許用戶創建他們自己的索引，因此查詢在沒有索引的情況下效率不高。

第二種方法是讓兩個列家族擁有1000個應用的所有數據。第一列家族將具有與上面相同的組合列，但它將在JSON文檔中保存該行的整個數據對象。第二列家族將具有相同的組合鍵，但是會爲表示json文檔中的字段的fieldid的鍵添加另一個值（我們的應用元數據管理器存儲UUID以標識JSON文檔中的每個「字段」），但會每個數據類型都有一個「fieldvalue」列 - 字符串，數字，小數點，浮點數（日期和布爾值被轉換爲數字）。這裏的優點是，我們可以很容易地爲搜索目的索引每個列，並且我們正在最小化我們創建的列家族的數量。

以上兩種方法的優缺點是什麼？我是否在上述場景中錯過了明顯或誤解Cassandra的東西（例如，我可以擁有首先是如此寬的複合列）？對於這種類型的應用程序是否還有其他更好的架構建議？

Answer 1

我認爲在決定數據模型時需要回答的第一個問題是「我該如何查詢這些數據？」一般來說，在任何一個模型中，您都無法接近CF，列或組合中的組件數量，所以我不擔心這一點。

考慮到您擔心第一個模型中缺少輔助數據，這告訴我，按值查詢功能可能很重要。如果是這樣，第二個型號可能爲您提供更好的服務。需要注意的是，輔助人員在基數較低的情況下工作得最好，而且您的數據可能不適合這種情況。如果沒有，你可以很容易地創建你自己的索引，在這種情況下，任何模型都可以工作。

我的建議是弄清楚你打算如何讀取你的數據，然後計劃你的模型來匹配你的讀取模式。如果您不確定，請與兩種模型一起玩，看看哪種模式效果最好。根據我的經驗，通常需要不止一次迭代才能制定出一個好的模型，並且您不應該害怕以不止一種方式編寫數據。規範化不是這裏的目標。如果您想更深入地討論您的模型，請查看freenode上的Cassandra IRC頻道（#cassandra）。