关系数据库迁移非关系数据库方案(iwantmoon.com出品）

经常遇到一些同行，在遇到大数据量和大并发量的背景的时候，愁眉不展，加班不断。对于NoSql带来的分布式数据库，表示距离很远，同时迁移成本很高，风险也很高。

那么本文，我们就来讨论一下，如果我们确定要从MySql(关系数据库）迁移至非关系数据库，我们会遇到的问题，以及解决方案

首先，我们还是要讨论一下，关系数据库的一些优化方案，下图是主从，也就是传统上讲的读写分离：

这种模式，适合写少读多，一处写，再同步给各读库，降低了，分散了读的压力 。

上图，为双机互备，适合读多写多的场，任一服务器得到 数据，会同步给另外一台。分散了读写压力。

以上两种模式，是目前关系数据库部署的架构，当然，在结构上，人们还找到一些技巧：分表和分库，因为本文主讲，不是关系数据库优化，所以这里就不再多提这块。如果大家有兴趣，欢迎在技术QQ群里面讨论：299388502。

对于关系数据库两种结构，我们很明显可以看到问题：

1、读写分离，写压力在一台服务器上，虽然将读请求分开，但同步需要时间，做不到实时同步。

2、双机互备，同样有同步延时的问题。

3、并没有从根本上解决数据库需要的大IO需求。

=======================================================

至此，我想问题，已经解释清楚了，下面我们简单介绍一下HBase

HBase源于06年Google开放的论文Big Table，和之前开放的两篇 GFS and MapReduce，他是Big Table的开源实现，另外两个项目对应的开源实现是Hadoop(HDFS/MapReduce)，由于本文并不是主讲HBase原理，所以 小伙伴们，大家需要自己去看一下，同时如果有兴趣，欢迎到QQ群讨论：299388502

下面我们回到主题 ，MySql怎样迁移到HBase。

一、冷切换

冷切换，主要是需要停止服务，开始备份数据，备份完成之后再开启新的服务。

冷切换的场景，本文不是主讲，同时，并不适合互联网项目的需求 ，当然12306不算，人家铁道部人傻有资本，不是我们能比的。一些企业项目可以考虑冷切。

二、热切换

热切，是需要，不影响目前线上的服务的同时，做到MySql到HBase的切换。那么，我们面临的问题是：

1、在开始备份的时候，线上服务，依然在运行着。

2、在备份过程中，产生的新数据，怎样处理

3、如何做到无缝切换。

=====================================

问题出来了，那我们讨论一下，解决问题的方案，首先看图：

1、在不停止线上服务的情况下，我们在Time 0点开始备份

2、在Time 1点完成数据备份，同时我们开始Double Write（双写），确保Time 1点之后的数据完全同步， 主源为MySql ，副源为：hbase。

3、开始备份 Time 0 到Time 1产生的数据。

4、备份完成后，这个时间点可以将主源切换为HBase，副源为MySql，这时MySql作为一个抗灾的角色出现。

5、HBase only这个阶段，视各项目自身情况而定。如果你们想更保险一点，可以让双写状态延续时间长一点。

OK，到此为止，基本上我们讨论结束了。

同时，欢迎大家参与敲代码程序员社区的技术讨论

我们的网站：http://iwantmoon.com

QQ群：299388502