如何提高企业网站大数据量查询效率（转载）

                           如何提高企业网站大数据量查询效率

摘自：http://clglctm.blog.hexun.com/26073206_d.html

摘  要：目前企业信息化正在如火如荼地开展之中，企业信息量在急剧膨胀。这使得信息的搜索工作变得极为繁重起来。据调查统计，人们在平时的工作中，有70%的时间都花费在信息搜索上。由此，如何提高人们搜索信息的效率成为众多企业为之努力的方向。于是企业网站的Web应用系统中，信息查询设计的好坏直接影响到系统的响应时间和性能这两个关键指标，尤其是当数据量变得越来越大时，如何处理大数据量的查询成了每个程序开发人员都必须面对的问题。本文从系统架构设计，查询框架设计，数据库连接池技术三个方面，探讨如何解决Web应用的大数据量查询，并结合中南电力设计院综合MIS平台、质量管理信息系统及OA系统的技术情况，介绍了提高大数据量查询效率的经验。

关键词：系统架构 JAVA 数据库连接池 大数据量访问

 

前言

随着全球信息产业蓬勃发展，计算机网络构成了信息通信的高速公路。有了网络的全天候支持，企业的生产水平、服务质量及工作效率都得到了极大的提高。但同时由于客户访问量及数据量的不断增长，使后台服务器系统的并发承载能力面临极大的挑战。

结合中南电力设计院几年来质量管理信息系统、电子媒体归档系统、OA系统及综合MIS系统等网络应用积累的经验，从系统架构设计，数据库存取，数据库连接池技术三方面对大数据量的访问效率进行了研究，总结出一套适用于企业网站应用建设的解决方案。

 

系统架构设计

什么是系统的架构（Architecture）？一般而言，架构有两个要素：

·它是一个软件系统从整体到部分的最高层次的划分。

一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。

详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。

·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。

在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

一般而言，软件架构设计要达到如下的目标：

·可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

·安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

·可升级性（Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

·可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

·可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展

·可维护性（Maintainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费

·客户体验（Customer Experience）。软件系统必须易于使用。

·市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

一言以蔽之，系统架构决定着企业网站的WEB应用系统的生死存亡。

应用系统的发展经历了从两层架构到三层（或多层）架构的过程，在应用系统中通常包含三个逻辑组成部分：表达逻辑、事物逻辑、数据存储。目前的三层（或三层以上的）B/S架构通常是以Brower/Web server/DataBase形式为主，这可以将表达逻辑分布在客户浏览器上，数据存储分布在数据库服务器端，而事务逻辑单独作为一层，结合在Web服务器（或其它服务器）中。这样可简化应用发布和维护，更利于软件集群化的分担模式，增加并发处理能力，灵活的完成多主机的分担切换和相互备份作用，实现了并发性保障。

按照客户表达层、事物逻辑处理层和服务器数据存储层三个方面设计的系统，可根据业务量的多少分配多台主机，可实现客户端的简洁性、系统的逻辑安全性、服务器的负载均衡等特点。

中南电力设计院的综合MIS平台的系统架构设计就是按照以上思路进行的。

 

查询框架设计

数据查询是WEB应用系统中的重要操作，又相当消耗资源。在J2EE应用中，对于大数据量查询的处理有许多好的成功经验，在决定应用某种设计模式前，我们需要对被查询数据的特点以及这些数据以何种方式被使用（查询的特点）进行一个分析，根据不同的结论来决定采用何种处理策略。而且，数据本身的特点和被使用的方式往往交织在一起，需要综合起来考虑，但这其中主要的考量点还是数据查询的特点。

一般来说，可以从以下几个方面来分析数据：

1、      数据量大。

这是本文讨论的数据的一个最基本特点，这个特点在查询框架设计时要引起足够的重视。

注意：大数据量的查询是指查询时匹配条件的数据量大，而不是指表中的数据量大，虽然大部分时候这两者都是一致的。因为在某些情况下，业务逻辑可以限制或者只需要一次获取很少量的数据，而查询的表中的数据量却可能很大，那这种情况就不属于本文的讨论范围。

2、      关联复杂，多表关联。

越是简单的数据可能关联越少，而越是复杂的数据往往都是多表关联，这样很多时候你需要将这几张表作为一个整体来考虑。

3、      变化频率。

从这个角度出发，可以大致将数据分为以下几类：几乎不变化的睡眠数据；有规律定时更新的数据，比如人事系统的人员信息等。

4、 成长性。

数据是否具有成长性，要预见数据的成长性，并在现有方案中考虑这种成长性，避免到时候查询框架的重新设计，象大部分的业务数据都具有这种成长性。
注意：这里也要特别注意区分数据本身的成长性和数据查询的成长性，这看似等同的两者其实还是存在很大的区别。就拿档案系统来说，电子图纸的数据肯定是一天天在增加，具有高成长性，但是在某个区间（比如一个月，一个星期）内的针对某一个工程的电子图纸查询则变化不会太大，不具有成长性。而后者却往往是实际系统中最常遇到的查询情况。

5、 数据查询的频率和方式。

所有的数据查询不可能被等同地使用，你要分清楚系统中的几个关键查询，这些查询使用频率高，响应要快。试想一想，如果一个档案查询系统每次都要让用户等上十秒钟，结果就可想而知。

接下来就可以根据这些分析来设计应用系统的查询框架。在J2EE架构下，对于大数据量的查询主要采取以下两种方法：

基于缓存的方式：

