Cassandra中CQL的blob类型是否支持存储PDF文件？

前置说明：本次技术选型由客户强制要求使用Cassandra，以下回答仅围绕Cassandra本身的能力边界展开，不讨论其他数据库替代方案。

Cassandra在技术能力上完全支持存储PDF文件，只是从架构设计层面不推荐存储大体积二进制文件。
Cassandra的核心定位是高并发、低延迟的分布式小数据读写系统，大体积文件存储和它的设计目标相悖：

• 大体积二进制数据写入会导致单分区体积快速膨胀，轻则拖慢对应分区的读写性能，重则引发节点内存溢出，影响集群稳定性
• 大文件读写会占用大量网络、磁盘IO资源，挤占同节点上核心业务请求的资源配额
• Cassandra没有针对大文件做分片传输、断点续传类优化，大文件读写失败后的重试成本极高
  如果你的PDF模板单文件体积普遍在1MB以内，且写入频率极低、读取频率可控，临时存储满足业务需求完全可行；如果单文件体积普遍超过数MB，哪怕强制要求使用Cassandra，也更建议在Cassandra中仅存储PDF模板的元数据（模板ID、版本、更新时间等），二进制文件存到对象存储节点，通过元数据关联访问路径——这是工程层面的折中优化方案，不涉及数据库选型替换。

是。Cassandra的blob类型本质就是可变长的无格式字节序列，所有要写入blob列的二进制内容，不管是PDF、图片还是其他格式文件，都需要先序列化为字节数组才能写入；读取时拿到返回的字节数组，再反序列化为对应格式的文件流做后续填充操作即可。
这里也正好说明你提到的和Oracle BLOB的差异：Oracle的BLOB是专门设计的大对象类型，数据库内部会为大对象分配独立表空间、做存储块优化；而Cassandra的blob数据和同分区的其他列数据是一起存储在SSTable文件中的，没有独立的大对象存储优化机制，这也是大体积blob会影响性能的核心原因。

blob类型从设计之初就是用来承载小体积非结构化二进制数据的，常见的合理使用场景包括：

• 存储短长度的加密哈希值、数字签名、加密后的敏感短字段
• 存储KB级的序列化小对象（比如Protobuf、Thrift序列化后的短结构化数据）
• 存储小尺寸的缩略图、图标等体积很小的二进制静态资源
  它的设计目标从来不是承载MB级以上的大文件、音视频、文档类资源，这类场景本身就不在Cassandra的能力覆盖范围内。

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