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

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

曾几何时，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(HybridTransactionandAnalyticalProcess)，主要由协调节点、数据节点和全局事务管理器(GTM)组成。GuassDB300：由华为研发，也是基于开源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部署。OceanBase：简称OB，蚂蚁集团研发，按照官方说法，2020年5月，OceanBase以7.07亿tpmC的在线事务处理性能，打破了去年自己创造的TPC-C世界纪录。截止至目前，OceanBase是第一个也是唯一一个上榜的中国数据库。但该数据库在金融行业使用的不多。CockroachDB：著名的小强数据库，不支持线性一致性，只支持因果一致性，因为它们使用的是混合逻辑时钟(HybridLogicalClocks)，它们的设计思想都是来自Spanner，但和TIDB很像，都使用raft算法的改进算法multiraft，让多分片并行处理提升性能。C、Aurora数据库由Amazon推出的云原生数据库，它的特点是计算节点垂直扩展，存储节点可以水平扩展。可见计算节点依然是单节点，同步到其他从节点，可见跟其他分布式数据库相比，从节点不支持写入，所以不支持多写，从节点只能分担读的压力。Aurora基于mysql引擎构建，100%支持mysql。目前主流的有：PolarDB：阿里云原生关系型数据库，有三个独立的引擎，分别100%兼容MySQL、100%兼容PostgreSQL、高度兼容Oracle语法，存储容量最高可达100TB，单库最多可扩展到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没有undodata，完全是赤裸裸的MVCC多版本数据，这就导致了数据不能先写内存中的cache，而必须内存和磁盘同步，如果IO不行，这个性能的跌落可想而知。所以，为了节省资金，使用云上的数据库的方案绝对是不二的选择，目前在业界AWS的Aurora占据的市场份额较大。B、业务契合度如果选择第一类PGXC架构的数据库的话，初期的对业务的理解和数据库的设计是比较关键的，比如我们公司而言，使用的是腾讯的TDSQL，本质上类似于分片的MYSQL数据库。建表时，需要指定shardingkey，如果每次使用shardingkey是查询，速度是非常快的，但如果你不知晓shardingkey，在开发代码时，没有用到shardingkey，这速度就会大幅下降。此外，初期容量的估算也是很重要的，因为如果分片数据库的总容量要扩展的话，涉及到shardingkey的改变，这样就会有不同分片间的数据的迁移，这会对业务造成影响，所以初期一般会把TDSQL的数据库的容量设置的比较大，这样有一定的冗余和浪费。但如果你选择第二类，NewSQL架构的数据库就完全没有这钟烦恼，这种数据库并没有shardingkey，它通过后端的协议把数据打散的。业务可以根据自身的需要来设计SQL语句。虽然有python和spark等数据分析工具，但SQL语句还是接受程度是很大的，如果分布式数据库本身可以容量海量，又可以相对快速的执行SQL语句，那么数据库本身也能被用来做数据分析。这里要讲的就是TIDB了，这种数据库既是OLTP又可以作为OLAP，它有个tiflash的组件，这绝对是个创新，这个组件可以把在存储的行式数据在底层导入到列式存储上，使得你可以使用tiflash进行数据分析，而且不影响OLTP业务。C、开发人员的习惯很多分布式数据库都有一个共同的特征，就是功能少，这也是无奈之举，发展时间短且理念创新，原先在单库中可以使用的功能在分布式数据库中，就无法实现。比如存储过程、触发器等等。TIDB中，原厂甚至对于自增主键也推荐不使用，因为之会导致读写的热点。所以，如果企业中开发人员无法接受这种形式的话，使用就很受到制约了。在这种情况下，NewSQL可能就不能适合了，由于PXGC架构的数据库不是脱胎于PostgreSQL就是来源于MySQL，其中不得不提到红的发紫的GoldenDB，兼容常用的Oracle语法，而且提供分布式存储过程的支持。但是，话又说回来了，存储过程真的这么重要吗？D、性能上的考虑如果对数据库的性能有很大需求的，那么你必须适当放弃灵活性了，也就是选择第一类的PGXC架构的分布式数据库，虽然这种数据库有shardingkey，但只要设计好了SQL，在shardingkey下工作，性能还是相当不错的，根据腾讯云官方资料记载，TDSQL可以达到几十万TPS，这个数据着实把我吓了一跳，我猜想这一定是腾讯云对sysbench做了某些适当的调整。不管怎么说，就算有夸张的成分在里面，也可以说明PGXC架构的数据库在性能方面是非常出众的。E、数据的安全性考虑安全性通常容易被人遗忘，要做到高等级的安全性着实不易，所以有很多分布式数据库借鉴了传统数据库的安全特性，如TIDB就借鉴了MySQL的用户名和密码访问方式。但是众所周知，MySQL的某些安全等级是不能满足金融类核心数据库的安全等级要求的，所以即使在去IOE的大潮下，目前几乎还没有哪家金融类企业敢于把核心库建立在分布式数据库之上，即是对安全的考虑，也是对可靠性的考虑。三、如何迁移到分布式数据库决定使用一套分布式数据库后，如果将现有业务迁移到分布式数据库上来，是个头痛的问题，涉及到如下问题。A、兼容性分布式数据库有种限制条件，很多在常规数据库中能使用的对象或存储过程，在分布式数据库中，都不能使用。比如我们公司原来都使用MySQL

，要开发改为TIDB，首先建表语句都要改，要加入SHARD_ROW_ID_BITS这个TABLEOPTION，把rowid打散写入多个不同的Region，否则大量的insert就会将数据写入一个region中，导致写热点。再有TIDB本身居然没有altertable将字段类型改变到json格式，需要人为的导入导出；还有TIDB没有最大连接数，只要cpu和内存充足，理论上没有上限。这个看上去像MySQL的数据库，和MySQL的使用还是有很多区别的。B、迁移工具一般而言，分布式数据库厂商为了自己的产品好卖，都有针对不同数据库迁移到本数据库的迁移工具。但是，迁移是会停业务的，如果使得停业务的时间最小甚至于不停业务，是一个值得研究的课题。C、架构目前，kubernetes作为一种容器架构出现在很多体系中，是否要将分布式数据库部署在实体机、虚机，还是容器中，是个考虑点。过去觉得无状态的跑容器，有状态的跑实体机，但这种思维定式随着时间的推移正在慢慢消失。Kubernetes在不断的发展，它的statefulset组件早已经可以容纳各种有状态的服务，其中也包