文本数据用LMDB或HDF5加速效果有限，因其体积小、解析开销低，而LMDB/HDF5引入序列化、反序列化、键查找和内存映射等固定成本，反而成为瓶颈；真正受益场景是含大尺寸二进制数据或受磁盘随机IO限制时。
为什么文本数据用LMDB或HDF5加速效果有限
直接把纯文本（比如句子、token ID序列）塞进 LMDB 或 HDF5，往往不会明显提速，甚至更慢。原因很实在：文本本身体积小、解析开销低，但 LMDB/HDF5 增加了序列化（dumps_pyarrow）、反序列化（loads_pyarrow）、键查找、内存映射管理等固定成本。尤其当每条样本只是几百字节的 torch.LongTensor（如 BERT 的 input_ids），这些额外操作反而成了瓶颈。
真正受益的场景是：样本含大尺寸二进制数据（如图像像素、音频波形、预提取的特征向量），或者你正被磁盘随机IO卡住（比如从上万个小文件里逐个读取JSON）。对纯文本，优先优化路径在别处。
文本数据该用什么替代方案
如果你的数据是 tokenized 后的整数序列（input_ids, attention_mask 等），最轻量高效的方案是：
- 用
numpy.memmap把所有样本拼成一个大二进制文件（dtype=np.int32），按固定长度切片；__getitem__直接self.data[start:end].copy()—— 零序列化、零磁盘IO、CPU缓存友好 - 若需变长序列，改用
torch.load(..., map_location='cpu')加载.pt文件（用torch.save(torch.stack([...]), ...)预存），比 HDF5 读取快 2–3 倍，且支持pin_memory=True - 完全避开磁盘：训练前把整个 tokenized 数据集 load 到 RAM（例如 10GB 以内），
Dataset.__getitem__只做索引访问 —— 这是最简单也最有效的“加速”
非要上LMDB？注意这三个坑
如果必须用 LMDB（比如和图像多模态数据统一 pipeline），以下配置不调准，性能会比原生 DataLoader 还差：
立即学习“Python免费学习笔记（深入）”；
-
map_size必须显式设够：文本数据虽小，但 key 是字符串（如b'12345'），value 是序列化后的 bytes，总 size 容易低估。建议起步设1099511627776（1TB），否则写入中途报MapFullError - 禁用
meminit=False和map_async=True：文本场景不需要 mmap 初始化优化，反而增加首次访问延迟；map_async在小 value 下无收益，还可能引发竞态 - key 编码必须用
ascii，不要用utf-8：LMDB 内部按字节比较，u'{}'.format(idx).encode('utf-8')和ascii行为一致，但少一次编码判断 - 避免在
__getitem__里做loads_pyarrow：把它提到__init__阶段一次性解包到内存 list，后续只做 O(1) 索引 —— 这才是文本数据该有的访问模式
HDF5在文本场景的硬伤
HDF5 对文本数据天生不友好：
- 每个 dataset 必须声明固定 shape，变长序列只能填 zero-padding + 单独存
lengths，浪费空间且破坏 cache locality -
h5py.File(..., 'r')打开即加载元数据，小文件多时元数据开销 > 数据本身 - 并发读取（
num_workers > 0）下容易触发Unable to open file (file is already open for write)错误，必须加swmr=True且所有 worker 共享同一 file handler，实际做不到 - 没有类似 LMDB 的 atomic commit，写入中断易损坏文件，调试期风险高
除非你在做科学计算类 NLP（比如处理 TB 级对齐的词向量矩阵），否则别碰 HDF5 存纯文本 —— 它的设计目标就不是这个。
