单节点环境下HDFS与Cassandra存储量差异疑问：为何Cassandra占用更大空间？

这个问题挺典型的，结合你用的Cassandra 2.1.9版本，我来拆解下为啥会出现列存储反而占用更多空间的情况，主要有这几个核心原因：

1. 存储模型的本质差异：文件系统vs分布式数据库 #

HDFS是分布式文件系统，核心是直接存储原始二进制数据块，除了块级元数据（比如块ID、存储节点），几乎没有业务层的额外开销。你用的COMPRESS.BLOCK是块级压缩，直接对原始二进制数据进行压缩，所以能把31M的数据压到16.4M。

而Cassandra是分布式列数据库，哪怕你存的是二进制BLOB，它也需要为数据添加大量元数据和辅助结构，来支撑分布式查询、分区索引、ACID特性等能力。这些开销在小数据量场景下会被放大，甚至超过原始数据的大小。

2. CQL接口的封装开销 #

你通过CQL写入二进制数据时，Cassandra会把数据封装成结构化的列格式：

• 每个BLOB列会存储列名、类型标记、值的长度信息；
• 每行数据会附带分区键、默认时间戳（哪怕没设置TTL）、行级状态标记；
• 如果数据是拆分成多行写入，这些行级元数据的累积开销会非常可观。

而HDFS没有这一层封装，直接把二进制数据当成连续的字节流存储。

3. SSTable的多组件存储开销 #

Cassandra的数据最终落地为SSTable文件，每个SSTable包含多个独立组件，每个组件都会占用额外空间：

• Data.db：压缩后的核心数据文件；
• Index.db：分区索引，用来快速定位分区位置；
• Filter.db：布隆过滤器，用来快速判断分区是否存在；
• CompressionInfo.db：压缩块的元数据信息；
• 还有统计信息、摘要文件等辅助文件。

这些辅助文件在小数据量场景下占比很高，比如布隆过滤器哪怕只有一个分区，也会占用几MB空间。

4. 默认压缩的实际效果差异 #

Cassandra 2.1.9的默认压缩算法是Snappy（可以用DESCRIBE TABLE命令确认），但它的压缩是针对SSTable块，且仅在flush或compaction时生效。另外，Cassandra存储的是带元数据的结构化数据，这些元数据的可压缩性远低于原始二进制数据，所以整体压缩率会比HDFS低很多。

如果你的数据还在MemTable（内存临时存储）里，此时数据是未压缩的，会占用更大空间——可以用nodetool cfstats查看是否有未flush的MemTable，执行nodetool flush your_keyspace.your_table强制落地后再看存储量。

排查步骤建议 #

• 确认压缩配置：执行DESCRIBE TABLE your_table;，检查compression字段是否启用了压缩，以及使用的算法；
• 查看SSTable组件大小：到Cassandra数据目录（默认/var/lib/cassandra/data/[keyspace]/[table]-xxxx），查看各个文件的大小，定位哪个组件占比最高；
• 优化数据模型：如果业务允许，把分散的二进制数据合并成单个大BLOB列，减少行/列级的元数据开销；
• 手动测试压缩率：用Cassandra默认的压缩算法（比如Snappy）手动压缩你的31M原始数据，对比压缩后的大小，再加上预估的元数据开销，判断是否符合当前的50M存储量。

内容的提问来源于stack exchange，提问作者Jenny.D