我注意到由於其分區限制爲100MB，關係無法正確存儲在C *中，非規範化在這種情況下無助於C *可以爲每個分區創建2B個單元，而不僅僅是Longs的2B單元有16GB？！？！？這是不是跨越了100MB的分區大小限制？cassandra無法存儲跨分區大小限制的關係嗎？
這是我一般不明白的地方，C *宣稱它可以有2B單元，但分區大小不應該跨越100MB？
這樣做的習慣用法是什麼？人們說這對於TitanDB或JanusDB來說是一個理想的用例，可以很好地擴展數十億個節點和邊緣。這些在數據模型下使用C *的數據庫如何呢？
礦的使用情況下，這裏描述https://groups.google.com/forum/#!topic/janusgraph-users/kF2amGxBDCM
請注意，我充分意識到的事實，這個問題的答案是「使用額外的分區鍵減小分區大小」但說實話，誰的我們有這種可能嗎？特別是在建模關係中......我對某個小時內發生的關係不感興趣......
分區中的最大單元格數（行x列）爲20億，單列值大小爲（推薦1 MB）2 GB
來源：http://docs.datastax.com/en/cql/3.1/cql/cql_reference/refLimits.html
分區大小100MB不是上限。如果您檢查datastax文檔
爲了實現高效操作，分區的大小必須在Apache Cassandra™的特定限制內。分區大小的兩種度量是分區中值的數量和磁盤上的分區大小。調整磁盤空間的大小比較複雜，涉及每個表中的行數和列數，主鍵列和靜態列。每個應用程序將有不同的效率參數，但是一個好的經驗法則是，保持行的10萬個以下項目的最大數量，並在100 MB
磁盤大小
你可以看到，對於高效運行和低堆壓他們剛剛制定了一個很好的經驗法則是在單個分區中保留100,000行和100MB磁盤大小。在鄰接表格式
TitanDB或JanusDB存儲圖形，這意味着的曲線圖被存儲爲與它們鄰接列表的頂點的集合。頂點的鄰接列表包含所有頂點的入射邊（和屬性）。
他們使用VertexID是分區鍵，PropertyKeyID或EdgeID作爲聚簇鍵和屬性值或邊屬性作爲普通列。
如果使用卡桑德拉作爲存儲後端。 在TitanDB或JanusDB中，爲了高效操作和低堆壓力，應用相同的規則，意味着頂點的邊數和屬性數爲100000，大小爲100MB。