第二大脑

主题

2026-08-24
1060
3.7m

国产数据库选型测评方法论（从纸面到可执行 POC） ​

一句话机制：纸面对比只能用来「排除」，不能用来「定选」——选型可信度的地基是「证据分级」，而最终的决策依据只能来自统一口径下的自有数据实测（POC），厂商话术在进入横向排序前一律降级为「待验证项」。

证据分级约定（贯穿全文的地基） ​

选型文档最大的坑是把厂商话术当事实。所有论断必须按下述三级标注，不同级别不得混用于同一结论：

级别含义可用于
A 级官方文档 / 官方公告 / 测评公告 / 采购公示，可原文查证直接作为准入与排除依据
B 级第三方公开资料、社区实践、行业报告仅作参考与提问线索
C 级厂商自述、宣传口径、无口径的数字不得用于横向排序，只能转为待验证项

典型反例：同一份金仓 TPC-C 宣传材料中，单节点 tpmC 在 12,800 与 128,500 之间相差 10 倍，且均无硬件配置、并发数、warehouse 数与审计方——这类数字属 C 级，一律不采信。

方法论六步 ​

  1. 先澄清易混淆项：识别"同名不同物"。如 TDSQL PostgreSQL 版 ≠ TDSQL-C PG 版（后者已停售）≠ TDSQL MySQL 版（TPC-C 榜单成绩主体是 MySQL 系，不能套到 PG 版）。网上大量对比文混淆这三者，结论直接跑偏。
  2. 四维度客观对比（功能 / 性能 / 兼容性 / 生态合规）：功能维度用官方文档可查能力打分，且要指出"真正区分点"而非罗列同质化能力——同质化清单没有决策价值，区分点才有。
  3. 性能维度不横向排序：因为不存在公开可信的同口径基准——任何"某库比某库快 X%"都缺硬件/并发/数据规模/时长/参数/审计方至少三项。做法是全部下沉到实测，用统一压测框架在同规格硬件上跑自有数据。
  4. 兼容性必须按「源库视角」评估：脱离源库谈"兼容率百分比"没有意义。PG 源视角下，同源（瀚高）> 同源+方言适配（金仓）> 分布式语义改造（TDSQL PG）> 异构（达梦），成本档位逐级上升。
  5. 统一索取清单防「三轮拉扯」：向每家厂商一次要清楚授权/环境支持/技术支持，四家一致逐项打勾 + 各家差异化诉求（如金仓 GIS 需单独 License、达梦 DTS 是静态迁移）。
  6. 评估模型 + 权重表 + 三年 TCO + 评审机制：权重表按场景备两套择一；TCO 算三年不是首年；评审机制必须防打分走过场（如强制证据标注、争议项必须回到 A/B/C 级别裁定）。

不变量（必须成立的约束） ​

  • 证据分级是地基：C 级证据一旦进入横向排序，整个选型结论就不可信。
  • 定选依据必须来自自有 POC 实测，凡标 #待验证 的条目必须在 POC 或合同谈判中闭合。
  • 兼容性评估必须锚定源库，脱离源库的"兼容率"是无效指标。
  • 环境验收要有 Go / No-Go 清单，任一硬指标不达标即暂停，不"带病进入测评"。

常见误解 ​

  • 把厂商 tpmC / 基准宣传当性能依据 → 同一材料数字相差 10 倍，属 C 级，弃用。
  • 把 TDSQL MySQL 版的 TPC-C 成绩套到 TDSQL PG 版 → 产品线都不同，结论作废。
  • 以为"功能清单对比"就是选型 → 四家功能已高度同质化，清单对比无区分度，真正决定选型的是区分点 + 实测。
  • 只看首年成本 → 信创选型必须算三年 TCO（含迁移、License、运维）。

关联 ​

最近更新