在Cassandra表中以Blob形式存储PDF文件是否可行？

当然支持！Cassandra完全能搞定以Blob形式存储PDF文件的需求，不过实际操作里有几个要点得留意，我给你慢慢梳理：

Cassandra本身就提供了blob数据类型，专门用来存储二进制数据——像你说的5-10MB的PDF，完全在它的处理范围内。单个Blob的理论上限是2GB，你的文件大小远低于这个阈值，容量上根本不用担心。

因为是时序数据库，表结构得贴合时序查询的需求，给你两个参考方案：

• 以文件唯一标识为主键：适合需要快速通过文件ID查找的场景

CREATE TABLE pdf_metadata (
    file_id UUID PRIMARY KEY,
    timestamp TIMESTAMP,
    pdf_blob BLOB,
    file_name TEXT,
    file_size INT
);

• 以时间分区为主：适合按时间段批量查询文件的场景，能提升时序查询效率

CREATE TABLE pdf_metadata (
    year INT,
    month INT,
    file_id UUID,
    timestamp TIMESTAMP,
    pdf_blob BLOB,
    file_name TEXT,
    file_size INT,
    PRIMARY KEY ((year, month), file_id)
);

这里要注意，Cassandra建议单个分区的总大小控制在100MB以内，所以按时间分区时，要确保每个分区（比如某一年某一月）里的所有PDF总大小不超这个数，避免分区过大拖慢性能。

• 写入时：不管用什么客户端SDK（Java、Python、Go等），都能把PDF的二进制内容直接转换成Blob格式传入——比如Java用ByteBuffer，Python直接传bytes类型就行。
• 读取时：拿到Blob数据后，要转成二进制流再保存成PDF文件，这个过程SDK也都有对应的方法，不难实现。

如果你的元数据表核心是存文件的时序信息，PDF本身访问频率不高，也可以考虑把PDF放到对象存储（比如MinIO这类），然后在Cassandra里只存文件的访问链接、文件名、时间戳这些元数据。这种方式的好处是：

• 减轻Cassandra集群的存储压力，让它专注处理元数据的高速读写
• 大文件下载可以直接走对象存储的优化链路，性能更好
  但如果你的业务要求PDF和元数据强一致，或者需要在Cassandra里做事务性操作，那直接存Blob还是更合适的选择。

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