zhuqibs
作者zhuqibs2021-04-26 12:02
软件开发工程师, Adidas

中小企业分布式数据库之路

字数 5799阅读 1541评论 0赞 2

曾几何时, IT 界有两款软件被奉为神一样的软件,一款是 SAS ,这是一个被奉为神器的数据分析软件,并有“有了 sas ,世界上没有了失业”的美誉。还有一款就是 Oracle 数据库了,由于当年 Oracle7 击败了 Sybase 数据库,一跃成为王者,市场份额达到 46% 以上,无论是中小企业还是大公司总要用到 Oracle 的数据库,风头无两,据说当年阿里巴巴 Oracle 数据库部就有 100 多号人,而负责的 RAC 数据库的节点多达 17 个,极其庞大。

然后时过境迁,当年的庞然大物,虽然现在仍然是这么的大,但境遇却发生了重大的变化。首当其冲的就是 Oracle 面对分布式数据库的挑战, Oracle 公司一贯的思路,就是不搞分布式数据库,因为它们觉得单库很“香”,为什么呢?原因是 Oracle 公司对单库的功力深厚,依赖于强大的关系型数据库的设计和规划技术, Oracle 单库可以适应于各个领域,而且如果对性能有较大需求的,可以让客户买 EXADATA 一体机,完全可以满足互联网的海量数据分析 OLAP 应用,而前端的互联网应用不是 Oracle 的范畴,可以用 MySQL 去对付。 Oracle 依赖单库 Oracle 数量巨大的许可证售卖,维持着每年庞大的利润,而在是否搞分布式数据库问题上非常不上心。但技术的发展是挡不住的, Oracle 在分布式数据库上的犹豫,给了很多其他公司机会。

一、三类分布式数据库

单体数据库时代,随着系统交易量的不断上升,数据库读写性能出现了严重下降。我们可以借助分库分表中间件,比如 mycat 、 shardingjdbc 来实现分库分表,缓解单库的读写性能。但是这种分库分表的中间件充其量都只是 XA 弱事务,虽然接近于普通事物,但仍然有很多缺点,最主要的是会存在数据不一致的情况。如果要保证数据一致性,就需要借助于分布式事务中间件,比如阿里巴巴的 seata 。后来分布式数据库逐渐成为解决数据一致性的选择,目前分布式数据库产品已经比较成熟,支持 ACID 事务。

A 、 PGXC 数据库 --- 支持全局时钟的分布式数据库

这种数据库架构被业内称为 PGXC 架构,这个名字是 PostgreSQL-XC 的简称,它是一种提供写可靠性,多主节点数据同步,数据传输的开源集群方案。基于分库分表演化而来,优点是性能比较稳定,缺点是写入能力有限,这是由架构风格决定的。目前主流的有:

· TBase :腾讯数据平台团队在基于 PostgreSQL 研发的,支持 HTAP(Hybrid Transaction and Analytical Process) ,主要由协调节点、数据节点和全局事务管理器 (GTM) 组成。

· GuassDB 300 :由华为研发,也是基于开源 PostgreSQL 研发的,支持 HTAP ,支持 SQL92 、 SQL99 和 SQL2003 语法,并且支持提供存储过程、触发器、分页等,但目前华为在上面已经久久不见发力。

· AntDB :由亚信科技开发,基于开源 PostgreSQL 内核研发的,主要特点是对 Oracle 兼容性高,分布式事务支持 2PC 协议和 MVCC ,集群支持动态扩展。

· GoldenDB :由中兴通讯研发,这款数据库以 mysql 为内核构建的,按照官方的描述,这款数据库对金融行业的支持比较好,目前这个数据库的发展势头很强劲。

· TDSQL :由腾讯研发,它算不上是完全的 PGXC 架构,因为没有全局时钟。不过它也有自己解决一致性的方案,它的自增长序列为用户提供一个全局唯一数字 ID 服务,对全局锁和 mvcc 都有一定的作用。

B、NEWSQL数据库 --- 新型架构的 分布式数据库

** 由 NoSQL 键值数据库发展而来,它是一类新的数据库架构方案,不仅具有 NoSQL 对海量数据的存储管理能力,还保持了传统数据库支持 ACID 和 SQL 等特性。有以下特点:

• 放弃了 PGXC 架构中单体数据库的事务支持

• 在 BigTable 基础上构建了事务支持

• 引入分片机制,主要采用 Range 动态分片技术,跟 HASH 分片相比,数据可以不用固定的在某一个分片上

• 可靠性方面,放弃传统数据库的主从复制,采用 Paxos 、 Raft 等共识算法来保证 HA

• 存储引擎方面,使用 LSM-Tree 替换 B+ 树模型,写入性能更高

• 支持事务管理

这种数据库架构上有很大优势,但设计难度也很大,目前主流的有:

