黄东旭解析 TiDB 的核心优势
477
2024-03-06
从事数据库相关工作十余年,经历过早期的传统集中式数据库如***、MySQL,后来的分库分表中间件如MyCat、ShardingSphere,再到后来的分库分表数据库如***、***,最后到如今的云原生分布式架构TiDB。回忆下来大概可以用一句话来总结:无论数据量和业务量如何增长,无论数据库架构如何变化,作为开发人员来说始终希望保持单机数据库的简单使用习惯。而TiDB正好符合我们的这个期望,可以这么说,TiDB把分布式数据库的复杂实现留给了自己,留给用户的只有“简单”二字。当然,选择TiDB不仅仅是因为使用“简单”,具体而言我归结了我们选择TiDB的10个原因。
一. 真正的开源产品
全球最著名的开源单机关系型数据库非MySQL和***莫属,他们代表了单机关系库的两大阵营,大多数的国产数据库也是基于他们开发和迭代。而如果问你国内数据库里面哪个开源产品做的最好,我相信大多数人会说是TiDB。从PingCAP公司2015年创立TiDB开始,它的定位就是走开源路线。事实也证明了TiDB的这个路线是完全正确的,随着产品不断成熟,早期开发者不断贡献,TiDB也产生了更多用户。数量众多的用户,也吸引了新的贡献者加入。以下是2023年TiDB社区总结的部分数据:
l 2023 年TiDB 中文社区注册人数达 33,926
l 积累优质技术问题 23,000+
l 累计优质回复249,000+
l 平均每个问题回复数 10+
l 问题得到解决比例:90 %
l 代码贡献者 2,154 人,覆盖国家/地区 45 个,Star 37,000+
再来看一下最新https://ossinsight.io/ 数据,对比目前国内主流的另外一款开源数据库***,TiDB无论在用户数、提交数等方便均比***高出好几倍。
二. 存算分离的架构
TiDB是一个典型的存算分离架构,计算层由多个无状态的TiDB Server构成,存储层由多个TiKV节点以及可能包含的TiFlash组成。存算分离架构相比于存算一体的架构,其最大的优势在于计算资源和存储资源是可以独立进行扩缩容的。假设你有一个TiDB集群在使用,一段时间后发现计算资源不够用了,那么你只需要扩容TiDB Server即可;如果是存储空间不够用了,只需要扩容相应的TiKV或TiFlash即可。但存算一体架构下是无法实现这一点的,如CockroachDB、***包括Greenplum等分析型数据库,它们的扩容只能是一体化的扩容,这必然带来计算或存储一方资源的浪费。
三. 对应用透明无感
如果把MySQL比作一个小黄鸭的话,TiDB就像上图中的大黄鸭(此图来自PingCAP创始人黄东旭关于TiDB的分享)。打这个比方,是为了说明TiDB相比于很多其它分布式数据库而言的一个优势就是对应用非常的透明。大家知道,数据库向分布式转型起初主要来自互联网厂商比如阿里***,因为业务量和数据量的爆发式增长他们不得不采用一些分库分表的方案。开始阶段以中间件的方案来实现分库分表能力,后来则通过增加分布式事务与全局授时等能力后索性整合成一个分布式数据库的产品,比如***、***。分库分表架构的数据库一个比较大的不足是需要数据库开发人员对业务非常熟悉,以便于在创建数据模型时规划合理的分片键(sharding key)。当查询条件基于分片键过滤时,便可以直接路由到对应的分片数据库实现本地化查询,从而避免跨多库的查询访问。然而,用TiDB不需要考虑分片键设计的问题,这主要有两个原因:(1)TiDB的存储引擎是基于Raft协议实现并以Region为单位的分布式多副本存储,而不是采用多个单机数据库的分库分表方式;(2)TiDB中的PD模块具有负载均衡和自动调度能力,它可以基于节点的存储容量、负载情况来自动拆分或合并Region,保证了节点间的负载均衡,而如果在分库分表架构里面分片键设计不合理很有可能导致负载严重倾斜。
四. 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 在快递行业助力时效分析的落地实践 (qq.com) 这篇文章。
五. 在线扩缩容与在线升级
得益于TiDB存算分离架构的优势,使用TiDB的tiup集群管理组件来进行组件的扩缩容真的只能用一个字来形容:香!!!对比之前使用过的一些分布式产品,尤其是采用普通的对节点数取模并进行哈希数据分布的实现,在进行节点扩缩容的过程中整个集群基本是不可用的状态,还有一些产品是不支持在线升级的。TiDB的在线扩缩容与在线升级能力是真的强大,一方面TiDB允许你对集群中的任意组件进行单独或组合扩缩容,另一方面TiDB自身的BACKOFF机制可以保证在线扩缩容和在线升级对正在运行的业务可以达到无感,这对于需要7*24小时不停机的业务系统尤为重要。有了这样的能力,TiDB就可以很容易的支撑“双11” “618”这样的大促类活动,运维需要做的仅仅是在高峰期之前把新资源通过扩容添加进去,然后在高峰后把新资源再通过缩容剥离出来。
六. 强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。
八. 完善的文档和学习平台
不知道大家有没有试过把TiDB的中文官方文档导出成pdf文件,最新的v7.5.0版本一共有4476页,而一般的数据库完整指南(比如***手册)也就2000多页,可以说明TiDB仅官方文档就已经非常详尽。除了官方文档,TiDB还有专门的学习课程、博客、用户交流平台等,可以帮助TiDB的新手快速上手熟悉这款数据库产品。
九. 敢于“不做“
大家可能听到过很多国产数据库都声称对***兼容多少多少,可以一键平滑去O之类的。对于国产数据库是否要兼容***这件事,网上有两种不同的说法,一种是像飞总聊IT文章 神经病!!国产数据库为什么要兼容***?? (qq.com) 里面说的***兼容并不容易且国产数据也没有必要去兼容它,另一种是像白鳝老师文章 兼容***错误代码这件事,我站OB这一边 (qq.com)中的观点认为兼容***是必要的。从一个旁观者的角度,我只能说现在的国产数据库确实是太卷了,而***又早已在很多的国内企业中尤其是金融客户中根深蒂固。国产数据库厂商为了能尽可能的通过多做一些***兼容性的能力来减少客户迁移的成本,以此换取可能的一些商机,也属于情理之中。然而TiDB的思路是只想做最好的自己!谁都知道做***兼容性能获得更多的商业机会和利润,然而TiDB自始至终却从未提到要去兼容***。我个人虽然不理解这种做法的原因,但我明白一个道理就是,在研发人员规模不算大的前提下,做更多的***兼容性意味着一定要在其他产品功能及稳定性上做出取舍。我赞同TiDB的做法,毕竟***这种做了几十年的国外数据库在国家大力倡导信创的背景下也不会走太远了~
十. 全球市场认可度
放眼墨天轮国产数据库列表里面300家左右的数据库,如果让你选择出全球市场做的最好的一个,那一定非TiDB莫属。得益于开源,TiDB的开源社区贡献者已经遍布了全球很多国家,中国以外的贡献者超过40%,主要有美国、日本、德国、印度等。另一方面,据我了解,TiDB目前在国外也有很多的商业案例,比如databricks、Airbnb等。数据库技术起步国外领先我们几十年,能够征服国外用户并且能够很好的被商用,已经充分证明了TiDB的产品影响力。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。