我注意到由于其 100MB 分区限制，关系无法正确存储在 C* 中，非规范化在这种情况下无济于事，而且 C* 每个分区可以有 2B 单元，因为只有 Longs 的那些 2B 单元有 16GB ?!?!? 这不是超过 100MB 分区大小限制吗？
这是我一般不明白的，C* 宣称它可以有 2B 个单元，但分区大小不应该超过 100MB ???
这样做的惯用方法是什么？人们说这是 TitanDB 或 JanusDB 的理想用例，可以很好地扩展数十亿个节点和边缘。这些在后台使用 C* 的数据库如何对它进行数据建模？
我的用例在这里描述https://groups.google.com/forum/#!topic/janusgraph-users/kF2amGxBDCM
请注意，我完全清楚这个问题的答案是“使用额外的分区键来减小分区大小”，但老实说，我们当中谁有这种可能性？特别是在建模关系中......我对特定时间发生的关系不感兴趣......
分区中的最大单元数（行 x 列）为 20 亿，单列值大小为 2 GB（推荐 1 MB）
来源：http ://docs.datastax.com/en/cql/3.1/cql/cql_reference/refLimits.html
分区大小 100MB 不是上限。如果您检查 datastax 文档
为了高效操作，分区的大小必须在 Apache Cassandra™ 中的特定限制内。分区大小的两个度量是分区中值的数量和磁盘上的分区大小。调整磁盘空间比较复杂，涉及到每个表中的行数和列数、主键列数和静态列数。每个应用程序将有不同的效率参数，但一个好的经验法则是将最大行数保持在 100,000 项以下，磁盘大小保持在 100 MB 以下
您可以看到，为了高效操作和低堆压力，他们制定了一个很好的经验法则，即在单个分区中保持 100,000 行数和 100MB 磁盘大小。
TitanDB 或 JanusDB 以邻接列表格式存储图形，这意味着图形存储为带有邻接列表的顶点集合。顶点的邻接列表包含顶点的所有入射边（和属性）。
他们使用 VertexID 是分区键，PropertyKeyID 或 EdgeID 作为集群键和属性值或边缘属性作为普通列。
如果您使用 cassandra 作为存储后端。 在 TitanDB 或 JanusDB 中，为了高效运行和低堆压力，同样的规则适用，意味着顶点的边数和属性数为 100,000，大小为 100MB