如何支撑HTAP场景——HybridDB for MySQL系统架构和技术演进

随着DT时代的到来，企业占有的数据越来越多，其规模可能达到上百TB甚至PB级，如何以合理的成本管理并维护这样一个数据库也成为各个企业IT管理中的核心问题。HybirdDB for MySQL是基于HTAP资源的数据库，同时支持OLTP，在一份数据上做事务，又支持实时分析。10月12日的云栖大会·HTAP技术专场中，阿里云高级专家王骞探讨如何如何支撑HTAP场景，并重点分享了如何利用RDS技术实现HTAP业务，以及HybridDB for MySQL的系统架构和技术演进。

技术现状

首先看看技术现状，HybirdDB for MySQL是一个HTAP数据，希望同时解决在线事务和在线分析的问题。现在主流的数据库，比如MySQL，它非常擅长于做一些高并发的事务云，比如电商交易，或者尽量少的多表关联，或者预见索引的业务。反之，有一些数据库非常适合于做一些对静态数据的强分析。如果用户需要同时使用这两种业务，在现有技术方案解决下，需要事务处理库做事务类业务，需要分析类数据库做分析业务，这样无形当中会增加用户的成本，管理起来也非常的复杂。

2013年时团队看准了这个目标，希望帮助用户把这个问题解决掉，支撑更大的数据规模。在这个理念的支撑下就开始了HTAP数据库的研究。在数据规模变得非常大的情况下，成本也是非常值得考量的问题，在设计过程中项目兼顾了数据压缩，在线上观察到实际的业务，数据库能够做到3-15天压缩比。目前世界上最流行的几个数据库，比如MySQL、Oracle等等，它流行的并不是功能特性，而是通用的接口模式。但是，HybirdDB for MySQL并没有牺牲这方面的能力，它能够提供和MySQL一样的访问接口，帮助用户对业务做无缝的迁移。

产品现在支持SQL标准、TPC-H、TPC-DS几个分析型的测试。作为RDS级云服务中一员，它同样支持RDS的云服务，比如高可靠、高可用、白名单、性能数据。在线扩容、备份恢复，这需要比较大的技术挑战。对于阿里云生态下的数据库，同时还支持DTS、DMS、CDP、QuickBI等生态产品，可以帮助解决包括数据交换、数据操纵等多方面的问题。现在HybirdDB for MySQL的规模已经支持了国内外数十个Region，包括美洲、德国等，还有国内的北京、上海、杭州等等。目前，线上数据已经达到了PB级，每天新增几百TB级数据，供给多个阿里云比较著名的业务去做实时分析和实时的处理。

产品定位

既然是一个混合型的数据库产品，HybirdDB for MySQL就需要在OLTP和OLDP两方面做性能和功能的扩展。在性能方面，HybirdDB for MySQL利用了分区自治，每个分区可以独立提供局部数据的业务，又能整体做数据的聚合、事务的聚合，提供跨区分布式的事务和分布式数据结算能力。和国内外知名数据库对比，可以看到每个数据库的定位。高并发的在线事务有一定局限，会在OLAP方面有所限制。HybirdDB for MySQL综合考虑了这几方面的因素，在架构上有很大的改进，同时解决了这几方面的问题。

技术演进

HybirdDB for MySQL整个产品的立项是在2013年，这时候遇到的主要问题是单机数据库的性能容量都不满足日益增长的业务需求，这时候就从中间件的思路去出发。在这个基础之上，从2014年到现在产品每年都提出了一些新的改进：比如说在2014年把中间件思路摒弃掉，改成了完整的数据库思路，解决了用户兼容性的问题；到2015年考虑到大数据降低成本，降低门槛，让更多用户参与到大数据的领域来；到2016年做了计算存储分离，这一年也做了产品公测，产品已经比较完善了，解决了单机MySQL解决不了的SQL；到了2017年，产品在OLAP方面做了更进一步的改进，引入了列存索引。在明年会做更进一步的技术革新，包括融合POLARDB作为存储引擎，更进一步提高事务能力。

