你们在数据库选型的时候看了哪些数据库？最后为什么选择了 TiDB ？

🌏 互助交流区
42

(1)看了哪些？
看了mysql pg tidb
（2）为什么选tidb?
2.1、我对tidb比较熟，运维能搞定
2.2、从场景上考虑，契合场景。我这一个场景是，有多个三方数据源，需要从外网同步到内网，数据源类型主要是mysql , tidb 契合mysql 协议数据，且DM 工作支持全量+增量同步，且同步需要过滤delete,dm 也支持，tidb的扩展性，可以实现“按量付费”“按需扩容”的模式，比较适合我场景。本质上这一层其实是作为数仓的ODS 层，tidb的这个扩展性就很合适，并且后面计算ETL 计算困难的话也可以加tiflash

1 个赞
43

  1. 你们在数据库选型的时候调研了哪些数据库？
    有华为gaussdb，人大金仓，海量数据库，tidb，阿里oceanbase。

  2. 最后为什么选择了 TiDB ？原因是什么？你觉得 TiDB 对比其他你调研的数据库，优势在哪里？
    通过对几款数据库产品做调研，poc测试，最后选了tidb，因为分布式的架构再也不用分库分表了，也完美兼容mysql的系统平滑迁移过去，挺好的。

44
  • 你们在数据库选型的时候调研了哪些数据库？
    SQLServer Express，GBase 8s Express，Oracle Express，MysQL，openGuass
  • 最后为什么选择了 TiDB ？原因是什么？你觉得 TiDB 对比其他你调研的数据库，优势在哪里？
    我一直是认真回答的问题，可惜我不能决策是否使用TiDB，所以现在还没定。我就期待一个公平的抽奖机会。哈哈。
45

在数据库选型那一轮，我们其实调研了挺多主流方案：MySQL、PostgreSQL、OceanBase、ClickHouse，还有一部分 NoSQL 类的，比如 MongoDB。
但结合我们当时的业务需求（高并发写入、分布式部署、又希望兼容 MySQL 生态），最后落在了 TiDB 上。

选择过程
一开始我们倾向于 MySQL + 分库分表方案，简单、成本低，但后期运维和扩容代价太大。
PostgreSQL 功能强，但在分布式和在线水平扩展这块相对弱一点。
ClickHouse 在分析型上确实猛，但事务和混合负载不太合适我们的场景。
最后 TiDB 的“一套系统搞定 OLTP + OLAP” 特性，还有 MySQL 协议兼容，对我们来说太香了。

我们选 TiDB 的几个关键点：

  1. 水平扩展真方便：节点直接加，数据自动均衡，不用再折腾分库分表。
  2. MySQL 协议兼容：迁移成本低，业务几乎不用改代码就能切过去。
  3. 强一致性 + 分布式事务：这一点在国产数据库里真不多见，TiKV + PD 的架构稳得很。
  4. 混合负载支持好：线上事务写入、离线分析都能在一套库里跑，节省同步链路。
  5. 社区活跃、生态完善：文档、监控工具、备份方案、性能调优手册都挺成熟的（而且排查问题之前解决的很快）。

对比其他数据库的优势

如果拿 TiDB 和我们调研的几款数据库对比：

  • 对比 MySQL：不需要手动分库分表，分布式天然支持扩容。
  • 对比 PostgreSQL：分布式能力更成熟，维护成本更低。
  • 对比 ClickHouse：支持事务、强一致性，更适合混合场景。
  • 对比 OceanBase：开源生态和社区活跃度更高，上手也更轻量。
46

测了这么多呀！

47

作为金融业务的技术负责人，在数据库选型过程中，我们对 GoldenDB、OceanBase、GBase、GaussDB 和 TiDB 进行了深入的调研与评估。最终选择 TiDB 作为核心业务数据库，主要基于以下几个关键维度的综合考量：

