为何Cassandra集合不适用于存储无界数据？

用PrimaryKey(chatId)搭配messages集合存储聊天消息，对比PrimaryKey(chatId, timestamp, messageId)的复合主键方案，核心问题集中在这几点：

• 行大小超限带来的性能灾难
  Cassandra对单条行的大小有隐性限制（官方建议不超过1MB，最大不能超2GB），但聊天消息是无界增长的——活跃的私聊、几百人的群聊用不了多久，messages集合就会膨胀到让单条行体积超标。一旦行过大：

  • 读取时要拉取整个消息集合，不仅加载慢到用户无法忍受，还会占用大量集群内存和网络带宽；
  • 写入时会大幅增加压缩、节点间数据复制的开销，拖慢整个集群的处理速度，甚至触发性能告警。

• 读写查询的效率极低

  • 写入：虽然Cassandra的List支持原子追加，但集合越大，每次写入的操作成本越高，高并发场景下消息发送延迟会直接飙升；
  • 查询：用户要加载最近100条消息、或者某天的聊天记录时，用集合必须把全部消息拉到客户端再过滤，完全是资源浪费；而复合主键可以直接通过WHERE chatId = ? AND timestamp > ?精准查询目标范围，性能差几个数量级；
  • 删除：要删除单条消息，集合只能通过元素内容或索引定位，操作复杂又慢；复合主键则能直接通过主键精准删除单条消息，高效可靠。

• 并发写入的吞吐量瓶颈
  同一个chatId对应的是单一行，所有写入操作都要竞争这一行的锁。在高并发场景（比如几百人同时发消息的群聊）下，会出现严重的写入排队，消息发送延迟直接失控。而复合主键结构里，每条消息是独立的行，并发写入互不干扰，集群能充分利用多节点的处理能力，吞吐量直接拉满。

• 数据维护的灵活性缺失
  如果要给旧消息设置TTL自动过期，或者批量归档历史消息，集合结构根本做不到精细化操作——要么整个聊天的消息一起过期，要么只能手动处理；而复合主键可以针对timestamp范围设置TTL，或者批量删除指定时间之前的消息，数据维护灵活得多。

内容的提问来源于stack exchange，提问作者user1745356