在这个过程中，产品不断满足用户业务的需求，成长到现在的形态。如果对MySQL数据库了解比较多的话，会感知到它只能部署在一台机器上，因为它的存储引擎只能利用单机资源。再说说存储引擎方面，比如ADB有很多锁，这些锁会进一步限制它的并发吞吐能力，导致整机吞吐和数据处理能力下降。我们线上观察得知，MySQL性能最合适的情况下是30-50个并发连接，ALDP并发连接可以高达几千、上万。传统数据库问题会限制它在大数据领域的能力发挥，因此借鉴了分库分表中间件，就是把这些数据切开，每个数据利用业务的特性，管理和处理这些数据。中间件也会有些比较明显的局限，因为它要嵌入到用户业务代码里，它的通用性用得很好，每个用户访问中心件时就需要自己定这套业务代码。

同时由于中间件是套在数据库上的一层，用户也有可能直接操纵顶层的数据库，这时候就会考虑到并发的问题。一些典型的问题，比如中间件要去做DBL时就需要锁住，避免用户再从旁访问。锁表过程中，数据库性能会下降。考虑到这些局限性能的问题，产品在2014年做了更大幅度的改进，过程中也遇到了非常多的问题，尤其是事故处理。2014年对SQL本身要求并不是很高，只能支持一些比较简单的聚合SQL。一些更复杂的，比如说需要数据重新交易的，在这个阶段还没有去支持，它的实现复杂度会更加高。

 

到了2015年时面临了超大规模的数据业务，包括用户希望存储上PB级的数据。在这个场景下单机数据库最多也只能提供3个T左右的流量，即使压缩单机也只能放十几个T，如果想保证不损坏重建，带来的挑战很大。当然它的收益也很明显，原来是在物理机存储数据，再压缩改进一下，只需要几台或者十几台单机。这个过程中面对的最大问题就是如何实现一套低成本的存储引擎体系，综合考虑软件和硬件的问题后产品最终选择了MySQL引擎。

此外产品在现有硬件体系结构上还应用了混合的存储，利用一块flash卡当做硬件的缓存，综合实行了一套软硬一体的混合存储。因为大的副本一旦损坏，迁移和损坏就相当于几T数据的搬迁。

当前限制

目前HybirdDB for MySQL还有一些存储限制，比如不支持高级特性、触发器、存储过程、游标、外键。有限的分区规则下，只支持哈希分区、只支持一个字段作为分区键以及二级分区有限支持。HybirdDB for MySQL也有不太适合的业务场景，比如数据量较小时热点无法完全消除，即使消除的话也需要一些代价，需要换一些字段做分区键。暂不适合的业务场景包括有：业务结构简单且数据量小，存在热点，可以采取CloudDBA诊断优化+ RDS升级；基于Oracle的复杂系统，包含大量存储过程，可以采取ADAM + PPAS去“O”；还有业务水平拆分后存在大量分布式事务，如转帐，并发上来之后可以解决吞吐量的问题，建议选择POLARDB的ScaleUp扩展。

未来展望

下一个阶段，产品需要解决的问题就是继续增强易用性，如支持存储过程、丰富索引格式、丰富二级分区特性、支持多种字符集、支持外部表、支持外部数据快速加载等，用户可以把更多计算逻辑下沉到数据库上，让它的开发变得更轻量级。另外需要增强安全性，在政企和金融业务中，安全特性是他们非常看中的。比如说SSL安全加密、TDE文件加密、自主访问控制等等，下一阶段也要解决这方面问题。下一步还将继续改进体验，坚持一贯的理念，提供一站式的服务，减少用户选型，降低用户成本。架构方面也要做更多的改进，如软硬结合、智能调度、OLAP持续优化等等。

架构方面将持续优化，发挥新一代硬件优势，包括引入资源的存储引擎，在共享存储上做一个全新的引擎出来，进一步改善存储性能，增强存储能力。使用共享存储之后就不用考虑备份、迁移方面的问题，因为底层共享存储会cover掉这个问题，到明年也可以支持更全面的HTAP业务场景内容。