一、核心选型原因

  1. 真正的分布式架构，原生支持水平扩展
    TiDB 是原生分布式 NewSQL 数据库，采用计算（TiDB）、存储（TiKV）、调度（PD）三层分离架构。
    相比之下：
    GoldenDB 虽为金融级分布式数据库，但依赖特定硬件和定制化部署，生态封闭；
    OceanBase 虽性能优异，但早期版本对 Oracle 兼容性较强，MySQL 模式存在功能限制，且社区版功能阉割较多；
    GBase 和 GaussDB 多为集中式或伪分布式架构，在高并发、海量数据场景下扩展性受限。
    TiDB 可以通过简单增加节点实现线性扩容，非常适合未来业务快速增长的需求。
  2. 强一致性与高可用保障
    TiDB 基于 Raft 协议 实现多副本强一致性，RPO=0、RTO<30秒，满足金融级容灾要求。
    所有节点无单点故障，自动故障转移，运维成本低。
    对比来看，部分国产数据库（如早期 GBase）在跨机房容灾和自动切换方面仍需人工干预。
  3. 高度兼容 MySQL 生态
    TiDB 高度兼容 MySQL 5.7 协议和语法，现有应用几乎无需改造即可迁移。
    开发者、DBA 工具链（如 Navicat、MyBatis、Percona Toolkit）可直接复用。
    而 OceanBase 的 MySQL 模式在复杂查询、窗口函数、JSON 支持等方面仍有差距；GaussDB 虽兼容 PostgreSQL，但团队技术栈以 MySQL 为主，迁移成本高。
  4. HTAP 能力：实时分析与交易一体化
    TiDB 4.0+ 引入 TiFlash 列式存储引擎，实现一份数据同时支持 OLTP 和 OLAP（HTAP）。
    金融场景中，风控、实时报表、反欺诈等需求无需再建数仓，降低架构复杂度和数据延迟。
    其他产品如 GoldenDB、GBase 8a 虽有分析能力，但通常需独立集群，数据同步存在延迟。
  5. 开源开放，社区活跃，避免厂商锁定
    TiDB 是 Apache 2.0 开源协议，代码透明，社区活跃（GitHub 35k+ stars），全球用户众多。
    我们可自主掌控升级、定制和问题排查，避免被单一厂商绑定。
    相比之下，GoldenDB、部分 GaussDB 版本闭源，GBase 社区支持弱，长期维护风险较高。
  6. 金融行业落地案例成熟
    在支付、清算、账务、风控等核心场景有成功实践，验证了其稳定性和合规性。
    二、为什么不选其他数据库？
    GoldenDB：虽为华为/中兴系金融数据库，但封闭性强、依赖厂商支持，扩展性不如 TiDB 灵活。
    OceanBase：性能强，但社区版功能受限，MySQL 兼容性不够“原生”，学习曲线陡峭。
    GBase：产品线分散（8a/8s/8c），分布式能力参差不齐，社区和文档支持较弱。
    GaussDB：华为主推，但生态偏向 Oracle/PostgreSQL，与我司 MySQL 技术栈不匹配。
    在金融业务对稳定性、一致性、扩展性、合规性的严苛要求下，TiDB 凭借开源、分布式、MySQL 兼容、HTAP 一体化的综合优势，成为我们最平衡且面向未来的数据库选择。
48

1、你们在数据库选型的时候看了哪些数据库？
percona、mysql、tidb

2、最后为什么选择了 TiDB ？原因是什么？
最主要的原因有两点：
2.1、解决我们日益增长的分库分表问题（商品库表超级大，单MySQL实例已经无法满足，不得不采用复杂的分实例、分库、分表）
2.2、有好的动态扩缩容，不用是存储还是计算。都可以做到按需对业务几乎无感知的扩缩容

另外个人觉得tidb的官方论坛很值得点赞，遇到问题的时候在这里寻找问题答案或者咨询问题，都能很快、很好的得到回复，得到解决方案。这也是在公司内部推荐推进tidb的一个原因

目前生产已经部署两套tidb集群，其余MySQL实例也在计划逐步迁移到新的tidb集群中。 希望tidb越来越优秀~~

