如何处理大数据量的查询..docVIP

J2EE综合：如何处理大数据量的查询 　　在实际的任何一个系统中，查询都是必不可少的一个功能，而查询设计的好坏又影响到系统的响应时间和性能这两个关键指标，尤其是当数据量变得越来越大时，于是如何处理大数据量的查询成了每个系统架构设计时都必须面对的问题。本文将从数据及数据查询的特点分析出发，结合讨论现有各种解决方案的优缺点及其适用范围，来阐述J2EE平台下如何进行查询框架的设计。 　　 　　Value List Handler模式及其局限性 　　 　　在J2EE应用中，对于大数据量查询的处理有许多好的成功经验，比如Value List Handler设计模式就是其中非常经典的一个，见图1。该模式创建一个ValueListHandler对象来控制查询的执行以及结果集的缓存，它通过DAO(Data Access Object)来执行查询，并将数据库返回的结果集（传输对象Transfer Object的集合）缓存起来，接下来的客户端查询请求将直接从缓存中获得。它的特点主要体现在两点：服务器端缓存数据，每次只返回客户端本次操作所需的数据，通过这两个措施来减少数据库的访问次数以及增加客户端的响应速度，达到最优的查询效果。当然，这里面隐含一个前提就是客户端采用分页的方式来浏览数据。关于该模式的详细介绍，请参考[Core J2EE Patterns]一书。 　　 　　图1：Value List Handler类图 文章转载自网管之家：/plus/view.php?aid=21749 但是在实际的应用过程中，会发现该模式存在一定的局限性，其实可以说是该模式应用具有一些前提条件：1、由于缓存是以内存来换性能，这对于小数据量会工作得很好，但是如果结果集很大，内存消耗将会非常严重。同时，消耗在处理结果集上的时间也会越来越长，比如要循环读取记录集中的数据，然后依次填充每个传输对象，想想看几百万条数据这样处理起来肯定让人不能忍受。过长的处理时间不仅降低反应速度，同时还会占用宝贵的数据库连接资源，造成其它地方无连接可用。虽然，在DAO模式中利用CachedRowSet，Read?Only?RowSet?，RowSet?Wrapper?List等策略（详见参考资料）来代替Transfer?Object?Collection策略，有效地提高了处理速度，但是仍然存在着在大集合数据中进行定位、遍历等问题。试想一想，即使在CachedRowSet中的absolute(2000000)也是非常费时的操作。所有这一切的根源就在于缓存是一次性读取所有的数据，虽然有时你可以利用业务逻辑来强制性增加一些限制条件（比如产品查询必须选择大类和次类），但这种限制往往是不牢靠的或者说只是一时的权宜之计。也有人提出，可以不必缓存所有的查询结果，而采取只缓存部分结果集，比如500，1000条，但这样一来，就涉及到复杂的查询数据是否越界的控制，增加了复杂度，同时也不易实现。2、既然使用缓存，那就不得不面对一个数据更新的问题，使用缓存，实际上就假定了在数据缓存期间，数据库中的数据不会改变，或者这些改变可以不被反映出来。但是，在很多场合下（比如常见的业务系统中）这些数据库中的数据经常会发生变化，而且这些改变需要及时反映给客户端3、缓存其实存在一个基本前提，就是缓存的数据会被客户端反复查询使用，具体到分页查询就是客户会选择不同的页数来查看数据。如果客户端的查询条件始终变化，或者用户基本上只关心第一页的数据（仔细琢磨一下用户的习惯，这在很多中应用场合都很常见），那缓存就失去了应有的意义，变得多此一举了。数据分析所以说，在决定是否应用某种设计模式前，我们需要对被查询数据的特点以及这些数据以何种方式被使用（查询的特点）进行一个分析，根据不同的结论来决定采用何种处理策略。而且，数据本身的特点和被使用的方式往往交织在一起，需要综合起来考虑，但这其中主要的考量点还是数据查询的特点。一般来说，可以从以下几个方面来分析数据：1、????数据量大。这是我们今天讨论的数据的一个最基本特点，这个特点在查询框架设计时要引起足够的重视。注意：大数据量的查询是指查询时匹配条件的数据量大，而不是指表中的数据量大，虽然大部分时候这两者都是一致的。因为在某些情况下，业务逻辑可以限制或者只需要一次获取很少量的数据，而查询的表中的数据量却可能很大，那这种情况就不属于本文的讨论范围。2、????关联复杂，多表关联。越是简单的数据可能关联越少，而越是复杂的数据往往都是多表关联，这样很多时候你需要将这几张表作为一个整体来考虑。3、????变化频率。从这个角度出发，可以大致将数据分为以下几类：几乎不变化的睡眠数据；有规律定时更新的数据，比如招聘网站的职位信息；经常性无规律更新的数据。4、????成长性。