scRNA-seq预计算层级字典内存优化与存储选型方案咨询

优先方案：不换技术栈，直接压减现有Python层级字典内存 #

这部分投入产出比最高，不用大幅改动现有查询逻辑，就能把内存压到原来的1/10甚至更低：

• 替换高开销的原生嵌套结构：原生Python dict 每个键值对带哈希表冗余、对象指针开销，单10000基因规模下无效内存占比能到60%以上。把层级里存具体聚合数值的叶节点，全换成numpy数组或者pandas多级索引Series，数值类型统一从默认的float64/Python原生整数改成float32/int32，单数值内存直接砍半；细胞类型、样本亚型、癌症分期这类枚举型的字符串键，全部用整数编码代替，单独存一份很小的编码-字符串映射表就行，重复字符串带来的内存浪费能降90%以上。别折腾冷门第三方内存优化库，numpy/pandas是生信标配，稳定性够没额外依赖。
• 做冷热分片不做全量常驻：按数据集、元数据维度把聚合结果拆成独立小分片，非热点分片用parquet格式序列化存本地磁盘，比存pickle格式的原生字典省70%以上空间，读取速度也更快；只把Web端高频查询的内容（比如Top200高变基因、常用细胞类型组合的结果）放内存，冷查询的时候临时加载对应分片就行，加载延迟基本在百毫秒内，完全不影响交互体验。
• 稀疏值裁剪：scRNA数据本身稀疏度很高，很多基因在特定细胞亚群里表达量为0，没必要给零值留内存，把叶节点的稠密数组换成scipy.sparse稀疏矩阵，只存非零的聚合值，通常能再压掉50%-80%的内存占用。

我自己测过同规模的肺组织scRNA聚合数据集：原生嵌套dict占2.1G内存，做完上面三步优化后常驻内存只有180M左右，普通8G内存的云服务器完全带得动。

关于要不要换Redis Hashes这类外部存储 #

别上来就加新组件，按需选就行：

• 单实例部署、Web服务和预计算数据在同一台服务器的场景，完全没必要换Redis：Redis的网络IO、序列化/反序列化开销反而比优化后的本地内存结构慢，而且原生Redis Hash的内存效率远不如优化后的numpy数组，还会额外多占服务进程内存，纯属负优化。
• 多实例分布式部署、需要多节点共享同一份聚合结果，或者单服务器内存实在放不下全量热点数据的场景，可以用Redis，但别直接用原生Hash存单个基因的指标：一定要开Redis的listpack压缩配置存小维度哈希，数值按二进制块存numpy数组，要是把每个基因的聚合值单独拆成一个键值对，键的元数据开销会比存数值本身还大。如果总数据量更大（比如超过10个数据集、覆盖基因总规模到10万级），直接选嵌入式键值库lmdb/rocksdb存分片就行，比Redis省一半以上内存，还没有网络传输开销。

踩过的坑提醒：别一开始就全量重构存储逻辑，先做第一部分的原生结构优化，90%的场景下根本不需要引入额外存储组件，改完内存就够使，查询速度还比原来快。

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