49

（1）你们在数据库选型的时候调研了哪些数据库？
MySQL、PostgreSQL、Oceanbase

（2）最后为什么选择了 TiDB ？原因是什么？你觉得 TiDB 对比其他你调研的数据库，优势在哪里？
1、【核心亮点】MySQL 协议的高度兼容性
对于一个大量使用 MySQL 技术的公司而言，选择 TiDB 意味着：

  • 极低的迁移成本： 绝大多数业务代码（SQL、ORM 框架）几乎无需修改。
  • 生态复用： 现有的开发工具、运维脚本、BI 系统、数据同步工具（如 Navicat, DataGrip, CDC 工具）可以无缝衔接。
  • 学习曲线平缓： 开发者（Dev）和数据库管理员（DBA）无需学习全新的数据库范式，可快速上手。
    2、【架构亮点】真正的 HTAP（混合事务/分析处理）
    TiDB 不是一个“单体”数据库，而是一个“平台化”的架构，其核心组件（TiDB, TiKV, TiFlash）的解耦设计带来了巨大优势。
  • TiFlash（列存引擎）： 这是 TiDB 的“杀手锏”。通过 Raft 协议，TiDB 可以实时地（准实时，秒级延迟）将 TiKV（行存）的数据复制到 TiFlash（列存）。
  • 实现的效果：
    • OLTP（事务） 在 TiKV 上运行，保持高吞吐和低延迟。
    • OLAP（分析） 在 TiFlash 上运行，利用列存优势，极大加速复杂报表和即席查询。
  • 核心优势：
    • 一份数据，两种用途： 无需传统复杂的 ETL 流程（T+1）。
    • 资源隔离： 分析查询不会冲击或锁定事务查询，实现了真正的“实时分析”。
      3、弹性的水平扩展与高可用
      TiDB 真正实现了“开箱即用”的水平扩展和金融级高可用。
  • 弹性： 业务增长时，只需在线增加 TiKV（存储）或 TiDB（计算）节点，容量和性能即可线性增长，整个过程对应用完全透明。
  • 高可用： 基于 Raft 共识算法，数据自动维护多个副本（默认3副本）。任何单点（磁盘、机器、机架甚至机房）故障，数据库都能在秒级内自动完成故障转移（Failover），RPO（数据丢失）= 0，RTO（恢复时间）极短。
    这完全碾压了传统主从复制（M-S）的异步复制（有数据丢失风险）和复杂的手动/半自动切换。
    4、丰富的监控指标
    TiDB 内置了极其丰富的监控指标（Metrics）和日志，配合 Grafana + Prometheus，提供了强大的“可观测性”（Observability）。DBA 可以清晰地看到任何一条慢 SQL 的执行细节（Coprocessor耗时、Raft 等待等），定位问题非常精准。
    5、活跃的开源社区与强大的商业支持
  • PingCAP 公司和社区：TiDB 背后有 PingCAP 公司的强力支持和极其活跃的开源社区。这意味着我们可以快速获得帮助，紧跟技术发展潮流，并且有清晰的商业支持路径可供选择。
50

嗯嗯，更重要的一点，支持信创

51

1、你们在数据库选型的时候看了哪些数据库？
MySQL，TiDB，GaussDB
2、最后为什么选择了 TiDB ？原因是什么？
因为兼容mysql协议，可以不停机扩容和支持大数据分析；
有开源版本进行大量测试，同时可以在社区获得全方位资料的支持。

52

从多维度选型到落地验证：TiDB 成为核心业务数据库的决策逻辑

在数字化转型加速的背景下，数据库作为业务的核心基础设施，其选型直接决定了系统的扩展性、稳定性与长期运维成本。尤其对于金融支付、互联网服务等面临高并发、海量数据、强一致性需求的场景，选型过程更是一场对技术架构、业务适配、生态成熟度的综合考量。我们结合多行业实践经验，调研了数十款主流数据库后，最终选择 TiDB 作为核心业务数据库，其决策逻辑与核心优势如下。

