Cassandra存储单条记录1280个浮点数：列表与多行方案差异咨询

业务与现有方案现状 #

你需要在Cassandra中为每条记录存储1280个单精度浮点数，数据写入后不会执行更新、删除操作，所有读取操作均来自Spark任务，通过令牌范围做跨节点的大范围批量扫描，不存在单独读取某一个浮点数分量的查询需求。
你当前在生产运行的第一版Schema，是用LIST类型整组存储所有向量值：

CREATE TABLE data_point (
    account ASCII,
    groupkey TINYINT,
    productid TEXT,
    vectors LIST<FLOAT>,
    PRIMARY KEY ((account, groupkey), productid)
) WITH CLUSTERING ORDER BY (productid ASC);

目前这套方案运行稳定，但你在犹豫是否需要将1280个浮点数拆分为独立行存储，对应的备选拆分行Schema草稿如下：

CREATE TABLE data_point (
    account ASCII,
    groupkey TINYINT,
    productid TEXT,
    vector FLOAT,
    PRIMARY KEY ((account, groupkey), productid)
) WITH CLUSTERING ORDER BY (productid ASC);

注：这份拆分行的Schema存在主键逻辑缺陷——如果没有额外增加向量位置索引列作为聚簇键，同一个productid下仅能存储1个浮点数值，根本无法容纳1280个独立分量，会直接触发主键冲突的写入错误。
你产生纠结的核心原因，是看到Datastax文档的明确提示：

集合（Collections）适用于存储/反规范化相对少量的数据。

但文档没有说明“少量”和“大量”的具体量化边界，不确定1280个浮点数是否已经超出了集合类型的适用范围。

方案对比与选型结论 #

集合类型的实际适用边界 #

Cassandra的LIST、SET、MAP等集合类型，底层是以单个单元格的形式存储整组数据的，真正影响性能的从来不是集合里的元素个数，而是单元格的总大小：

• 业内通用的优化建议是单个单元格的总大小不要超过10KB，一旦超过这个阈值，读取时需要把整份单元格数据拉取到节点内存做全量反序列化，容易出现读超时、堆内存占用过高的问题，压缩、compaction 阶段的开销也会显著上升。
• 你要存储的1280个单精度浮点数，单值占4字节，整组向量总大小仅为5KB左右，完全处于集合类型的性能舒适区，远未达到大单元格的风险阈值。文档提到的“适合存少量数据”，本质上是在提醒用户不要把几十KB甚至上百KB的大块数据塞进集合单元格，而不是限制集合内的元素数量。

拆分行方案的实际开销 #

如果硬要把1280个浮点数拆成独立行存储，反而会带来不必要的性能损耗：

• 写入端：原本1次写入即可完成的向量存储，会被放大为1280次写入，SSTable的条目数、一致性校验开销、磁盘随机写入量都会提升上千倍。
• 读取端：你的所有读取都是Spark批量全量扫表，拆分行的模式根本发挥不了“按行单独查询分量”的优势，反而会把原本连续的向量数据拆成上千倍的行扫描任务，网络传输、内存反序列化的开销都会大幅上升，完全匹配不上你的读取场景。
• Schema维护成本：如果要正确实现拆分行存储，必须额外增加向量索引列作为聚簇键，整个表的主键结构会从原来的两层聚簇变成三层，后续查询、数据迁移的复杂度都会显著提升。

最终选型建议 #

保留当前用LIST<FLOAT>存储整组向量的方案即可，没有必要做拆分行改造。哪怕后续向量长度翻倍到2560个浮点数（总大小10KB），只要不出现单单元格数据持续膨胀到几十KB的情况，这种方案的性能都会远优于拆行存储的模式。

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