一、集群化方案

1、MySQL应用的演化

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

只有MySQL

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

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

单实例的问题:

从MySQL到HBase:数据存储方案转型的演进一旦MySQL挂了,服务全部停止;
从MySQL到HBase:数据存储方案转型的演进一旦MySQL的磁盘坏了,公司的所有服务都没有了 (一般会定时备份数据文件)。

主从方案

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

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

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

从MySQL到HBase:数据存储方案转型的演进为了扩展读能力可以增加多个slave;
从MySQL到HBase:数据存储方案转型的演进允许slave同步有一定的延迟;
从MySQL到HBase:数据存储方案转型的演进一致性要求严格的,可以指定读主库。

主从功能的问题:

从MySQL到HBase:数据存储方案转型的演进需要增加管理Proxy层,分配写请求、读请求;
从MySQL到HBase:数据存储方案转型的演进节点故障:其它节点应该快速接管故障节点的功能。

垂直拆分

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

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

垂直拆分的问题:

从MySQL到HBase:数据存储方案转型的演进线下分析,需要在业务代码里join各个表。因为拆成多个库,已经无法join了。
从MySQL到HBase:数据存储方案转型的演进不容易做数据库的事务性,用户余额减少与下单成功的情况下无法使用MySQL的事务功能。

水平拆分

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

原文链接

相关文章: