选择 TiDB 的 10 个理由

数据运维 2024-01-22 爱可生开源社区手机阅读

文章转载自数据源的技术后花园，作者爱喝自来水的猫

从事数据库相关工作十余年，经历过早期的传统集中式数据库如 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+ 再来看一下最新 https://ossinsight.io/ ( https://ossinsight.io/ ) 数据，对比目前国内主流的另外一款开源数据库 OceanBase ，TiDB 无论在用户数、提交数等方便均比 OceanBase 高出好几倍。TiDB 是一个典型的存算分离架构，计算层由多个无状态的 TiDB Server 构成，存储层由多个 TiKV 节点以及可能包含的 TiFlash 组成。存算分离架构相比于存算一体的架构，其最大的优势在于计算资源和存储资源是可以独立进行扩缩容的。假设你有一个 TiDB 集群在使用，一段时间后发现计算资源不够用了，那么你只需要扩容 TiDB Server 即可；如果是存储空间不够用了，只需要扩容相应的 TiKV 或 TiFlash 即可。但存算一体架构下是无法实现这一点的，如 CockroachDB 、 OceanBase 包括 Greenplum 等分析型数据库，它们的扩容只能是一体化的扩容，这必然带来计算或存储一方资源的浪费。

如果把 MySQL 比作一个小黄鸭的话， TiDB 就像上图中的大黄鸭（此图来自 PingCAP 创始人黄东旭关于 TiDB 的分享）。打这个比方，是为了说明 TiDB 相比于很多其它分布式数据库而言的一个优势就是对应用非常的透明。大家知道，数据库向分布式转型起初主要来自互联网厂商比如阿里腾讯，因为业务量和数据量的爆发式增长他们不得不采用一些分库分表的方案。开始阶段以中间件的方案来实现分库分表能力，后来则通过增加分布式事务与全局授时等能力后索性整合成一个分布式数据库的产品，比如 TDSQL 、 GoldenDB 。分库分表架构的数据库一个比较大的不足是需要数据库开发人员对业务非常熟悉，以便于在创建数据模型时规划合理的分片键（ sharding key ）。当查询条件基于分片键过滤时，便可以直接路由到对应的分片数据库实现本地化查询，从而避免跨多库的查询访问。然而，用 TiDB 不需要考虑分片键设计的问题，这主要有两个原因：（ 1 ） TiDB 的存储引擎是基于 Raft 协议实现并以 Region 为单位的分布式多副本存储，而不是采用多个单机数据库的分库分表方式；（ 2 ） TiDB 中的 PD 模块具有负载均衡和自动调度能力，它可以基于节点的存储容量、负载情况来自动拆分或合并 Region ，保证了节点间的负载均衡，而如果在分库分表架构里面分片键设计不合理很有可能导致负载严重倾斜。

大家可能听到过很多国产数据库都声称对 Oracle 兼容多少多少，可以一键平滑去 O 之类的。对于国产数据库是否要兼容 Oracle 这件事，网上有两种不同的说法，一种是像飞总聊 IT 文章神经病！！国产数据库为什么要兼容 Oracle ？？(qq.com) 里面说的 Oracle 兼容并不容易且国产数据也没有必要去兼容它，另一种是像白鳝老师文章兼容 Oracle 错误代码这件事，我站 OB 这一边 (qq.com) 中的观点认为兼容 Oracle 是必要的。从一个旁观者的角度，我只能说现在的国产数据库确实是太卷了，而 Oracle 又早已在很多的国内企业中尤其是金融客户中根深蒂固。国产数据库厂商为了能尽可能的通过多做一些 Oracle 兼容性的能力来减少客户迁移的成本，以此换取可能的一些商机，也属于情理之中。然而 TiDB 的思路是只想做最好的自己！谁都知道做 Oracle 兼容性能获得更多的商业机会和利润，然而 TiDB 自始至终却从未提到要去兼容 Oracle 。我个人虽然不理解这种做法的原因，但我明白一个道理就是，在研发人员规模不算大的前提下，做更多的 Oracle 兼容性意味着一定要在其他产品功能及稳定性上做出取舍。我赞同 TiDB 的做法，毕竟 Oracle 这种做了几十年的国外数据库在国家大力倡导信创的背景下也不会走太远了 ~放眼墨天轮国产数据库列表里面 300 家左右的数据库，如果让你选择出全球市场做的最好的一个，那一定非 TiDB 莫属。得益于开源， TiDB 的开源社区贡献者已经遍布了全球很多国家，中国以外的贡献者超过 40% ，主要有美国、日本、德国、印度等。另一方面，据我了解， TiDB 目前在国外也有很多的商业案例，比如 databricks 、 Airbnb 等。数据库技术起步国外领先我们几十年，能够征服国外用户并且能够很好的被商用，已经充分证明了 TiDB 的产品影响力。