从数据库得到全部（部分）数据，并将其在服务器端进行缓存，接下来的客户端请求，将直接从缓存中取得需要的数据。这其实就是经典的Value List Handler模式的原理（如下图），该模式创建一个ValueListHandler对象来控制查询的执行以及结果集的缓存，它通过DAO(Data Access Object)来执行查询，并将数据库返回的结果集（传输对象Transfer Object的集合）缓存起来，接下来的客户端查询请求将直接从缓存中获得。它的特点主要体现在两点：服务器端缓存数据，每次只返回客户端本次操作所需的数据，通过这两个措施来减少数据库的访问次数以及增加客户端的响应速度，达到最优的查询效果。它主要适用于数据量不是非常大，变化不是很频繁（或者变化频繁但是有规律）且不具有成长性的情况，比如人事系统的大部分查询就非常适合采取这种方式。

 

采用这种方式，要特别注意第一次查询问题，避免响应性能达不到要求，因为每个查询第一次都需要连接数据库，从中获取数据并缓存起来，所以第一次查询会比接下来的查询都显得更慢一些。

对于数据的缓存，有以下几种实现方式：

直接缓存在服务器端

Value List Handler模式就采取这种方式，并且可以根据不同的情况采取不同的缓存策略，比如Transfer Object集合，CachedRowSet等，这取决于你的DAO实现策略。

用临时表来保存查询结果

WLDJ（www.sys-con.com/weblogic/）杂志2004年第7期上有一篇名为“Handling Large Database Result Sets”的文章，它详细介绍了如何利用临时表来改良Value List Handler模式以支持大型的J2EE应用。

 

基于查询的方式：

不进行数据缓存，客户端的每次数据请求都需要进行实际的数据库查询，这种方式适用于量大，具有成长性，变化频繁的数据。该方式的特点是每次查询的时间都大致相等，不会存在基于缓存的方式的第一次查询问题，但后续的操作会比缓存方式的查询慢一些。采取这种方式的查询框架设计更具有可扩展性以及对数据变化更好的应变能力，在大部分的业务系统中都推荐使用该方式。

使用这种方法，每次查询应该只从数据库获得客户端所需的数据，这样就涉及到如何获得部分数据的问题。一种是查询出符合条件的所有记录，然后遍历该记录集，根据上次查询结果来比较记录中的某些字段获取本次查询需要的部分数据，由于要对记录集进行遍历，效率不高，一般都不推荐使用，而往往采用另一种增加sql查询语句条件的方式。

 

数据库连接池

Java的数据库连接通常利用JDBC（Java Database Connectivity）来做的，JDBC是一个Java扩展API，它为编程者提供了基于SQL查询的数据访问能力。但是，通过JDBC连接访问数据库服务器的能力，对于有大数据量访问的应用程序还是不够的。引入连接池的目的就是改善依赖于数据库的java服务器代码的性能和并发性，解决三层架构中的中间层与第三层之间的开销。

数据库连接是一种关键的有限的昂贵的资源，这一点在多用户的网页应用程序中体现得尤为突出。对数据库连接的管理能显著影响到整个应用程序的伸缩性和健壮性，影响到程序的性能指标。数据库连接池正是针对这个问题提出来的。

连接池是数据库连接的缓冲区，它位于内存中，由于使用了连接池，所以连接可以被重复使用，而无需在每次使用完后，都需要进行创建和撤销操作。所以采用连接池具有减少工作量，更加容易移植和总体性能更高的优点。

数据库连接池负责分配、管理和释放数据库连接，它允许应用程序重复使用一个现有的数据库连接，而再不是重新建立一个；释放空闲时间超过最大空闲时间的数据库连接来避免因为没有释放数据库连接而引起的数据库连接遗漏。这项技术能明显提高对数据库操作的性能。

数据库连接池在初始化时将创建一定数量的数据库连接放到连接池中，这些数据库连接的数量是由最小数据库连接数来设定的。无论这些数据库连接是否被使用，连接池都将一直保证至少拥有这么多的连接数量。连接池的最大数据库连接数量限定了这个连接池能占有的最大连接数，当应用程序向连接池请求的连接数超过最大连接数量时，这些请求将被加入到等待队列中。数据库连接池的最小连接数和最大连接数的设置要考虑到下列几个因素：

1) 最小连接数是连接池一直保持的数据库连接，所以如果应用程序对数据库连接的使用量不大，将会有大量的数据库连接资源被浪费；

2) 最大连接数是连接池能申请的最大连接数，如果数据库连接请求超过此数，后面的数据库连接请求将被加入到等待队列中，这会影响之后的数据库操作。

3) 如果最小连接数与最大连接数相差太大，那么最先的连接请求将会获利，之后超过最小连接数量的连接请求等价于建立一个新的数据库连接。不过，这些大于最小连接数的数据库连接在使用完不会马上被释放，它将被放到连接池中等待重复使用或是空闲超时后被释放。

基于Web的中间件产品较多,它们都可以实现池的作用，在我们中南电力设计院的质量管理信息系统，电子媒体查询系统和OA系统中选用Tomcat作为数据库中间件进行数据库连接池管理，利用Tomcat自身的管理机制来监视数据库连接的数量、使用情况, 程序效率得到显著提高。（限于篇幅，连接池配置代码略）                                       

 

结论

目前随着企业网络应用的发展，大数据量访问的效率问题已经越来越突出，甚至在某些地方成了企业发展的瓶颈。在中南电力设计院的MIS软件开发过程中也遇到同样的问题，曾经出现在网页上生成一个树状结构需要等待30秒左右的情况，而那时后台数据还不到一万条，经过对软件的数据访问效率的研究之后，提出了这套解决方案，同样的一个树状结构用户最多只需要等待3秒钟就可以完成。经过几年的运行与调试，目前各系统总体体能表现非常地稳定，能够满足企业用户需要。

 

  学习： 看样子还要学习一下TOMCATE配置