# Summary 为什么做预训练数据 **不** 用 MySQL 1. **吞吐瓶颈** - 训练时 GPU 期待 _GB/s_ 顺序读；MySQL 点查 + 网络交互会拖慢流水线。 2. **无索引需求** - 预训练只按**顺序**遍历文本，不需要按主键 / 二级索引检索。 3. **压缩与成本** - 文件 + zstd 压缩可轻松做到 2‑3× 体积缩减；MySQL 行格式无法针对长文本高效压缩。 4. **易部署 & 可移植** - 分 shard 的 JSONL/Parquet 放任何对象存储即可；拷贝目录就能训练，省去 DB 迁移。 # Cues # Notes ## 两种做法的核心定位 |维度|DataTrove / NeMo Curator（分片 JSONL/Parquet）|传统 MySQL 存储| |---|---|---| |**目标场景**|**离线批量训练**：一次写入、顺序流式读取，追求 _高吞吐 + 压缩比_|**在线事务/查询**：高并发随机读写、ACID| |**数据类型**|巨量**半结构化长文本**（网页段落、元数据）|典型**结构化行数据**（行/列固定、短字段）| |**IO 模式**|训练时 _sequential scan → batch loader_；写时追加|点查 / 索引查询；频繁 INSERT/UPDATE| |**可扩展性**|直接把 shard 放对象存储；节点越多吞吐越高|水平分库分表成本高；索引维护贵| |**压缩/成本**|zstd /gzip 按文件压缩，冷数据=冷存储|存储行格式 + 索引，压缩有限，空间贵| |**依赖/复杂度**|依赖少，不必部署数据库；本地或 S3 均可|需运维 MySQL 集群、备份、主从同步| |**与 PyTorch/Megatron 对接**|DataLoader 直接 mmap / fsspec 逐 shard 读|需自写 connector 拉行数据、性能瓶颈| --- ## 为什么做预训练数据 **不** 用 MySQL 1. **吞吐瓶颈** - 训练时 GPU 期待 _GB/s_ 顺序读；MySQL 点查 + 网络交互会拖慢流水线。 2. **无索引需求** - 预训练只按**顺序**遍历文本，不需要按主键 / 二级索引检索。 3. **压缩与成本** - 文件 + zstd 压缩可轻松做到 2‑3× 体积缩减；MySQL 行格式无法针对长文本高效压缩。 4. **易部署 & 可移植** - 分 shard 的 JSONL/Parquet 放任何对象存储即可；拷贝目录就能训练，省去 DB 迁移。 --- ## 什么时候 **会** 把文本放 MySQL？ - **在线检索 / 辅助特征**：需要按 user_id、time_range 实时查询日志、评论等。 - **数据标注平台**：UI 连 MySQL 做增删改查、状态追踪。 - **小规模实验**：几十万条文本，团队已有 MySQL，临时可用。 --- ### 📌 一句话总结 > **预训练语料 = 大型离线顺序读** → 用分片文件 + 轻量 Writer； > **业务数据 = OLTP 随机读写** → 用 MySQL / ClickHouse 等数据库。