cassandra无法存储跨越分区大小限制的关系吗？

Question

我注意到由于其100MB的分区限制，关系无法正确存储在C *中，在这种情况下，非规范化无济于事，而且C *每个分区可以有2B个单元，而不仅仅是那些2B单元多头有16GB？！？！？这是否超过了100MB的分区大小限制？

这是我一般不理解的，C *宣称它可以有2B单元但是分区大小不应该超过100MB ???

这样做的惯用方法是什么？人们说这是TitanDB或JanusDB的理想用例，可以很好地扩展数十亿个节点和边缘。这些使用C *的数据库如何在数据模型下进行建模？

此处描述了我的用例https://groups.google.com/forum/#!topic/janusgraph-users/kF2amGxBDCM

请注意，我完全清楚这个问题的答案是“使用额外的分区键来减少分区大小”但老实说，我们中谁有这种可能性？特别是在建模关系中......我对在特定时间内发生的关系不感兴趣......

Answer 1

分区中的最大单元数（行x列）为20亿，单列值大小为2 GB（建议为1 MB）

来源：http://docs.datastax.com/en/cql/3.1/cql/cql_reference/refLimits.html

分区大小100MB不是上限。如果您检查数据存档文档

  

为了有效运行，Apache Cassandra™中的分区大小必须在一定限度内。分区大小的两个度量是分区中的值的数量和磁盘上的分区大小。调整磁盘空间的大小更复杂，并且涉及每个表中的行数和列数，主键列和静态列。每个应用程序都有不同的效率参数，但一个好的经验法则是保持最大行数低于100,000项，磁盘大小低于100 MB

你可以看到，为了有效运行和低堆压力，他们只是做了一个很好的经验法则是在一个分区中保持行数100,000和磁盘大小100MB。

TitanDB或JanusDB以邻接列表格式存储图形，这意味着图形存储为具有邻接列表的顶点集合。顶点的邻接列表包含所有顶点的入射边（和属性）。

他们使用VertexID是分区键，PropertyKeyID或EdgeID作为聚类键，属性值或边缘属性作为普通列。

如果您使用cassandra作为存储后端。 在TitanDB或JanusDB中，为了有效运行和低堆压力，应用相同的规则，意味着顶点的边数和属性数为100,000，大小为100MB