一、选型调研：覆盖全场景的数据库矩阵

为确保选型的全面性，我们围绕业务核心需求（高并发、强一致、水平扩展、实时分析），调研了四大类数据库产品，覆盖传统架构、分布式架构、国产信创等多个方向：

1. 传统集中式关系型数据库

  • MySQL/PostgreSQL：开源生态成熟，适配中小规模业务，但单节点性能上限明显，水平扩展需依赖分库分表中间件，分布式事务支持薄弱。
  • Oracle：企业级功能完善，强事务与高可用能力突出，但闭源收费，扩展成本高，运维复杂度高，且存在厂商锁定风险。

2. 分布式 NewSQL 数据库

  • TiDB：PingCAP 开源的原生分布式数据库，计算、存储、调度三层分离架构，支持 HTAP 混合负载。
  • OceanBase：蚂蚁集团推出的金融级分布式数据库，性能优异，但社区版功能阉割较多，MySQL 模式存在功能限制，学习曲线陡峭。
  • CockroachDB：兼容 PostgreSQL 协议，支持水平扩展与强事务，但分析能力较弱，国内生态支持不足。
  • GoldenDB：华为 / 中兴系金融级分布式数据库，依赖特定硬件与定制化部署，生态封闭，扩展性灵活性不足。

3. 国产信创数据库

  • 人大金仓（KingbaseES）/ 达梦：适配政务等国产化场景，多基于集中式架构，分布式能力成熟度不足，生态偏向 Oracle/PostgreSQL，与 MySQL 技术栈适配性差。
  • GBase/GaussDB：部分为伪分布式架构，跨机房容灾需人工干预，社区支持薄弱，长期维护风险高。
  • 崖山数据库 /openGauss：崖山生态尚不成熟，工具链支持有限；openGauss 部署受限于单台服务器，无法横向扩展，商用版本底层逻辑改动较大。

4. NoSQL 数据库

  • MongoDB：文档型数据库，适合非结构化数据存储，但事务支持弱（仅单文档事务），SQL 兼容性差，无法满足复杂业务查询需求。
  • Cassandra/ClickHouse：Cassandra 适合高吞吐写入场景，但强一致性支持不足；ClickHouse 分析性能优异，但事务能力薄弱，不适配混合负载场景。

二、核心决策：TiDB 契合业务需求的五大关键理由

经过多轮性能测试、场景适配验证与成本评估，TiDB 凭借在 “扩展性、一致性、兼容性、混合负载、开源生态” 五大维度的综合优势，成为最终选型：

1. 原生分布式架构：线性扩展破解规模瓶颈

TiDB 采用计算（TiDB）、存储（TiKV）、调度（PD）三层分离架构，通过自动分片（Region）与 PD 智能调度，新增节点即可实现计算与存储能力的线性扩容，无需业务改造或停机维护。这完美解决了传统数据库 “分库分表” 带来的运维复杂度，以及部分国产数据库 “伪分布式” 架构在亿级数据、数万 TPS 场景下的扩展受限问题，适配业务快速增长的长期需求。

2. 金融级强一致与高可用：零数据丢失 + 低容灾成本

基于 Raft 共识协议，TiDB 实现数据多副本同步，确保分布式事务的 ACID 特性，达成 RPO=0、RTO<30 秒的金融级容灾标准。所有节点无单点故障，支持自动故障转移，无需人工干预，相比部分国产数据库（如早期 GBase）的手动容灾切换，大幅降低运维成本与故障风险。

3. 高度兼容 MySQL 生态：迁移成本趋近于零

TiDB 全面兼容 MySQL 5.7/8.0 协议与语法，现有应用代码、ORM 框架（MyBatis）、DBA 工具链（Navicat、Percona Toolkit）可直接复用，迁移过程几乎无需改造。这解决了 OceanBase MySQL 模式的功能短板、GaussDB 与 MySQL 技术栈不匹配等问题，让团队无需重构业务或学习新语法，平滑完成技术升级。

