从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的事务功能。