--- title: '选择 TiDB 的 10 个理由' date: '2024-01-21T17:36:18+08:00' status: publish permalink: /blog/10-reasons-to-choose-tidb author: '周, 盛虎' excerpt: '文章转载自公众号“数据源的技术后花园”，作者爱喝自来水的猫归结了其选择 TiDB 的 10 个原因。' type: post id: 6183 category: - 观点洞察 tag: - HTAP - TiDB - '在线 DDL' post_format: [] profile: - 爱喝自来水的猫 --- > 文章转载自公众号“数据源的技术后花园”，作者爱喝自来水的猫 从事数据库相关工作十余年，经历过早期的传统集中式数据库如 Oracle 、 MySQL ，后来的分库分表中间件如 MyCat 、 ShardingSphere ，再到后来的分库分表数据库如 TDSQL 、 GoldenDB ，最后到如今的云原生分布式架构 TiDB 。回忆下来大概可以用一句话来总结：**无论数据量和业务量如何增长，无论数据库架构如何变化，作为开发人员来说始终希望保持单机数据库的简单使用习惯** 。而 TiDB 正好符合我们的这个期望，可以这么说，**TiDB 把分布式数据库的复杂实现留给了自己，留给用户的只有“简单”二字**。当然，选择 TiDB 不仅仅是因为使用“简单”，具体而言我归结了我们选择 TiDB 的 10 个原因。 一、真正的开源产品 --------- 全球最著名的开源单机关系型数据库非 MySQL 和 PostgreSQL 莫属，他们代表了单机关系库的两大阵营，大多数的国产数据库也是基于他们开发和迭代。而如果问你国内数据库里面哪个开源产品做的最好，我相信大多数人会说是 TiDB 。从 PingCAP 公司 2015 年创立 TiDB 开始，它的定位就是走开源路线。事实也证明了 TiDB 的这个路线是完全正确的，随着产品不断成熟，早期开发者不断贡献， TiDB 也产生了更多用户。数量众多的用户，也吸引了新的贡献者加入。以下是 2023 年 TiDB 社区总结的部分数据： - 2023 年 TiDB 中文社区注册人数达 33,926 - 积累优质技术问题 23,000+ - 累计优质回复 249,000+ - 平均每个问题回复数 10+ - 问题得到解决比例：90 % - 代码贡献者 2,154 人，覆盖国家 / 地区 45 个， Star 37,000+ 再来看一下最新 数据，对比目前国内主流的另外一款开源数据库 OceanBase ，TiDB 无论在用户数、提交数等方便均比 OceanBase 高出好几倍。 ![开源社区活跃情况](https://img1.pingcap.com/files/2024/01/20240126093941833.png)二、存算分离的架构 --------- TiDB 是一个典型的存算分离架构，计算层由多个无状态的 TiDB Server 构成，存储层由多个 TiKV 节点以及可能包含的 TiFlash 组成。存算分离架构相比于存算一体的架构，其最大的优势在于**计算资源和存储资源是可以独立进行扩缩容的**。假设你有一个 TiDB 集群在使用，一段时间后发现计算资源不够用了，那么你只需要扩容 TiDB Server 即可；如果是存储空间不够用了，只需要扩容相应的 TiKV 或 TiFlash 即可。但存算一体架构下是无法实现这一点的，如 CockroachDB 、 OceanBase 包括 Greenplum 等分析型数据库，它们的**扩容只能是一体化的扩容，这必然带来计算或存储一方资源的浪费**。 ![存算分离架构](https://img1.pingcap.com/files/2024/01/20240126094042681.png)三、对应用透明无感 --------- ![大号 MySQL](https://img1.pingcap.com/files/2024/01/20240126094133894.png)如果把 MySQL 比作一个小黄鸭的话， TiDB 就像上图中的大黄鸭（此图来自 PingCAP 创始人黄东旭关于 TiDB 的分享）。打这个比方，是为了说明 TiDB 相比于很多其它分布式数据库而言的一个优势就是对应用非常的透明。大家知道，数据库向分布式转型起初主要来自互联网厂商比如阿里腾讯，因为业务量和数据量的爆发式增长他们不得不采用一些分库分表的方案。开始阶段以中间件的方案来实现分库分表能力，后来则通过增加分布式事务与全局授时等能力后索性整合成一个分布式数据库的产品，比如 TDSQL 、 GoldenDB 。**分库分表架构的数据库一个比较大的不足是需要数据库开发人员对业务非常熟悉，以便于在创建数据模型时规划合理的分片键（ sharding key ）**。当查询条件基于分片键过滤时，便可以直接路由到对应的分片数据库实现本地化查询，从而避免跨多库的查询访问。然而， **用 TiDB 不需要考虑分片键设计的问题**，这主要有两个原因：（ 1 ） TiDB 的存储引擎是基于 Raft 协议实现并以 Region 为单位的分布式多副本存储，而不是采用多个单机数据库的分库分表方式；（ 2 ） TiDB 中的 PD 模块具有负载均衡和自动调度能力，它可以基于节点的存储容量、负载情况来自动拆分或合并 Region ，保证了节点间的负载均衡，而如果在分库分表架构里面**分片键设计不合理很有可能导致负载严重倾斜**。 ![自动调度](https://img1.pingcap.com/files/2024/01/20240126094253740.png)四、HTAP 混合负载能力 ------------- TiDB 有一篇论文叫《 TiDB:A Raft-based HTAP Database 》可能大家有读过，里面讲述了 TiDB 被设计为一款 HTAP 数据库的理念及实现思路。TiDB 最早的开发灵感来源于 Google Spanner 这样一款 NewSQL 数据库，然而直到现在为止多数 NewSQL 数据库基本上只擅长 OLTP 类型的场景，典型代表产品为 CockroachDB 和 YugabyteDB 。TiDB 在 NewSQL 基础上为了能够同时解决业务上的分析类场景而对底层 Raft 机制进行重构设计，通过引入列存储引擎实现了 AP 能力。使用 TiDB 可以很好的解决我们有混合业务负载的一些场景，比如风控。TiDB 在 HTAP 场景上的一个典型实践案例就是中通快递大数据平台，详细的使用情况可以参考 [HTAP 在快递行业助力时效分析的落地实践](https://cn.pingcap.com/blog/htap-in-the-express-delivery-industry/ "HTAP 在快递行业助力时效分析的落地实践")这篇文章。 ![HTAP混合负载](https://img1.pingcap.com/files/2024/01/20240126094444357.png)五、在线扩缩容与在线升级 ------------ 得益于 TiDB 存算分离架构的优势，使用 TiDB 的 tiup 集群管理组件来进行组件的扩缩容真的只能用一个字来形容：**香！！！**对比之前使用过的一些分布式产品，尤其是采用普通的**对节点数取模并进行哈希数据分布的实现，在进行节点扩缩容的过程中整个集群基本是不可用的状态**，还有一些产品是不支持在线升级的。TiDB 的在线扩缩容与在线升级能力是真的强大，一方面 TiDB 允许你**对集群中的任意组件进行单独或组合扩缩容**，另一方面 TiDB 自身的 BACKOFF 机制可以保证在线扩缩容和在线升级对正在运行的业务可以达到无感，这对于需要 7\*24 小时不停机的业务系统尤为重要。有了这样的能力，TiDB 就可以很容易的支撑“双 11 ”“ 618 ”这样的大促类活动，运维需要做的仅仅是在高峰期之前把新资源通过扩容添加进去，然后在高峰后把新资源再通过缩容剥离出来。 ![在线升级](https://img1.pingcap.com/files/2024/01/20240126094612326.png)六、强 MySQL 兼容 ------------ 记得有一次，业务部门的人直接丢给我一堆 MySQL 5.7 的建表语句和复杂 SQL 语句，想让我看看 TiDB 的兼容程度。说实话，一开始我认为是不太乐观的，简单扫了几眼 SQL 语句，里面涉及到一些比较特殊的 json 函数、窗口函数相关的用法。后来拿着 SQL 文本放在 TiDB 里面执行了一把，居然全部执行成功没有任何的报错。这让我眼前一亮，**原来 TiDB 对 MySQL 的兼容程度已经做到如此炉火纯青的地步**，这也让业务部门的人对 TiDB 产生了浓厚的兴趣。TiDB 已有的 SQL 语法基本都能够兼容 MySQL ，但是还没有做到 100% ，针对这一点， TiDB 在官方文档中也明确列出来，参考与 MySQL 兼容性对比 | PingCAP 文档中心 。与很多数据库号称自己能够 99% 以上兼容 MySQL ，我更喜欢 TiDB 的实事求是，把不兼容的功能直接写明，这样用户使用起来也会更加清晰明了。 七、良好的可观测性 --------- 初次接触 TiDB 的时候，觉得它还是比较复杂，主要体现在安装的组件比较多，除了基本的 PD 、 TiDB Server 、 TiKV/TiFlash 之外，默认还会安装 altermanager 、 grafana 、 prometheus 和 dashboard 。然而在后期使用过程中才发现， TiDB 的这些组件对线上运维分析起着至关重要的作用。线上运维使用最多的应该是 grafana ， granafa 里面涵盖了每个组件的不同面板，可以帮助用户在定位具体问题尤其是性能问题提供有力的帮助。使用 Dashboard 可以查看集群信息、慢 SQL 执行、资源管理，并且可以一键生成集群的诊断报告，用于详细分析集群潜在问题。补充说明一点， TiDB 现在有一个商业版本的 TEM 工具可以实现界面化的安装部署运维，替代命令行集群管理组件 tiup 。 ![TEM](https://img1.pingcap.com/files/2024/01/20240126094716697.png)八、完善的文档和学习平台 ------------ 不知道大家有没有试过把 TiDB 的中文官方文档导出成 pdf 文件，最新的 v7.5.0 版本一共有 4476 页，而一般的数据库完整指南（比如 PostgreSQL 手册）也就 2000 多页，可以说明 TiDB 仅官方文档就已经非常详尽。除了官方文档， TiDB 还有专门的学习课程、博客、用户交流平台等，可以帮助 TiDB 的新手快速上手熟悉这款数据库产品。 ![学习文档](https://img1.pingcap.com/files/2024/01/20240126094754159.png)九、敢于“不做” -------- 大家可能听到过很多国产数据库都声称对 Oracle 兼容多少多少，可以一键平滑去 O 之类的。对于国产数据库是否要兼容 Oracle 这件事，网上有两种不同的说法，一种是像飞总聊 IT 文章 [神经病！！国产数据库为什么要兼容 Oracle ？？](https://mp.weixin.qq.com/s?__biz=MzI5OTM3MjMyNA==&mid=2247497328&idx=1&sn=263ef1567f013577682ce10f980de1af&scene=21#wechat_redirect "神经病！！国产数据库为什么要兼容 Oracle ？？")里面说的 Oracle 兼容并不容易且国产数据也没有必要去兼容它，另一种是像白鳝老师文章 [兼容 Oracle 错误代码这件事，我站 OB 这一边](https://mp.weixin.qq.com/s?__biz=MzA5MzQxNjk1NQ==&mid=2647851605&idx=1&sn=107955b241fccef8ab662e940f06ca76&scene=21#wechat_redirect "兼容 Oracle 错误代码这件事，我站 OB 这一边") 中的观点认为兼容 Oracle 是必要的。从一个旁观者的角度，我只能说现在的国产数据库确实是太卷了，而 Oracle 又早已在很多的国内企业中尤其是金融客户中根深蒂固。国产数据库厂商为了能尽可能的通过多做一些 Oracle 兼容性的能力来减少客户迁移的成本，以此换取可能的一些商机，也属于情理之中。然而 TiDB 的思路是**只想做最好的自己**！谁都知道做 Oracle 兼容性能获得更多的商业机会和利润，然而 TiDB 自始至终却从未提到要去兼容 Oracle 。我个人虽然不理解这种做法的原因，但我明白一个道理就是，在研发人员规模不算大的前提下，做更多的 Oracle 兼容性意味着一定要在其他产品功能及稳定性上做出取舍。我赞同 TiDB 的做法，毕竟 Oracle 这种做了几十年的国外数据库在国家大力倡导信创的背景下也不会走太远了 ~ 十、全球市场认可度 --------- 放眼墨天轮国产数据库列表里面 300 家左右的数据库，如果让你选择出全球市场做的最好的一个，那一定非 TiDB 莫属。得益于开源， TiDB 的开源社区贡献者已经遍布了全球很多国家，中国以外的贡献者超过 40% ，主要有美国、日本、德国、印度等。另一方面，据我了解， TiDB 目前在国外也有很多的商业案例，比如 databricks 、 Airbnb 等。数据库技术起步国外领先我们几十年，能够征服国外用户并且能够很好的被商用，已经充分证明了 TiDB 的产品影响力。 ![全球贡献者分布](https://img1.pingcap.com/files/2024/01/20240126095043600.png)