4. HTAP 混合负载：一份数据支撑事务与分析

通过 TiKV（行存引擎）与 TiFlash（列式存储引擎）的协同，TiDB 实现一份数据同时支持高并发 OLTP 事务与实时 OLAP 分析。金融风控、支付清算、实时报表等场景无需搭建 “事务库 + 数仓” 双集群，避免了数据同步的延迟与架构复杂度，相比 GoldenDB、ClickHouse 等需独立集群的方案，大幅提升数据实时性并降低硬件成本。

5. 开源开放生态：避免锁定 + 快速问题响应

TiDB 遵循 Apache 2.0 开源协议，代码透明可审计，GitHub 累计 35k+ stars，全球用户案例丰富（如美团、知乎、东亚银行）。开源社区与商业版功能保持一致，无核心功能阉割，企业可自主掌控升级与定制，避免厂商锁定风险。同时，完善的文档、监控工具（TiDB Dashboard）、备份方案（BR 工具）与快速的社区响应，解决了部分国产数据库社区薄弱、问题排查效率低的痛点。

三、优势对比：TiDB 相对于竞品的核心差异化价值

1. 对比传统 MySQL/PostgreSQL

  • 扩展性：TiDB 原生支持水平扩展，无需手动分库分表；传统数据库扩展依赖中间件，运维复杂且易出问题。
  • 混合负载：TiDB 原生 HTAP 能力，无需额外搭建数仓；传统数据库需通过 ETL 同步数据，分析延迟达分钟级。
  • 高可用：TiDB 多副本自动故障转移；传统数据库需依赖 MHA 等外部工具，配置维护复杂。

2. 对比国产分布式数据库（OceanBase/GoldenDB 等）

  • 兼容性：TiDB 对 MySQL 生态的兼容性更彻底，迁移成本更低；OceanBase MySQL 模式在复杂查询、JSON 支持等方面存在差距。
  • 开源生态：TiDB 开源免费，社区活跃，避免厂商锁定；GoldenDB 生态封闭，OceanBase 社区版功能阉割，长期维护风险高。
  • 部署灵活性：TiDB 支持物理机、云服务器、Kubernetes 等多种部署方式，不依赖特定硬件；GoldenDB 需定制化部署，适配成本高。

3. 对比 NoSQL 数据库

  • 事务能力：TiDB 支持分布式强事务，满足金融、电商等场景的数据一致性要求；MongoDB、Cassandra 等 NoSQL 事务支持薄弱。
  • SQL 兼容性：TiDB 完整支持 SQL 语法与复杂查询，无需重构应用；NoSQL 数据库多无标准 SQL 支持，适配传统业务成本高。
  • 混合负载：TiDB 兼顾高并发写入与实时分析；ClickHouse 仅擅长分析，Cassandra 仅擅长高吞吐写入，均无法覆盖混合场景。

四、实践验证：从选型到落地的价值兑现

目前，TiDB 已在支付清算、账务管理、风控决策等核心业务场景稳定运行，支撑亿级数据存储、数万 TPS 并发写入，同时满足秒级实时报表分析需求。从 v3.0 到 v7.1 的版本迭代中，其性能持续优化，运维成本仅为传统分库分表方案的 1/3，充分验证了选型决策的合理性。

总结

数据库选型的核心是 “业务需求与技术特性的精准匹配”。TiDB 之所以能在众多竞品中脱颖而出，本质在于它平衡了 “分布式扩展、强一致性、低迁移成本、混合负载、开源生态” 五大核心诉求，既解决了当前业务的性能瓶颈与运维痛点，又为未来业务增长预留了充足空间。对于面临海量数据、高并发、实时分析需求的企业而言，TiDB 无疑是兼顾稳定性、灵活性与长期成本的最优解。

1 个赞
53