· 谷歌 Spanner :可以说是 NewSQL 数据库的鼻祖,后来的好多数据库都是借鉴了 Spanner 的思想,使用 GPS 加原子钟的方式来实现全局时钟,同时实现了线性一致性。

· TiDB :非常有名的一块 NewSQL 数据库,由 PingCAP 研发,支持 HTAP ,支持线性一致性,一个亮点是兼容 mysql 协议和生态,可以支持 K8S 部署。

· Ocean Base :简称 OB ,蚂蚁集团研发,按照官方说法, 2020 年 5 月, OceanBase 以 7.07 亿 tpmC 的在线事务处理性能,打破了去年自己创造的 TPC-C 世界纪录。截止至目前, OceanBase 是第一个也是唯一一个上榜的中国数据库。但该数据库在金融行业使用的不多。

· CockroachDB :著名的小强数据库,不支持线性一致性,只支持因果一致性,因为它们使用的是混合逻辑时钟 (Hybrid Logical Clocks) ,它们的设计思想都是来自 Spanner ,但和 TIDB 很像,都使用 raft 算法的改进算法 multi raft ,让多分片并行处理提升性能。

C 、 Aurora 数据库

由 amazon 推出的云原生数据库,它的特点是计算节点垂直扩展,存储节点可以水平扩展。可见计算节点依然是单节点,同步到其他从节点,可见跟其他分布式数据库相比,从节点不支持写入,所以不支持多写,从节点只能分担读的压力。 Aurora 基于 mysql 引擎构建, 100% 支持 mysql 。目前主流的有:

· PolarDB :阿里云原生关系型数据库,有三个独立的引擎,分别 100% 兼容 MySQL 、 100% 兼容 PostgreSQL 、高度兼容 Oracle 语法,存储容量最高可达 100 TB ,单库最多可扩展到 16 个节点。

· CynosDB :现在叫 TDSQL-C 数据库,是 腾讯云 自主研发的新一代关系型云原生数据库,既拥有 分布式 设计的 低成本 优势,又具有集中式的 易用性 ,采用存储计算分离设计。

· Taurus :华为云原生数据库, 100% 兼容 Mysql ,使用 Log-as-database 以最小化网络 IO ,不仅针对 IO 与写操作进行了优化,而且还考虑了读优化,让应用程序可以在缓冲区内以最小的代价获得最新的数据。

二、中小型企业如何选择分布式数据库

纵观这三类分布式数据,给我们茫然的感觉,实在选择太多了,如何选择呢?我这里提出几点考量

A 、成本考虑

钱永远是最主要的考量点,如果资金充足的话,可以暂不考虑第三类云原生的数据库,毕竟数据是新时代的石油,把数据放在云上,对于某些企业来说是不能容忍的。所以,第一和第二类中可以做个选择。但反之,如果资金紧张,云下的分布式数据库,你可要掂量一下资金问题了,就拿 TIDB 而言,生产环境刚上 TIDB 是不敢用开源的,谁的胆子也没有这么肥啊!要买 PingCAP 的订阅,起板每年 100 万,再加上每套集群 10 台带 ssd 磁盘的物理机的投资,一年少说要 300 万左右,这还是基本配置。有朋友说为啥要 ssd 盘呢,我用 sas 盘性能要求低点不行吗? 那还真不行,原来 TIDB 的设计是为 ssd 专门设计的,很多地方都是反常规的,如果不用 ssd ,性能会跌入谷底,比如 : TIDB 没有 undo data ,完全是赤裸裸的 MVCC 多版本数据,这就导致了数据不能先写内存中的 cache ,而必须内存和磁盘同步,如果 IO 不行,这个性能的跌落可想而知。

所以,为了节省资金,使用云上的数据库的方案绝对是不二的选择,目前在业界 AWS 的 Aurora 占据的市场份额较大。

B 、业务契合度

如果选择第一类 PGXC 架构的数据库的话,初期的对业务的理解和数据库的设计是比较关键的,比如我们公司而言,使用的是腾讯的 TQSQL ,本质上类似于分片的 MYSQL 数据库。建表时,需要指定 sharding key ,如果每次使用 sharding key 是查询,速度是非常快的,但如果你不知晓 sharding key ,在开发代码时,没有用到 sharding key ,这速度就会大幅下降。此外,初期容量的估算也是很重要的,因为如果分片数据库的总容量要扩展的话,涉及到 sharding key 的改变,这样就会有不同分片间的数据的迁移,这会对业务造成影响,所以初期一般会把 TDSQL 的数据库的容量设置的比较大,这样有一定的冗余和浪费。

