我注意到由于其分区限制为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。