Mysql 应用的演化

Mysql 与 Hbase 说到最核心的点，是一种数据存储方案。方案本身没有对错、没有好坏，只有合适与否。 相信所有的公司都与 MySql 有着不解之缘，部分学校的课程甚至直接以 sql 语言作为数据库讲解。

只有 mysql

笔者呆的上家公司是一个 O2O 创业公司，所有的数据都存储在同一个 MySql 里，而且没有任何主备方案。相信这是一个很多初创公司典型的解决办法。当时，这台 Mysql 为用户、订单、物流服务，同时也为线下分析服务

单实例的问题：

1. 一旦 mysql 挂了，服务全部停止了
2. 一旦 mysql 的磁盘坏了，公司的所有服务都没有了 （一般会定时备份数据文件）

主从方案

随着业务增加，单个 DB 是无法承载这么多的请求的。于是就有了主从复制、读写分离的解决方案

master 只负责写请求，slave 同步 master 用来服务读请求

1. 为了扩展读能力可以增加多个 slave
2. 允许 slave 同步有一定的延迟
3. 一致性要求严格的，可以指定读主库

主从功能的问题：

1. 需要增加 管理 proxy 层，分配写请求、读请求
2. 节点故障：其它节点应该快速接管故障节点的功能

垂直拆分

业务继续增长，master 甚至都无法承载所有的写请求。数据库需要按业务拆分。

垂直拆分的问题：

1. 线下分析，需要在业务代码里 join 各个表，因为拆成多个库，已经无法 join 了
2. 不容易做数据库的事务性，用户余额减少，与下单成功无法使用 mysql 的事务功能

水平拆分

业务继续增长，订单表有大量的并发写入，而且已经有了几千万行数据。

1. 单个库无法承载大量的并发写入
2. 上千万行的大表，数据写入可能需要调整一棵巨大的 B+ 树
3. 上千万行，B+ 树过深，读写需要更多的磁盘 IO
4. 很多老数据访问较少，B+ 树上层缓存的部分信息无用
5. 。。。

参考：

大众点评订单系统分库分表实践

水平分库/分表带来的问题

1. 维护 map 方案
2. 辅助索引只能局部有效
3. 由于分库，无法使用 join 等函数；由于分表 count、order、group 等聚合函数也无法做了
4. 扩容：需要再次水平拆分的：修改 map，迁移数据。。。

Mysql 的问题

Mysql 的主要瓶颈，单机单进程。CPU 有限、内存/磁盘功能、连接数有限、网卡吞吐有限。。。

集群的限制点

• 关系型数据库，纵向的外键相互 join (范式)
• 数据库事务性，基于单机的锁机制，无法扩展到集群中使用
• 全局有序列性，基于 B+ 树，数据有序聚合存储，集群化后无法保证
• 数据本地存储，扩容需要迁移数据

集群的方案

放弃部分功能，辅助索引检索、join、全局事务性、聚合函数等。当然有些牛逼的分布式数据库，试图解决这些问题（如 TIDB）。

• 水平拆分：存储 KV 化，用机械的 map 思路实现集群
• 扩容方案：手动导数据，开发数据迁移脚本
• 事务性：两阶段事务、paxos、单库事务。。。
• 备份容灾：从节点同步主节点，但有一定的数据延迟
• 服务稳定性：主节点挂了，proxy 会将从节点升级为主节点；从节点挂了会被其它从节点替换

HBbse 集群化解决方案

水平拆分

• region: 拆分后的子表
• region server: 管理这些数据的 server，相当于一个 mysql 实例
• .META. 表存储拆分信息 map<row, server>

单个 region 过大，RegionServer 将 region 会均分为两个（自动、手工）。然后更新 .META. 表

扩容方案

RegionServer 向 HMaster 汇报状态。HMaster 为 RegionServer 负载均衡，调整其负责的 region

增/删 RegionServer 后，会为重新调整 region 的分配方式

服务稳定性

RegionServer 只是计算单元，挂掉后 Hmaster 可以随便再找一个节点代替坏节点服务

事务性

HBase 只保证行级事务，单行数据肯定存在同一台机器 (单机事务很好做)

备份容灾

数据使用 HDFS 存储，多复本，任何一个复本挂掉都不影响功能

RegionServer 只是计算单元，挂掉后不影响服务