java访问数据库速度_Java访问数据库的速度瓶颈问题的分析及解决

Fast Lane Reader

抛弃EJB，加速只读数据的存取。

有些时候，高效地存取数据比获得最新的数据更重要。在Java Pet Store中，当一个用户浏览商店的目录时，屏幕与数据库内容吻合不是至关紧要的，相反，迅速显示和重新获得非常重要。FLR模式可以加速从资源中重新获得大型的列数据项的速度，它不用EJB，而是更直接地通过DAO来存取数据，从而消除EJB的经常开支(例如远程方法调用、事务管理和数据序列化等)。

在Java Pet Store这个例子中，当一个用户浏览目录时，通过CatalogDAO(而不是CatalogEJB)从数据库加载数据项，而CatalogDAO是一个Fast Lane Reader的实例，使得读访问变得迅速，如图4：

图4 Fast Lane Reader设计模式

与DAO模式不同的是，FLR是一个优化的模式，但不是要替代原有的访问机制，而是作为补充使其完备。当你频繁地只读大型的列数据和不必存取最新的数据时，使用FLR将是非常合适的。

Page-by-Page Iterator

为了高效地存取大型的远程数据列，一下子通过重新获得其元素为一个子列的Value Object(提高远程传输效率的设计模式，这儿不详尽描述)。

分布式数据库的应用经常需要用户考虑一长列数据项，例如一个目录或一个搜索结果的集合。在这些情况下，立刻提供全列的数据经常不必要(用户并不是对所有的数据项感兴趣)或不可能(没有足够的空间)。此外，当重新获得一列数据项时，使用Entity Bean的代价将非常高昂，一个开销来自于使用远程探测器来收集Requested Bean，另外，更大的开销来自对每个Bean产生远程调用以从用户获得数据。

通过Iterator，客户机对象能一下子重新获得一个子列或者页的Value Object，每一页都刚好满足客户机的需求，因此，程序使用较少的资源满足了客户机的立刻需求。

在Java Pet Store这个例子中，JSP页面product.jsp任何时候只显示一个数据列的一部分，从ProductItemListTag(Page-by-Page Iterator)重新获得数据项，当客户机希望看到列中的别的数据项，product.jsp再次调用Iterator重新获得这些数据项，流程见图5：

图5 Page-by-Page Iterator设计模式

以上设计模式的应用向我们表明，在某些特殊情况下，优化对数据库的访问模型，既可满足用户的需求又可提高访问数据库的效率。这给我们一个思路，就是：在你的硬件环境可能会产生瓶颈的情况下，可以通过对软件模型的优化来达到满足需求的目的。上述三种设计模式的应用情形为：

Data Access Object

需要将商业逻辑和数据存取逻辑分离；在调度的时刻，需要支持选择数据源的类型；使用的数据源的类型的变化，对商业对象或其它客户端完成数据存取没有影响。

Fast Lane Reader

面对大型的列数据，需要经常的只读访问；访问最新的数据并不是至关紧要的事情。

Page-by-Page Iterator

存取大型的服务器端数据列；任何时刻，用户只对列的一部分内容感兴趣；整个列的数据不适合在客户端显示；整个列的数据不适合在存储器中保存；传输整个列的数据将耗费太多的时间。