基础软件十年铸一剑，企业级分布式数据库HotDB
出任九月《程序员》杂志的专题顾问，在杂志发行后和大家切磋一下本人在杂志中的文章，欢迎大家交流我司私有云数据库产品HotDB。
HotDB是一款专注MySQL数据库服务的高可靠高吞吐量的分布式数据库产品，能在分布式数据环境下为应用提供集中式数据库的操作体验，为海量数据、海量用户、高可用、高性能和高并发的业务系统提供强有力的支撑，同时具备强分布式透明、易扩展、无学习成本等特点。让技术工程师专注应用程序编码实现，不必知道也不必关心数据的存放和操作位置等细节；让数据库运维人员更轻松地管理海量数据和大规模的数据库集群。私有云数据库产品HotDB的定位概括如图1。
图1 私有云数据库HotDB定位
l 传统行业信息化的数据系统现状
当下，国内传统行业的企业信息化几乎都被甲骨文Oracle数据库、IBM小型机和存储设备、EMC存储设备垄断，几乎很难摆脱对这三家公司的依赖，成本、风险居高不下。IBM小型机和存储设备、Oracle数据库、EMC存储设备构成了业界经典的IOE集中式数据库架构，遗憾的是这种技术架构是基于欧美人口基数和增长率而设计的，不适应中国将近14亿人口的超级大国国情。
IOE技术架构是非常优秀的，最大优势是降低研发工程师的编码水平要求，降低架构师的架构设计水平要求，让技术人员只需关注信息系统的业务编码实现。IOE技术架构在中国大江南北互联网化，尤其移动互联网普及后，遇到IOE技术架构无法支持高并发和海量用户的业务场景的天花板，垂直扩展也达到其吞吐量的瓶颈。同时，不断地垂直升级硬件设备，不仅信息化成本急剧增加，还存在硬件设备投入与数据系统吞吐量增长远低于线性比例。企业实施IOE技术架构后，对设备和商业数据库软件的维护升级，尤其是硬件设备过保后必须购买厂商或厂商认可第三方的维保服务且设备维保费用昂贵；商业数据库软件Oracle按CPU核数量及产品类型购买许可费，同样也需要每年支付昂贵的维保费用，概括总结如图2所示。
图2 IOE架构缺陷
随着互联网的发展普及，移动互联网以接近光的速度迅速普及祖国的各个角落里。同时，过去十多年国内互联网聚焦于商业模式创新，带动消费者信任与依赖线上的聊天、交友、购物、办公等涉及工作和生活的方方面面，迫使整个社会体系正走向变革和商业模式重构。在线支付、互联网金融和在线销售保险等业务发展，迫使银行保险业不得不改变自己的服务模式。电子商务的发展，基本上达到重构生产-代理-销售的渠道模式，由C2C模式发展到B2C模式，及正在进行的C2B模式，越来越深入地改变企业生产管理经营的模式。
银行、保险、生产制造等行业的企业，将逐渐取消中间环节而直接面对消费者，采用纯线上、互联网+物流和互联网+上门的综合模式为消费者提供无微不至的服务，此时信息化就成为企业的核心部门。这就需要传统行业企业的信息化技术进行革新，建设面对服务海量用户和处理海量数据的能力，确保信息化系统稳定可靠。
传统行业的企业经营模式转型是势在必行的，转型过程和转型后的信息化的数据系统可能面临的挑战，总结如图3所示。
图3 企业信息化面临挑战
l 分布式数据库的价值
传统企业因要适应社会变革和生产经营转型升级，为此企业信息化的数据系统需要面临海量数据、海量用户、高可靠、高性能、高并发和可水平扩展（简称：二大三高一扩）的挑战。分布式数据库HotDB正是为此应运而生的技术产品，组合单体的计算处理能力，即数据系统的数据服务采用开源数据库MySQL、数据存储采用多块本地盘的X86物理服务器和分布式数据库中间件HotDB Server共同组成，分布式数据库管理平台HotDB Cloud完成相关的配置管理、监控、报表、服务管理等功能，图4是分布式数据库替换IOE集中式数据库的架构图。
图4 分布式数据库替换集中式数据库的架构图
l 分布式数据库的发展历史
图5是在过去的十年时间里，MySQL数据库社区一直在探索分布式数据库的技术产品路线，从最早的读写分离产品MySQL-Proxy，再到阿里巴巴开源的伪分布式数据库产品Amoeba和Cobar，尤其Cobar的技术架构思路成为指引行业的灯塔，惠及国内众多互联网企业。
我和热璞合伙人在开心农场合作的时期，继承Cobar的技术架构思路碰到业务场景不满足和产品功能不够完善的问题，为此我们结合社交游戏行业的写比例高达88%及以上的特点和大量玩家1-10秒内反复操作同一条记录，设计出伪分布式数据库产品Gaia（注释：希腊神话中大地女神，又称地母），类似于当下阿里巴巴的Oceanbase技术架构与算法特征。
后同惠普合作中国联通MSS域业务系统大集中和去IOE化，属于国内传统行业成功实施开源分布式技术架构的超大型项目。在实施过程中，碰到远超互联网行业业务复杂数倍和研发团队技术转型的问题，为此在伪分布式数据库Cobar基础上改进和封装了大量的功能，降低技术门槛和解决复杂业务场景的问题，例如E-R分片解决父子表的数据关联业务场景。
从最早的MySQL-Proxy到DaaS都存在一个通病，我们设计这类产品的时候只为解决某一个或一类问题，也即数据读负载均衡到如何解决数据分片，通过数据架构设计技巧和应用编程技巧规避数据分片后的问题，同时也存在维护的技术门槛等问题。为此热璞团队不断地反思过往的产品设计经验和去IOE实施过程的经验，从而分布式数据库产品HotDB的研发设计追求服务稳定可靠、分布式透明、数据安全和易维护易应用。
图5 基于MySQL数据库服务的分布式数据库发展史
l 分布式数据库的分片算法
经历多款分布式数据库产品设计与研发，及实施数十个私有云数据库项目后，总结发现分布式数据库产品需提供五种数据分片算法：路由表、约定范围、哈希约定、自动哈希和E-R关系，前四种分片算法是核心，第五种算法主要是为解决常见的某一类特殊数据分片关系，让分布式数据库HotDB优化器的性能更佳，五种算法的描述信息见图6。
图6 分片算法
四种数据分片算法有各自的算法特征和最佳的业务场景，详细信息见表1：
| 序号 |
算法名称 |
算法简称 |
算法特征描述 |
业务场景 |
| 1 |
路由表 |
Route Match |
须配置每一个分片因子的值与数据节点的对照关系，不要求数据均匀分布的模型。 |
分片因子的值域范围可控的业务场景，例如：按银行、证券、快递、物流、零售等网点编号，B2C平台的网店编号等。 |
| 2 |
范围 约定 |
Range |
配置分片因子的每个值域段与数据节点的对照关系，不要求数据均匀分布的模型。 |
适用范围 同 哈希约定 算法 一样广泛。 |
| 3 |
哈希 约定 |
Hash |
1024作为分母取模计算哈希值，约定哈希值段对应不同的数据节点，不要求数据均匀分布的模型。 |
同上，适用范围更广，例如：按银行、证券、快递、物流、零售等网点编号，C2C/B2C平台的网店编号等。 |
| 4 |
自动 哈希 |
Auto |
按数据分片的数据节点数量作为分母取模，计算哈希值分片，适用于数据均匀分布的模型，追求做到每个数据节点的数据量一致。 |
互联网行业的用户UID、电信行业的手机号、快递行业的运单号、金融行业的帐号、身份证号等。 |
见表1 数据分片算法特征与业务场景
l 分布式数据库的分片规则
MySQL Cluster的NDB存储引擎分布式数据库默认是按主键（注释：若没有主键则选择唯一索引，若二者都没有则默认创建一个主键）进行数据分片，这样设计可降低技术复杂度，但非主键的数据处理的成本较高。分布式数据库的数据架构设计最佳实践经验，需让每张表做到自由选择一个特有的分片字段和分片算法组成表对象的数据分片规则，可让数据结构设计更简洁和技术门槛更低，也更有利于降低数据访问的复杂度，同时能提升优化数据访问的性能。
选择作为表对象的分片字段，建议具备图7所示描述的属性：
图7 分片字段的属性
以金融行业的某大型支付平台数据库的数据分片规则为例，该平台需要处理所有网络支付业务的交易，支付宝、财付通、银联、银行的网银等渠道的在线支付业务都需要借助某大型支付平台中转完成。支付平台采用报文方式交互，则海量报文数据小文件直接采用分布式文件系统存储，从报文中解读出来的业务数据和帐务数据存储到MySQL分布式数据库中。依据每家机构的业务量规模大小和业务数据的特征，则业务数据和帐务数据的数据分片规则设计，如下：
(1) 区域性银行采用机构号作为分片字段，数据分片算法为路由算法。
(2) 全国或大型银行采用机构号与报文标识号组合作为分片字段，数据分片算法为路由算法和哈希约定算法组合。
(3) 小型网络支付机构采用机构号作为分片字段，数据分片算法为路由算法。
(4) 大型网络机构采用机构号与报文标识号组合作为分片字段，数据分片算法为路由算法和哈希约定算法组合。
l 总结
关系型数据库理论创新在上世纪八十年代已达到巅峰，九十年代已完全成熟且再无重大创新或补充，并行数据库较著名的产品有Teradata、Greenplum、Gamma等众多产品，而分布式数据库产品有ADA-DDM、分布式INGRES系统等，仅有无共享架构的MySQL Cluster（NDB存储引擎）较为通用和生产环境可用，但也存在业务场景和数据量的局限性。热璞技术团队耕耘数据库行业十年以上，一直探索与实践追求更优的数据库解决方案，吸收分布式数据库关系理论和并行数据库关系理论的技术算法优势，同时结合单机版开源数据库MySQL的算法特征和技术优势，研发出支持海量数据的存储与服务能力的分布式数据库产品HotDB，是热璞科技在基础软件领域十年铸一剑的成果，已在互联网、快递物流、广电传媒、金融等行业成功实施应用。