我想知道您對使用Cassandra執行 RBAC樣認證&授權模型的意見。我們已經簡化了通用模型 （http://en.wikipedia.org/wiki/Role-based_access_control）至 中央關係：Cassandra作爲基於角色的訪問控制系統的數據庫
用戶--- N：M --- ---作用ñ ：m ---資源
用戶和資源使用外部可見的標識符進行索引。 這些標識符也必須是「可重用的」（想想：郵件別名）。
考慮Cassandra的主要原因是可用性，可擴展性 和（全局）地理冗餘。 RBDMS很難實現。
另一方面，RBAC有許多m：n關係。儘管某些不一致可能是可接受的，但資源所有權（即角色=擁有者）絕不可混用。
您認爲如何？這樣的關係模型是否是Cassandra 的反模式？你知道基於Cassandra的類似解決方案嗎？
我打算繼續，將我的意見轉換爲答案，以便他們在一個地方。
雖然您擁有一個大型探測數據集，但如果我正確讀取了100,000,000個帳戶，您還需要強制執行一定級別的一致性以確保特定關係永遠不會失去同步。您還需要強制執行許多一對多關係（資源 - >用戶或上面的m：n）。另外，聽起來你會從數據集中讀取數據而不是寫入數據集。隨後，我認爲具有熱備份的RDBMS將比定製的Cassandra部署更好地解決您的問題。 這之中背後的原因：
在RDBMS一個一對多的關係可以表述爲跨表的連接SQL語句，你只需要存儲數據一次。在Cassandra中，根據設置，您必須在多個位置存儲相同的信息以正確反映關係。這會導致一個相當混亂和冗餘的數據模型。
一致性 - Cassandra最終是一致的，這在處理大多數數據時很好，恕我直言。但是，在處理像安全性這樣的需要始終保持一致性的內容時，RDBMSes（複數？）在事務中具有顯着的優勢，以確保您的數據始終保持同步。從安全角度來看，我認爲這很重要。
讀取速度 - 在RDBMS中使用索引會顯着加快讀取數據庫的速度，所以我不會將其作爲驅動決策因素，直到您可以憑經驗確定將是一個重大瓶頸。 Cassandra的法定人數閱讀模型在某些方面可能會變慢，因爲您必須在N臺機器（其中N> = 1）上等待才能返回答案，並在答案不同步時更正答案。
冗餘 - 具有熱備份（主 - 主複製）的RDBMS可解決冗餘問題。
Cassandra的一個偉大的工具，我喜歡用然而，在這種情況下，我覺得你的模型作品更好地與比它與卡桑德拉做了RDBMS。
祝你好運！
然而，我有一個重要的要求：全球地理冗餘。 Cassandra支持開箱即用，而使用RDBMS的多主版本也會遇到諸如丟失更新或混合更新等問題。 – 2012-03-19 15:38:36
確實如此，但您仍然可以通過Cassandra丟失數據。如果部分仲裁寫入失敗，則整個寫入失敗。使用RDBMS，即使更新失敗，您仍然至少有一個位置的數據。請參閱PG維基，瞭解有關羣集postgres的更多詳細信息，作爲擴展RDBMS的示例：http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling – FloppyDisk 2012-03-19 16:00:31
@FloppyDisk當您在Cassandra中編寫的一致性級別不能滿意（即你沒有得到法定數量的節點的迴應，如果這是你所要求的），客戶得到一個例外讓他們知道發生了什麼。寫入可以與Cassandra媲美，因此您可以安全地重試該寫入，直到成功爲止，而不用擔心覆蓋新的更改。沒有涉及數據丟失。 – 2012-03-22 16:45:50
在進入RDBMS和NoSQL之前，在評估Cassandra時，想到了兩個直接的問題。 1）你要處理的數據集有多大？ 2）您將數據添加到數據的頻率和速度有多快？例如，您從1TB數據集開始，每天將添加10GB的數據。如果你有一個較小的數據集並且它不會增長太多，我認爲RDBMS可以爲m：n關係提供更多的功能，而無需做額外的工作。 – FloppyDisk 2012-03-19 12:37:06
如果您沒有大量寫入操作，我會傾向使用熱備份的RDBMS來實現安全性。原因在於您可以使用索引來加速RDBMS中的讀取操作，並且您將能夠執行m：n關係，而無需編寫大量列系列來處理這一切。您還可以確保您沒有任何不一致 - 我認爲您在實施安全體系結構時需要這樣做。 – FloppyDisk 2012-03-19 13:04:22
約100.000.000帳戶。不是繁重的寫入負載，而是大量的讀取 – 2012-03-19 13:05:03