1、你们在数据库选型的时候看了哪些数据库？
MySQL、 PostgreSQL、TiDB
2、最后为什么选择了 TiDB ？原因是什么？
还未最终确定，但被TiDB兼容MySQL协议、可以灵活的扩/缩容，OLTP、OLAP均可支持且互不影响等等特性吸引，同时考虑未来可能有的国产化要求。

54

1.你们在数据库选型的时候调研了哪些数据库？

  • 调研了MySQL、PostgreSQL；TiDB；

2.最后为什么选择了 TiDB ？原因是什么？你觉得 TiDB 对比其他你调研的数据库，优势在哪里？

  • 选TiDB主要是它刚好契合我们的需求——既要像MySQL一样好用，又能扛住业务增长不用折腾分库分表。
    优势就三点：一是扩容不用改代码，业务完全没感觉；二是强一致，核心交易数据不丢；三是跟MySQL几乎无缝衔接，迁移、开发都不用重新学。
55
  1. 你们在数据库选型的时候调研了哪些数据库？
    MySQL 分库分表（比如用 MyCAT 这类中间件）、 其他一些分布式数据库（如 CockroachDB, PG+Citus、 专门的分析型数据库（如 ClickHouse 或 Doris）
  2. 最后为什么选择了 TiDB ？原因是什么？你觉得 TiDB 对比其他你调研的数据库，优势在哪里？
    TiDB 特别适合那些数据量持续增长、并发压力大、既有实时交易又有即时数据分析需求（HTAP），并且希望技术栈尽量简化、运维更自动化的场景
56

在数据库选型过程中，我们围绕业务核心需求（如数据规模、事务一致性、扩展性、运维成本等），覆盖了传统关系型、分布式关系型（NewSQL）二大类主流数据库，以下是具体调研范围、选择 TiDB 的核心原因及优势对比分析：
一、调研的数据库清单及核心定位

  1. 传统关系型数据库
    MySQL：开源成熟，生态丰富，适配中小规模结构化数据场景，水平扩展依赖手动分库分表，跨节点事务支持弱，运维复杂度随数据量增长急剧上升。
    PostgreSQL：功能全面，开源免费，但分布式能力原生缺失。
    Oracle：企业级稳定性强，功能覆盖全场景，但闭源收费（授权 + 硬件成本高），扩展性依赖昂贵的 RAC 集群方案，国产化适配性差，信创不适用。

  2. 分布式关系型数据库（NewSQL）
    TiDB：开源 NewSQL 代表，兼容 MySQL 协议，原生支持分布式架构、强事务、高可用，兼顾 OLTP 与 OLAP 场景。
    CockroachDB：开源 NewSQL，具有强一致性和高可用性，支持分布式事务，但国内场景优化不足，SQL 兼容性（尤其 MySQL 生态工具适配）较弱。
    Google Spanner：谷歌闭源分布式数据库，基于全球分布式架构，强一致性与扩展性顶尖，但无法私有部署。

二、最终选择 TiDB 的核心原因，即TiDB核心优势
TiDB 的核心竞争力在于兼容 MySQL 生态的同时，解决了传统关系型数据库的扩展性瓶颈，又弥补了 NoSQL 数据库在事务和 SQL 支持上的短板。对于我们这类需要 “结构化数据 + 强事务 + 水平扩展 + 低运维成本” 的业务场景，TiDB 是综合性价比最高的选择。

TiDB核心优势：
契合业务规模扩张需求：传统 MySQL 分库分表方案面临运维瓶颈（如跨表查询复杂、扩容停机风险），TiDB 的原生分布式架构可实现无感知水平扩展。
保障核心业务事务一致性：TiDB 基于 Percolator 协议实现分布式强事务，解决跨节点数据一致性问题。
降低应用改造与学习成本：TiDB 高度兼容 MySQL 协议和语法，现有 MySQL 应用无需修改代码即可迁移，开发团队无需学习新的数据库技术栈，工具链（如 Navicat、MyDump）直接复用。
平衡成本与可用性：开源免费且支持私有部署 / 混合云模式，硬件要求灵活（普通 x86 服务器即可），相比 Oracle、Spanner 大幅降低成本；原生多副本（默认 3 副本）与自动故障转移能力，保障 99.99% 高可用。
适配国产化与混合负载场景：作为国内开源数据库标杆，TiDB 已完成国产化操作系统（麒麟、统信）和芯片（鲲鹏、飞腾）适配；通过 TiDB（行存 OLTP）+ TiFlash（列存 OLAP）架构，可同时支撑交易查询与报表分析，无需拆分架构。

