由于在 CQL3 中支持宽行有两种方法。一种是使用复合键，另一种是使用 Map、List 和 Set 等集合。复合键方法可以有数百万列（转置为行）。这解决了我们的一些用例。
但是，如果我们使用集合，我想知道集合是否可以存储一定数量/数量的数据的限制（就像之前 Thrift C* 支持多达 20 亿列一样）
问问题
7786 次
5 回答
20
强烈建议在集合和地图中仅存储有限数量的数据。
原因：
集合和地图是作为一个整体获取的，完全。您不能对集合进行“切片”，因此将大量数据放入集合/地图中会对读取它们时的性能产生影响
Lists 的 CQL3 实现对于在列表中间的插入/删除没有性能。对于追加/前置操作，它非常快。对于索引 i 处的插入/删除元素，需要先读后写。基本上，列表的一部分将被重写，因为它们需要转移到好的索引
Set 和 Map 的插入/删除性能更高，因为它们使用列键进行存储/排序/索引
现在回答你的问题，集合/地图中的元素数量是否有硬性限制，答案是否定的，从技术上讲，除了 Thrift 中已经存在的经典 20 亿限制之外没有限制是的，它是有限的GlynD 上面提到的 65536。
相关 JIRA CASSANDRA-5428
于 2013-09-02T13:47:03.627 回答
15
除了性能问题之外，还有一个协议问题限制了您可以访问的项目数量为 65536。
于 2013-09-03T09:56:52.057 回答
6
在版本 2.1 中解决了CASSANDRA-5428之后以及使用本机协议的版本 3或更高版本时，修订后的非冻结 集合相关限制是：
======+===========+=================+=============== = 类型 | 尺码 | # 键 | 价值大小 ======+===========+=================+=============== = 列表 | 2B (2 31 ) | 不适用 | 65,535 (2 16 -1) 组 | 2B (2 31 ) | 不适用 | 65,535 (2 16 -1) 地图 | 2B (2 31 ) | 65,535 (2 16 -1) | 65,535 (2 16 -1) ======+===========+=================+=============== =
通过 Thrift 和早期版本的 C* 本机协议连接的客户端仍然受到这些相应传输的限制。
于 2015-12-11T05:47:05.100 回答
4
除了集合中 64k 个项目的限制之外，来自http://www.datastax.com/documentation/cql/3.1/cql/cql_using/use_collections_c.html：
这是两个限制：
项目的最大大小限制为 64k（未分割短的最大值）
集合中的项目数限制为 64K（未分割短片的最大值）
于 2014-08-26T19:32:46.013 回答
0
集合也被序列化，因此这增加了开销。另见 CASSANDRA-5428。
于 2014-10-27T10:19:02.463 回答