兔子313仿真优化项目里，存储层往往是最后才被想起、却最早拖后腿的那一块。我们团队做的是多参数仿真优化，用遗传算法加贝叶斯优化在几十个维度里搜参数组合，每天要跑上千个仿真批次，每批产生大量中间指标和输出数据。早期图省事，结果表放MySQL，明细数据直接存JSON文件，后来实验规模一上来，优化算法想读历史样本训练代理模型，一条查询能卡十几秒，整个迭代流程被存储拖到几乎无法推进。数据库选型这件事，听起来是基建问题，实际上直接决定优化算法能不能在合理时间内收敛。这篇文章就是记录我们怎么从一堆候选方案里，最后把OpenTeleDB的Xstore存储引擎接进仿真优化主链路的全过程，包括对比逻辑、表结构设计、参数调优和上线后踩过的坑。
1. 仿真优化项目的数据痛点：存储层怎么就成了瓶颈
1.1 仿真任务的数据画像：批次写入、聚合扫描、低频更新
在做选型之前，我一直坚持一个观点：不看清楚数据长什么样就去聊数据库，都是耍流氓。仿真优化项目的数据和互联网应用、电商系统有本质区别，我先贴一张我们梳理后的数据画像。
| 数据维度 | 特点 | 对存储的影响 |
|---|---|---|
| 写入模式 | 由调度器批量提交，高峰期每秒几千行，平时几乎无写入 | 需要高吞吐批量写入能力，而非高并发小事务 |
| 读取模式 | 优化算法按实验批次拉全量结果做回归，或按参数范围过滤聚合 | 需要列式扫描和聚合性能，点查比例很低 |
| 更新需求 | 任务状态频繁更新（排队中、运行中、完成、失败），结果数据几乎不更新 | 状态字段需要事务和点更新，结果数据只要追加写 |
| 数据生命周期 | 结果数据需要长期保留用于复现实验，日志类数据定期清理 | 需要对冷热数据有区分处理能力 |
| 一致性要求 | 不强依赖强一致，但任务状态不能丢，结果不能半截 | 写入数据可靠持久化，故障恢复不能丢已确认数据 |
这套画像里最要命的是第一条和第二条的组合：写入是突发批量，读取是分析型扫描，而且两者同时出现在一个系统里。MySQL这类传统关系库，小事务点查很在行，但大批量写入时行存储的页分裂、索引维护成本很高；到了扫描阶段，行存天生吃亏，读取一列会把整行数据都拉出来，I/O开销成倍放大。
仿真优化还有一个容易被忽视的问题：中间过程数据特别多。我们的仿真程序每跑一个迭代步就会输出一组观测值，这些值单条不大，但整个批次十几万行，一天跑一千个批次就是上亿条记录。如果存储层没有高压缩，光磁盘成本就够喝一壶。
1.2 存储不是"保存结果"，它直接决定优化迭代速度
很多做仿真的人有个误区，觉得数据库嘛，能存进去、能查出来就行，慢一点就慢一点。但在仿真优化这种场景下，存储层实质上参与到了优化算法的每一轮迭代里。
我们用的贝叶斯优化算法，每一轮都要从历史样本里取一批数据来训练高斯过程代理模型，还要算采集函数。历史样本越多，代理模型越准，但读取速度如果撑不住，样本量就被迫往下压。遗传算法那边更直接，每一代种群评估完，要把整个群体的适应度数据拉回来排序和筛选，这个动作每天要做几百次。
换句话说，存储层的查询延迟直接进到了优化循环的critical path里。MySQL加JSON文件的组合，早期几百个样本时还勉强能用，等样本量到了百万级，一次带条件的历史样本查询经常要十几秒，算法团队只能改小窗口去读，结果就是模型精度上不去，参数搜索效率断崖式下跌。
1.3 我们最初的技术债：MySQL加JSON文件混用
最早这套系统是原型验证阶段搭的，速度优先，所有合理不合理的选择都被容忍了。仿真结果的最明细数据，程序直接写成JSON文件按批次归档，MySQL里只存任务状态和参数组合。等到要做数据分析和模型训练的时候，发现JSON文件没有结构、没有索引，想筛一个参数范围只能写Python脚本挨个文件遍历。后来我们把关键字段抽出来放进MySQL，但明细数据还是躺在文件里，结果就是同一份实验数据拆成两套存储，对账对到怀疑人生。
这个阶段我们得到的教训很简单：数据库选型必须在数据量起来之前做，而且存储方案必须统一，不能在“临时文件”和“正规库”之间搞两套体系。等到百万级数据才想起来换库，迁移成本和风险已经高了不少。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 选型过程：三个候选方向与OpenTeleDB的入场理由
2.1 关系型数据库的问题：事务模型带来的安全感和扫描瓶颈
我们团队对MySQL和PostgreSQL都很熟，最初也是从关系库开始思考的。关系库最大的优势是心智负担低：SQL标准成熟、事务可靠、生态完善、工具链齐全。但仿真优化的数据访问模式和关系库的强项正好错开。
MySQL的InnoDB是行存储，数据按主键聚簇存放，查询某一行确实很快，但做大规模聚合分析时要把整张表扫一遍，I/O开销巨大。我们在测试环境用2000万行的仿真结果表做了一次实验：按参数范围过滤并计算均值，MySQL需要8秒多，这还算上了二级索引的帮助下推了一部分过滤条件。如果是更复杂的多列条件组合，索引基本失效，直接退化成全表扫描。
另外一个问题是压缩。In