57

1.回答： 当时选择了mongodb，mysql，oracle以及pg
2.回答：选择TiDB的原因是
a, TiDB ‌：提供完整的 ‌ACID 事务 ‌ 支持，确保数据的强一致性，非常适合金融、支付等对数据一致性要求严格的场景
b, TiDB ‌：‌完全兼容 MySQL 协议和语法 ‌，支持标准 SQL，包括复杂的多表 JOIN 查询，降低了开发者的学习成本，并便于从传统关系型数据库迁移
c. TiDB ‌：采用 ‌计算与存储分离 ‌ 的架构，支持 ‌自动水平扩展 ‌，能够轻松应对数据量增长和并发访问压力
d, 最重要的是在给客户做POC的时候，测试了数据库failover，TiDB在测试中没有一次出现数据库连接失败的报错，节点直接down掉，或者网络出问题对于数据库没有任何影响。

58

1. 你们在数据库选型的时候调研了哪些数据库？
PostgreSQL+citus、openGauss、TiDB、OceanBase
2. 最后为什么选择了 TiDB ？原因是什么？你觉得 TiDB 对比其他你调研的数据库，优势在哪里？
选择TiDB的原因：经过综合对比，觉得更加符合我们应对业务系统的需求场景
我们选型时考虑到国产化适配、非国产化场景下的整合情形以及分布式满足日益增长的超大业务数据，想的是通过开源数据库来兼容这两个场景。 PostgreSQL+citus是我们最开始的选择，通过适配以及模拟测试，发现改造成本太高，数据设计、应用适配方方面面都要考虑到，周期太长；openGauss是我们想适配国产服务器场景下的硬件加速，虽然效果明显，但是分布式条件下也是改造成本太高；OceanBase我们通过试用，发现开源版本和商业版本差异较大，也不符合我们预期；最后我们选择TiDB的看中如下优势：TiDB社区活跃、开源版本和商业版本差异符合我们预期、混合HTAP以及在线扩容等性能优越、应用改造运维成本低、切合我们国产化和非国产化场景需求

59

1、你们在数据库选型的时候看了哪些数据库？
分布式看过：TiDB、OceanBase
集中式看过：万里开源、达梦等

2、最后为什么选择了 TiDB ？原因是什么？
符合信创要求，Tidb兼容mysql（我们目前主要生产都是mysql）且分布式、未来业务量大了也能支撑，扩缩容简单。部门DBA前期对tidb有一定的学习基础，社区成熟、文档、培训教程比较容易上手。OB了解不多，社区、文档等不够成熟。还有就是应用对OB改造成本相对比较高一些。

60

1、你们在数据库选型的时候调研了哪些数据库？
调研了 mysql、OceanBase、doris、tidb
2、最后为什么选择了 TiDB ？原因是什么？你觉得 TiDB 对比其他你调研的数据库，优势在哪里？
Tidb 采用分层架构，其核心创新在于 TiKV（行式存储，用于 OLTP）和 TiFlash（列式存储，用于 OLAP）的协同。TiDB 服务器是无状态的，负责 SQL 解析和优化。PD 负责元数据管理和调度。这种架构更复杂，但目标是一栈式解决事务和分析问题，且基本完全兼容Mysql协议，无需大的改动。

61

1、你们在数据库选型的时候看了哪些数据库？
mysql、tidb、ob、hive、starrocks、mongodb
2、最后为什么选择了 TiDB ？原因是什么？
因为兼容mysql协议，方便迁移以及业务接入、动态横向扩容和支持大数据分析，方案成熟，易于管理。