我做的项目因为涉及到大量的历史数据增加而采用的非关系型数据（mongodb），但是在实际开过程中遇到了很多问题，有开发方面的，也有管理方面的，于是我思考了用关系型数据库mysql代替非关系型数据库mongodb的思路。

目前还没有实施，因为对项目的改动会很大，希望大家能看看我的思路，最好能提一些意见，谢谢各位了。

方案的核心在于将目前一个数据库分割为两个数据库，一个当前交易库，一个历史数据查询库。

---------------------------详细方案如下----------------------------------

建立两个mysql数据库，一个是当前业务库叫bussDB，一个是数据中心库叫datacenterDB。

 两个数据库如何运作： 

1、datacenterDB库和bussDB库表结构基本完全一致。bussDB库存放正在进行的交易，datacenterDB库存放当前正在进行的交易和所有历史交易。
2、业务后台管理系统和业务前台网站都直接连接bussDB库进行正常业务操作。
3、历史查询、分析统计系统连接datacenterDB库进行查询统计。
4、bussDB库按照适合oltp(交易型)的库进行数据库存储和建模的优化。
5、datacenterDB库按照适合olap(分析型、数据仓库)的库进行数据库存储和建模的优化，可以使用表分区和集群等技术。
6、每天晚上，自动定时通过ETL工具（数据库同步工具）将bussDB库中的信息自动同步到datacenterDB库中。
7、设置程序自动在交易完成后180天以后将交易信息清除，清除之后关于该交易的查询在datacenterDB库中查询。

为什么要分为两个数据库：

1、适合交易的数据库和适合分析的数据库建模有一定区别，bussDB是交易型，而datacenterDB是查询分析型。
2、bussDB库需要保证快速响应，不因为历史数据的不断增大而影响速度，因此需要定期清除数据和数据转存。
3、bussDB库是一个事务型的数据库，需要保证事务完整性，因此不适合做集群，应采取垂直扩展（高性能服务器）。
4、datacenterDB库是一个数据仓库的数据库，需要集群和水平扩展（廉价PC，做集群）。

为什么要用关系型数据库而不用非关系型数据库。

• 
  1、在以上方式设计的bussDB库的状态下，对于增删改查操作，关系型数据库和非关系型数据库的性能开销基本一致，因为所有表的数据量都非常小，小于百万级，因为在千万级数据量以下，关系型数据库只要设置了索引，都是非常快的。
  2、在性能方面一致的情况下，非关系数据库的缺点在于无法支持动态连接查询应用，即sql中的join操作，或者说是join效率不如关系型数据库高，另外也不支持分组(group)和统计操作(count/sum/avg等)，在业务系统中存在大量的join操作，比如，报表打印、银行缴费对账、员工、机构、角色、交易、科目、字典等复杂应用都涉及到大量关联，所以非关系型数据库在这些处理方面不如关系型数据库灵活和性能高，编写的代码可读性和健壮性也较低。
  3、关系型数据库的管理工具比如sqlyong，比非关系型数据库的管理工具更丰富，也更完善。对于数据库的DBA维护而言，关系型数据库的批量更新、导入、导出、备份、优化等方式和资料都丰富，对于开发人员的入门门槛，关系型数据库也比较低。
  4、关系型数据库的发展历史和稳定性要超过非关系型数据库。
  5、既然在性能一致的情况下为什么不用关系型数据库呢。
  6、datacenterDB库就必须是用关系型数据库了，因为datacenterDB大量的统计应用都是基于sql中的统计函数的，比如查询交易业务性别比例、学历分布等，都涉及到sql操作，比如，join,group by xxx,sum(),count(),avg()等，这些都是非关系型数据库不支持的。