解决的问题

目前已经面临或者未来可能面临的问题有以下这些：

1.数据量越来越大，超出了单表或者单库的最大限制。

2.数据访问压力越来越大，超出了数据库系统能力。

3.数据访问层运维问题。

4.数据访问层高可用方案。

5.数据访问层访问控制和管理。

暂时不解决的问题包括：

对非关系型数据存储的统一访问。

自主开发还是扩展？

为了解决上述问题，有很多可选的方案。自主开发和使用现有开源方案扩展的讨论是经常会面临的，详细讨论过程就不再赘述，直接列出讨论的结果。

结论：基于目前开源方案进行扩展和定制实现。具体原因有以下这些：

a.我们的使用场景很简单，大多数开源解决方案都可以很好地实现，而且目前有很多可选的开源方案，直接使用开源方案可行。

b.完全自主开发的周期更长、技术风险都非常大，这都是咱们无法承担的。

c.选择一个源代码开放、需求最符合、代码能够扩展和定制的开源产品可行。基于该开源产品，通过

不断深入学习使用方法，学习实现原理和源代码实现，达到可以自由扩展和定制，以改造成完全符合

自身需求的产品。

技术方案选型

可选方案分类概述 对于ddal来说，最核心的一个需求莫过于分库分表，而对于分库分表，已经有很多的开源产品出现了，比如cobar-client、hibernate shards、guzz、halo-dal、ibatis-sharding、cobar、mysql proxy、tddl等。每一个产品都有针对于不同层面进行封装而达到屏蔽上层对底层分库分表的具体细节的依赖，都是加载数据库访问客户端和服务端之间的一些中间层。

总结一下上述列出的各种解决方案可以归纳为一下几大类。

1.DAO层。该方案即通过在实现DAO层代码时候，通过硬编码的方式加入分库分表的逻辑，该层实现一般由项目组自行根据需求实现。

2.ORM 框架层。该方案的实现是通过实现一个ORM框架，该框架自带分库分表功能，如：guzz；另外一种方式是基于开源成熟的ORM框架（比如MyBaits、HIbernate）进行扩展分库分表特性，主要的开源产品有：cobar-client、hibernate shard、shalo-dal、ibatis-sharding。

3.JDBC API层。该方案通过封装JDBC API，实现分库分表逻辑，这个方法比较直接，而且有比较强的可控制性，目前还没有发现成熟的开源产品可用。

4.数据访问代理层。该方案通过位于客户端和服务端中间的代理服务器实现分库分表逻辑，主要产品有mysql proxy、Cobar和amoeba等。

5.数据库分区。该方案是数据库自行实行的分库分表特性。目前主流的关系型数据库，商业数据库Oralce、SQL server和DB2早就有非常成熟的数据库分区解决方案，而主流的开源数据库MySQL和PostGre也在5.0和8.0版本也增加了数据库表分区的特性。

如上图所示，展示的是各种方案之间的关系，还包括了各种方案所处的层次，图中带颜色的各区块表示的是各种实现方案。

上图中的关系是越处于下方的层次越低，上层的总是依赖下层，下层不依赖上层。各种层次的实现方案都有自己的优缺点，有自己适合的场景。

可选方案对比分析

各种可选方案都能够从不能程度上实现分库分表的核心需求，每种方案都有自己的优势和适合的应用场景，同时也有它的缺点和使用上的限制，通过对各种方案的详细各种因素的综合对比分析才能选择一个最适合一种或者多种方案的组合。