从MySQL到HBase：数据存储方案转型的演进

一、集群化方案

1、MySQL应用的演化

MySQL与HBase说到最核心的点，是一种数据存储方案。方案本身没有对错、没有好坏，只有合适与否。相信多数公司都与MySQL有着不解之缘，部分学校的课程甚至直接以SQL语言作为数据库讲解。我想借自身经历，先来谈谈MySQL应用的演化。

只有MySQL

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

单实例的问题：

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

主从方案

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

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

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

主从功能的问题：

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

垂直拆分

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

垂直拆分的问题：

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

水平拆分

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

原文链接