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

lis*_*sak 1 cassandra titan cassandra-3.0 janusgraph

我注意到由于其100MB的分区限制,关系不能正确地存储在C*中,在这种情况下非规范化没有帮助,并且C*每个分区可以有2B个单元这一事实,因为只有Longs的那些2B单元有16GB ?!?!?不跨越100MB分区大小限制吗?

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

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

我的用例在这里描述https://groups.google.com/forum/#!topic/janusgraph-users/kF2amGxBDCM

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

Ash*_*lam 6

分区中的最大单元数(行x列)为20亿,单列值大小为2 GB(建议为1 MB)

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

分区大小100MB不是上限.如果您检查datastax doc

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

您可以看到,为了实现高效操作和低堆压力,他们只做了一个经验法则就是在一个分区中保持行数100,000和磁盘大小100MB.


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

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

泰坦数据布局

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