但如果你选择第二类, NewSQL 架构的数据库就完全没有这钟烦恼,这种数据库并没有 sharding key ,它通过后端的协议把数据打散的。业务可以根据自身的需要来设计 SQL 语句。虽然有 python 和 spark 等数据分析工具,但 SQL 语句还是接受程度是很大的,如果分布式数据库本身可以容量海量,又可以相对快速的执行 SQL 语句,那么数据库本身也能被用来做数据分析。 这里要讲的就是 TIDB 了,这种数据库即是 OLTP 又可以作为 OLAP ,它有个 tiflash 的组件,这绝对是个创新,这个组件可以把在存储的行式数据在底层导入到列式存储上,使得你可以使用 tiflash 进行数据分析,而且不影响 OLTP 业务。

C 、开发人员的习惯

很多分布式数据库都有一个共同的特征,就是功能少,这也是无奈之举,发展时间短且理念创新,原先在单库中可以使用的功能在分布式数据库中,就无法实现。比如存储过程、触发器等等。 TIDB 中,原厂甚至对于自增主键也推荐不使用,因为之会导致读写的热点。所以,如果企业中开发人员无法接受这种形式的话,使用就很受到制约了。在这种情况下, NewSQL 可能就不能适合了,由于 PXGC 架构的数据库不是脱胎于 PostgreSQL 就是来源于 MySQL ,其中不得不提到红的发紫的 GoldenDB ,兼容常用的 Oracle 语法,而且提供分布式存储过程的支持。但是,话又说回来了,存储过程真的这么重要吗?

D 、性能上的考虑

如果对数据库的性能有很大需求的,那么你必须适当放弃灵活性了,也就是选择第一类的 PGXC 架构的分布式数据库,虽然这种数据库有 sharding key ,但只要设计好了 SQL ,在 sharding key 下工作,性能还是相当不错的,根据腾讯云官方资料记载, TDSQL 可以达到几十万 TPS ,这个数据着实把我吓了一跳,我猜想这一定是腾讯云对 sysbench 做了某些适当的调整。不管怎么说,就算有夸张的成分在里面,也可以说明 PGXC 架构的数据库在性能方面是非常出众的。

E、 数据的安全性考虑

安全性通常容易被人遗忘,要做到高等级的安全性着实不易,所以有很多分布式数据库借鉴了传统数据库的安全特性,如果 TIDB 就借鉴了 mysql 的用户名和密码访问方式。但是众所周知, MySQL 的某些安全等级是不能满足金融类核心数据库的安全等级要求的,所以即使在去 IOE 的大潮下,目前几乎还没有哪家金融类企业敢于把核心库建立在分布式数据库之上,即是对安全的考虑,也是对可靠性的考虑。

三、如何迁移到分布式数据库

决定使用一套分布式数据库后,如果将现有业务迁移到分布式数据库上来,是个头痛的问题,涉及到如下问题。

A 、兼容性

分布式数据库有种限制条件,很多在常规数据库中能使用的对象或存储过程,在分布式数据库中,都不能使用。比如我们公司原来都使用 mysql ,要开发改为 TIDB ,首先建表语句都要改,要加入 SHARD_ROW_ID_BITS 这个 TABLE OPTION ,把 rowid 打散写入多个不同的 Region ,否则大量的 insert 就会将数据写入一个 region 中,导致写热点。再有 TIDB 本身居然没有 alter table 将字段类型改变到 json 格式,需要人为的导入导出;还有 TIDB 没有最大连接数,只要 cpu 和内存充足,理论上没有上限。这个看上去像 MySQL 的数据库,和 MySQL 的使用还是有很多区别的。

B 、迁移工具

一般而言,分布式数据库厂商为了自己的产品好卖,都有针对不同数据库迁移到本数据库的迁移工具。但是,迁移是会停业务的,如果使得停业务的时间最小甚至于不停业务,是一个值得研究的课题。

C 、架构

目前, kubernetes 作为一种容器架构出现在很多体系中,是否要将分布式数据库部署在实体机、虚机,还是容器中,是个考虑点。过去觉得无状态的跑容器,有状态的跑实体机,但这种思维定式随着时间的推移正在慢慢消失。 Kubernetes 在不断的发展,它的 statefulset 组件早已经可以容纳各种有状态的服务,其中也包含了数据库。爱可生也推出了基于容器部署的 MySQL 集群, TIDB 也有自己的 Operator 来支持 K8S 部署。 而且,这里还有个伏笔请读者考虑,如同 TIDB 这种占用大量资源的数据库服务,为什么不可以是 serverless 的服务,为啥在没有访问时,也要占用庞大的闲置资源?

四、结束语

无论我们愿不愿意,分布式数据库已经出现在了我们周围,而且越来越多的企业正在准备和已经使用了分布式数据库,互联网时代,分布式数据库的能力将来会成为企业的核心竞争力。我们必须与时俱进,让自己的所在的公司使用上分布式数据库,发挥出分布式数据库的优势。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

2

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广