前几篇我们都在用 SkyWalking埋点、关联、告警。但当你真把大模型链路全量接进生产第一个被冲垮的往往不是 Agent而是 OAP 背后的存储。大模型 Trace 有几个特点Span 多三层 流式、Tag 和日志体量大、写入峰值高并发问答。选错存储OAP 会出现写入堆积、查询超时最终监控自己先挂了。SkyWalking 通过 storage.selector 支持多种后端官方主推 Elasticsearch也支持 H2单机演示、MySQL、PostgreSQL、BanyanDB 等。本篇对比 H2 / MySQL / ES 三类最常用的后端给出配置实战、性能数据、调优要点帮你为大模型场景选对存储。SkyWalking 后端的存储角色三种存储后端概览H2 / MySQL / ES部署配置实战三种性能对比与压测数据ES 调优实战存储容量与 TTL 管理最佳实践与踩坑1. SkyWalking 后端的存储角色OAP 是无状态计算节点所有原始数据Trace、指标、拓扑、日志都落在外接存储。存储承担三件事写入探针上报的 Span / 指标经 OAP 聚合后批量写库峰值由写入吞吐决定。查询UI 的追踪拓扑指标查询由随机读性能决定。保留历史数据按 TTL 滚动删除由存储的删除效率与容量决定。大模型场景对存储的压力集中在写入流式 Span 高频和容量日志 Tag 多。因此选型的核心指标是写入吞吐、单条查询延迟、水平扩展能力、运维成本。2. 三种存储后端概览H2 / MySQL / ES**H2**内嵌文件数据库零依赖OAP 默认。优点是开箱即用适合本地调试和演示。缺点是完全不支持水平扩展写入并发一高就锁表且重启有数据损坏风险。生产禁用。**MySQL**关系型团队熟悉、运维简单。优点是不用引入新组件已有 DBA 体系。缺点是 SkyWalking 的时序模型每秒上万条 Span对 MySQL 极不友好单表行数爆炸、二级索引维护重、批量插入和范围删除都慢。仅适合中小规模日 Trace 量百万级以下。**Elasticsearch**分布式搜索引擎SkyWalking 官方推荐生产后端。优点是写入吞吐极高LSM 批量、水平扩展好、按时间建索引天然适配 TTL 滚动。缺点是需要独立维护 ES 集群内存占用大查询需要懂 DSL。大模型大规模链路首选。简单对比维度H2MySQLElasticsearch------------部署复杂度极低低中高写入吞吐低中高水平扩展不支持弱分库麻烦强分片查询延迟低量小中低量大也稳适合规模演示百万 Trace/日千万级/日运维成本几乎无低中高3. 部署配置实战三种所有存储通过 config/application.yml 的 storage.selector 切换。下面分别给出配置片段。H2默认仅演示storage:selector: ${SW_STORAGE:h2}h2:driver: org.h2.jdbcx.JdbcDataSourceurl: jdbc:h2:mem:skywalking-oap-dbuser: samaxPoolSize: 10MySQL需先建库并执行 db-scripts/mysql.sqlstorage:selector: ${SW_STORAGE:mysql}mysql:properties:jdbcUrl: ${SW_JDBC_URL:jdbc:mysql://mysql:3306/sw?rewriteBatchedStatementstrue}dataSource.user: ${SW_DATASOURCE_USER:root}dataSource.password: ${SW_DATASOURCE_PASSWORD:root}maxPoolSize: 50注意 rewriteBatchedStatementstrue 很关键它让 MySQL 把批量插入合并写入性能可提升数倍。Elasticsearch推荐生产storage:selector: ${SW_STORAGE:elasticsearch}elasticsearch:clusterNodes: ${SW_ES_CLUSTER_NODES:es:9200}protocol: ${SW_ES_PROTOCOL:http}user: ${SW_ES_USER:}password: ${SW_ES_PASSWORD:}indexShardsNumber: ${SW_ES_INDEX_SHARDS_NUMBER:3}indexReplicasNumber: ${SW_ES_INDEX_REPLICAS_NUMBER:1}# 大模型场景建议调大批量写入bulkActions: ${SW_ES_BULK_ACTIONS:2000}bulkSize: ${SW_ES_BULK_SIZE:20}flushInterval: ${SW_ES_FLUSH_INTERVAL:10}bulkActions / bulkSize / flushInterval 控制 OAP 向 ES 批量写入的节奏是大模型高写入场景的首要调优点。4. 性能对比与压测数据以下为同构压测单 OAP、模拟大模型流式 Trace每条 Trace 含 4 个 Span 1 条日志的近似参考值实际取决于机器规格后端写入峰值 (Span/s)P99 查询延迟日留存上限(单节点)备注---------------H2~800随量飙升数十万锁表明显MySQL~6000500ms~2s百万级依赖批量参数ES(3 节点)~50000200ms 内千万级线性扩展结论很清晰H2 在几百 QPS 就到顶MySQL 到几千写入就开始出现查询变慢ES 在三节点下可轻松扛住大模型高峰单接口数千并发问答。若你们日 Trace 量级在千万以上或要保留日志做关联ES 是几乎唯一选择。一个常被忽略的点查询延迟随数据量增长曲线。H2/MySQL 是数据越多越慢的线性退化ES 因为按天分索引 时间范围查询数据量翻倍查询延迟几乎不变这对长期可观测性至关重要。5. ES 调优实战针对大模型高写入ES 侧有几个直接见效的调优。第一分片数。indexShardsNumber 默认 1~2大模型写入建议 3~5按数据节点数 × 1.5 估算。分片太少写入单点瓶颈太多则元数据开销大、查询扇出多。第二批量写入。上面 bulkActions2000, bulkSize20MB, flushInterval10s 表示累积 2000 条或 20MB 或 10 秒任一条件满足即刷盘大幅降低 ES 写入压力。第三副本与写入分离。写入高峰可临时把 indexReplicasNumber 设为 0写入完成后再动态调回 1避免写入时同步副本拖累。命令curl -X PUT es:9200/sw_segment-*/_settings -H Content-Type: application/json \-d {index:{number_of_replicas:0}}第四JVM 与堆。ES 堆建议不超过 31GB避免压缩指针失效数据节点堆外留足。OAP 侧也要给足堆-Xms4g -Xmx4g 起步否则批量缓冲撑爆。第五冷热架构。大模型 Trace 查询大多只看最近 7 天。用 ES ILM索引生命周期管理把热索引放 SSD 节点、冷索引迁移到普通节点既保性能又省成本。6. 存储容量与 TTL 管理大模型链路数据膨胀快必须靠 TTL 滚动清理否则存储被撑满后 OAP 写入失败、监控全盲。ES 的 TTL 在 application.yml 用 recordDataTTL 和各类留存天数控制storage:elasticsearch:# 各类数据保留天数metricsDataTTL: ${SW_ES_METRICS_TTL:7} # 指标保留 7 天recordDataTTL: ${SW_ES_RECORD_TTL:3} # Trace/日志保留 3 天# 是否启用按天索引强烈建议dayStep: ${SW_ES_DAY_STEP:1}dayStep 控制几天建一个索引大模型高量场景可设为 1每天一索引让删除就是删整个索引比按文档逐条删高效得多。MySQL/H2 没有原生 TTLSkyWalking 靠定时任务按 ttl 删行量大时删除会锁表、拖慢写入这也是它们不适合大规模的另一原因。容量预估公式粗略单 Trace 平均 4 Span 1 日志 ≈ 8KB若日 2000 万 Trace则日增约 160GB保留 3 天需 ~500GB 可用空间含副本翻倍则 1TB。务必留 30% 余量避免写满。7. 最佳实践与踩坑第一生产别用 H2哪怕先跑起来。H2 内存模式重启即丢文件模式并发写入会锁事故复盘时你最需要的恰恰是全量历史 Trace而它没了。演示可以生产必须 ES。第二MySQL 务必开 rewriteBatchedStatements。不开的话 SkyWalking 的批量插入退化成逐条 INSERT写入直接掉一个数量级OAP 后台疯狂报超时。第三ES 分片数提前规划。后期改分片要重建索引、重灌数据成本极高。按未来 6 个月峰值预留而不是当前量。第四监控你的监控。OAP 和 ES 自己也要被监控ES 的 heap、写入队列、磁盘使用率。曾经有团队 SkyWalking 静默挂了一周才发现是 ES 磁盘写满、索引变只读那一周的大模型事故全无链路可查。第五TTL 与合规平衡。金融、医疗类大模型日志可能要求留存更久但全量 Trace 留 30 天成本惊人。建议指标留久趋势分析Trace/日志按需缩短敏感内容脱敏后再存。第六升级注意存储兼容。SkyWalking 大版本升级常改 ES 索引 mapping直接连旧集群可能报错。升级前要么新建存储、要么执行官方提供的 index-name 兼容脚本并备份。选对存储SkyWalking 才能扛住大模型的高写入、大容量、长周期。一句话建议演示用 H2中小用 MySQL开批量生产大规模一律 ES TTL 冷热分层。