海量数据库记录的归档和查询方法.pdf

摘要
申请专利号：	CN200810043784.0	申请日：	2008.09.18
公开号：	CN101676899A	公开日：	2010.03.24
当前法律状态：	撤回	有效性：	无权
法律详情：	发明专利申请公布后的视为撤回IPC(主分类):G06F 17/30公开日:20100324\|\|\|实质审查的生效IPC(主分类):G06F 17/30申请日:20080918\|\|\|公开
IPC分类号：	G06F17/30	主分类号：	G06F17/30
申请人：	上海宝信软件股份有限公司
发明人：	王新春; 代真虎; 徐培杰
地址：	201203上海市浦东新区郭守敬路515号
优先权：
专利代理机构：	上海浦一知识产权代理有限公司	代理人：	丁纪铁
PDF下载：	PDF下载

内容摘要

本发明公开了一种海量数据库记录的归档和查询方法，归档记录包括对海量数据库记录进行分组，利用倒排索引技术建立索引文件，对需要模糊查询的字段进行分词；采用压缩算法对记录分组压缩并写入数据文件；将索引文件和数据文件保存到文件系统中。查询归档记录的时候先对查询条件做预处理和分词，根据查询条件在索引中找到匹配的记录在数据文件中的文件指针信息；解压对应的记录并将记录的详细信息返回给用户或其他系统。本发明能够高效的对数据库海量记录的归档和查询，克服归档记录有限，查询复杂和性能低下，用户掌握困难等缺点；独立

权利要求书

1、  一种海量数据库记录的归档方法；其特征在于，包括如下步骤：
(1)在数据库中获取一个需要归档的表中的记录；
(2)将步骤(1)获取的记录进行分组；
(3)对分组后的各组记录建立索引文件；
(4)对建立好索引文件的组进行数据压缩后归档；
(5)重复步骤(3)和步骤(4)直至步骤(1)获取的记录全部归档；
(6)若所述数据库中还有未归档的表，则返回步骤(1)。

2、  如权利要求1所述的海量数据库记录的归档方法，其特征在于，步骤(2)所述分组是将所述海量数据库记录按照每组固定记录数量的方式进行分组。

3、  如权利要求1所述的海量数据库记录的归档方法，其特征在于，步骤(3)所述的建立索引文件包括如下步骤：
(1)对每条记录需要查询的每个字段建立相应的倒排索引；
(2)对需要支持模糊查询或全文搜索的字段的文本进行分词；
(3)将同一个表中需要归档的记录建立一个索引文件。

4、  如权利要求1所述的海量数据库记录的归档方法，其特征在于，当步骤(2)中包括可转换为数字类型的数据记录时，先转换为数字数据后再索引和压缩归档。

5、  如权利要求1所述的海量数据库记录的归档方法，其特征在于，步骤(3)对一组记录建立索引文件时，包括计算该组记录压缩后的大小，并将该组记录中每条记录在数据文件中的确切位置作为记录的文件指针，写入索引文件中。

6、  如权利要求5所述的海量数据库记录的归档方法，其特征在于，所述文件指针包括：当前记录的压缩块在数据文件中的位置、记录压缩块的压缩前后大小及所述记录在压缩块中的序号。

7、  一种海量数据库记录的查询方法；其特征在于，包括如下步骤：
(1)解析用户输入的查询条件，去掉无意义的查询条件和影响系统正常运行的特殊字符；
(2)在索引文件中找到含有关键字的记录索引，根据记录的文件指针确定记录所在数据块在存档文件中的位置及记录在其所在数据块中的位置；
(3)根据记录所在数据块在存档文件中的位置查找并解压缩相应数据块文档，进一步根据记录在数据块中的位置查询到完整的数据记录。

8、  如权利要求7所述的海量数据库记录的查询方法，其特征在于，步骤(2)所述在索引文件中找到含有关键字的索引记录包括输入的查询条件进行分词，将分词后的结果到对应字段的索引中进行查询。

9、  如权利要求7所述的海量数据库记录的查询方法，其特征在于，当步骤(1)输入的查询条件为多个时，按照逻辑关系组合查询条件。

10、  如权利要求9所述的海量数据库记录的查询方法，其特征在于，步骤(1)输入的查询条件包含在归档建立索引中转换过的数字数据类型时，先将该查询条件转换成数字数据类型，并根据数字数据范围确定查询区域的范围。

11、  如权利要求7所述的海量数据库记录的查询方法，其特征在于，步骤(3)完成后将结果通过Web界面或者其他图形界面返回给用户。

说明书

海量数据库记录的归档和查询方法
技术领域
本发明涉及一种数据库记录的归档和查询方法，具体涉及一种海量数据库记录的归档和查询方法。
背景技术
在数据库系统中，对于数据量会不断增长的数据库表，当数据量积累到一定规模以后，往往使得系统的性能下降非常明显，不管是查询、新增、修改还是删除，数据量增大以后，对数据库系统的日常维护，如备份等会造成很多麻烦。对于这种数据会不停增长的表，如操作日志，超过一定时间以后其中的记录会被修改的几率就会很小，形成历史记录，对这些记录的处理一个比较好的方式就是执行归档。目前对大量历史记录的归档的处理虽然有多种方式，但是均不是很理想；要么实现效果不好，要么太复杂成本太高。本发明的目的就是为了提供一种对海量数据的归档方式，能够简单、高效的存储和访问这些数据。其基本思路是在归档的时候，对不同的数据进行分别处理，建立索引和压缩的数据文件，将归档文件(索引文件和数据文件)存储在文件系统中，并对归档以后的记录提供独立高效的查询支持。
现有解决数据库表中历史数据的问题，通常有以下几种方案，将逐一分析其应用的局限和不足：
(1)在原有表的基础上，增加归档表
这种方案将超过一定时间的历史记录转移到归档表中进行保存。查询的时候，如果在当前的数据表中没有查到，就转到归档表中进行查询。这种方案能够在比较短的时间或者数据量增长不是很迅速的时候，基本能够满足需求。但是如果数据量增长很快，那么归档表中的记录也会增加很庞大，严重影响性能；同时这种方案也不能无限制的保留归档记录。
(2)多个归档表加删除记录
在单个归档表的基础上，再增加一定数量的归档表，归档表进行循环使用，当归档表使用到最后一个规定表的时候，将记录删除。这种方式能够保留更多的归档数据，但是同样存在问题。首先是查询问题，如果归档表以时间来进行分割的，按照时间的范围进行查询的时候，可以只在相应的表中进行查询；但是不以时间范围查询，需要遍历所有归档表的时候，由于归档表中有大量的数据，查询的时候性能很难忍受。其次是保留的记录还是有限，因为最终数据还是会被从系统中清除。
(3)归档到文件，查询的时候恢复
这种方式是将记录执行归档的时候保存到文件系统中，需要查询的时候将保存的文件的记录恢复到数据库系统中。这种方式能够满足归档记录长期保存的需要，但是查询的时候复杂，不管是恢复到原有系统还是新的系统中，都要执行恢复的操作和过程。
(4)归档到其他数据库系统
将需要归档的记录转移到其他数据库系统中，查询的时候，在各个数据库系统中并行查询或者将查询的结果组合。这种方式增加了软硬件投资的成本，同时也增大了实现的复杂度。
发明内容
本发明所要解决的技术问题是提供一种海量数据库记录的归档方法，它能够高效的对数据库海量记录的归档和查询，克服归档记录有限，查询复杂和性能低下，用户掌握困难等缺点。为此，本发明还要提供一种海量数据库记录的查询方法。
为了解决上述技术问题，本发明的海量数据库记录的归档方法，包括如下步骤：
(1)在数据库中获取一个需要归档的表中的记录；
(2)将步骤(1)获取的记录进行分组；
(3)对分组后的各组记录建立索引文件；
(4)对建立好索引文件的组进行数据压缩后归档；
(5)重复步步骤(3)和步骤(4)直至步骤(1)获取的记录全部归档；
(6)若数据库中还有未归档的表，则返回步骤(1)。
基于上述归档方法，本发明的海量数据库记录的查询方法，包括如下步骤：
(1)解析用户输入的查询条件，去掉无意义的查询条件和影响系统正常运行的特殊字符；
(2)在索引文件中找到含有关键字的记录索引，根据记录的文件指针确定记录所在数据块在存档文件中的位置及记录在其所在数据块中的位置；
(3)根据记录所在数据块在存档文件中的位置查找并解压缩相应数据块文档，进一步根据记录在数据块中的位置查询到完整的数据记录。
本发明的海量数据库记录的归档和查询方法具有以下优点：1)、可以满足对归档文件的压缩存储和高效查询的需要，归档记录的文件(索引文件+数据文件)的大小只有原始记录的1/2或者更少；记录在百万级别的时候，查询的响应时间也在毫秒级，大大高于数据库查询的速度；2)、归档文件和数据库完全独立，不对数据库系统的正常运行造成任何影响；3)、归档文件存放在文件系统中，很容易备份和恢复；方案稍加改良就可以实现对多个归档文件的联合查询。
附图说明
下面结合附图和具体实施方式对本发明作进一步详细说明。
图1是本发明的海量数据库记录的归档方法流程示意图；
图2是本发明的海量数据库记录的查询方法和数据库查询性能对比。
具体实施方式
本发明的海量数据库记录的归档方法，如图1所示，根据不同的需求执行不同的处理方式，基本步骤如下：
1、在数据库中获取一个需要归档的表中的记录，将该表中的记录进行分组，分组可以是将所述海量数据库记录按照每组固定记录数量的方式进行分组，例如图1所示为M条记录归为一组。实际操作中，满足归档性能的条件下可以经过试验确定M的最佳取值，如果每条被归档记录的大小比较平均可以以一个固定值M对海量数据库记录分组，如果记录的大小差异比较大，也可以按照每组数据大小为定值对海量数据库记录分组。
2、对分组后的各组记录建立索引文件。
2.1、对每条记录需要查询的每个字段建立相应的倒排索引(InvertedIndex)。
2.2、对需要支持模糊查询或全文搜索的字段，对该字段的文本进行分词(这里的模糊查询不同于SQL语句的like查询；表示的是，不输入完整的句子也能够查询到结果，但英文单词必须是完整的。如输入“北京”能够查询到“北京2008”的结果，但输入“Bei”是查询不到“Beijing2008”)。
2.3、同一个表中需要归档的记录建立一个索引文件，对该表分组后，对各组中的每条记录分别建立索引，如图1中当前记录分词后包括k个字段，分别对字段i、i+1、…、i+k建立索引，在索引文件中，不同的字段对应了不同的域(Field，域是存储索引数据的结构)，同一个字段的索引属于同一个域中；如图1中所示，字段i的索引信息是放在索引文件中字段i的域中。
建立索引时，还要将具体每一条记录在数据文件中的确切位置作为记录的文件指针，写入索引文件中；记录的文件指针只保留在索引文件中，不进行索引。如图1所示，记录的文件指针包括：包含当前记录的压缩块在数据文件中的位置(压缩块POS)，记录压缩块的压缩前后大小(压缩块SIZE)，记录在压缩块中的序号(记录SN)。
3、对建立好索引文件的一组记录进行数据压缩后归档，同样同一个表的记录写入同一个归档文件，如图1所示，将M条记录作为一组进行压缩，压缩以后作为一个整体的数据块写入归档数据文件中。
当记录中存在时间和IP地址等可以转换为数字类型的数据记录时，可以将其转换为数字数据后再压缩归档，这样处理能够节省存储空间且便于后续的查询。
4、将一个表中的各组记录归档处理后，判断若数据库中是否还有未归档的表，是则返回步骤(1)，直至将数据库中所有需要归档的记录全部归档。当一个归档文件保留的记录数量达到一定数量或者超过一定时间以后，可以建立新的索引文件和数据文件，提高数据的安全性。
本发明对海量数据库记录的归档文件的查询，其基本步骤如下：
1、解析用户输入的查询条件，去掉无意义的查询条件和影响系统正常运行的特殊字符。
2、在索引文件中找到含有关键字的记录索引，根据记录的文件指针确定记录所在数据块在存档文件中的位置及记录在其所在数据块中的位置，确定应在哪个归档文件进行查询或需要在哪些归档文件中同时查询。
对于模糊查询，将用户的输入进行分词，将分词后的结果到对应字段的索引中进行查询。
如果需要在多个字段中进行查询，确定各个查询字段之间的关系，然后将各个字段的查询结果进行与或非的逻辑筛选。查询条件包含时间和IP地址类型的数据时，先将时间和IP地址类型的查询条件转换成数字数据类型，并根据数字数据范围确定查询区域的范围。
对于需要排序的字段，按照排序条件，将查询到的索引结果排序。
如果在索引中命中查询条件，返回命中的结果的总数量count，并返回前面N条记录的文件指针信息。
3、根据记录所在数据块在存档文件中的位置查找并解压缩相应数据块文档，进一步根据记录在数据块中的位置查询到完整的数据记录。
根据记录的文件指针信息，在数据文件中查询到记录的全部信息，返回给用户或者第三方系统。
下面分别对本发明上述归档方法和查询方法采取的一些主要技术做一个简要的说明。
一、倒排索引和分词
一般的索引结构建立的是一种“文档到单词”的映射关系，而倒排索引建立的则是一种“单词到文档”的映射关系。因为在日常的检索中，通常都是按照关键字进行搜索的，所以，倒排索引可以更好地适合这种检索机制的需要。目前搜索引擎广泛采用倒排索引来进行关键词的索引
分词就是提取关键词的一个过程，将自然语言切分出一个一个的关键词，供建立倒排索引的时候采用。英文是以词为单位的，词和词之间是靠空格隔开，而中文是以字为单位，句子中所有的字连起来才能描述一个意思，因此对英文的分词和中文的分词有很显著的区别。目前对中文的分词有很多研究和具体的成果，并且也有很多开源的分词器可以供使用，现有的分词算法可分为三大类：基于字符串匹配的分词方法、基于理解的分词方法和基于统计的分词方法。在这里，将本发明具体采用的方案做一个说明。
假设数据库里面记录1的description字段存储的数据是“I loveBeijing 2008 Olympic Games！Welcome to Beijing.”记录2的description字段存储的数据是“She once lived in Beijing.”
首先进行分词处理，因为是英文，所以分词按照空格分隔，去掉无实际意义的词语，示例中的“to”，其他的如a，an，the，in，on等。然后根据需要决定是否在查询的时候输入Welcome和welcome都能查询到结果，如果需要这样的查询，把所有的单词都转换为大写。为了支持输入Games和Game都能查询到结果，将单词都还原为基本形式，将Games还原为game，去掉所有的标点符号。
经过上面的处理，记录1的所有关键词为：[i][love][beijing][2008][olympic][game][welcome][beijing]；记录2的所有关键词为：[she][live][beijing]。
根据关键词，建立倒排索引。记录1和2经过倒排以后，变成如下表一所示的倒排结构：
表一

关键词 2008 beijing game i live love she olympic welcome 记录号 1 1，2 1 1 2 1 2 1 1

加上出现位置和出现频率后，索引结构变成如下表二所示的倒排结果：
表二
关键词 2008 beijing game i live love she olympic welcome [记录号]频率 [1]1 [1]2，[2]1 [1]1 [1]1 [2]1 [1]1 [2]1 [1]1 [1]1 位置 4 3/8，2 6 1 2 2 1 5 7

beijing在记录1中出现了2次，记录2中出现了一次，它的出现位置为“3/8，2”。结合文章号和出现频率，记录1中出现了2次，那么“3/8”就表示beijing在记录1中出现的两个位置，记录2中出现了一次，剩下的“2”就表示beijing是记录2中第2个关键字。关键字是按字符顺序排列的，因此可以用二分搜索算法快速定位关键词。
对于中文，目前采用最简单的分词方法，即按照字进行拆分，“我爱2008北京奥运会”将会被切分为[我][爱][2008][北][京][奥][运][会]，建立倒排索引的过程同第7和第8步。这种分词方式保证输入“奥运”也能检索到这条记录，同时实现简单，缺点是分词以后关键词数量比较多，形成的索引文件相对要大一些。但对于处理数据库记录的归档，因为数据库记录的数据一般都是比较简单的字词组成的，重复的数值或者数据比较多，因此也不会存在关键词词典数量非常庞大的情况。同时分词器是一个可以替换的，如果有新的需求，可以马上修改或替换。
对于时间数据，这个在数据库中非常常见，并且数据库存储的格式也是多种多样的，常见的“2008-08-08 18:00:00”，“20008/08/08 18:00:00”等。在查询的时候，一般都是查询在某个时间区间范围的数据，因此需要比较在两个时间点之间的范围。但是直接对数据库存储的时间进行比较是低效的，因为是字符串比较，归档文件里面有上百万记录的时候，时间开销比较大。因此把时间统一转换成整数类型，一种方式是转换成从1970年以来的毫秒值，另外是直接去掉数字之间的符号保存为“20080808180000”。第一种方式是不能处理1970年以前的时间数据，后面一种方式需要把时间全部格式化成相同的数值位数，不足的地方要补0。
对于不同的字段，在倒排索引中对应不同的域Field。域有三个重要的属性：是否存储，是否索引和是否分词。是否存储表示改字段的数据是否完整存储到索引中；是否索引标识是否要对该域的内容提供索引功能；是否分词表示改字段的记录是否要用分词器进行分词处理，不需要模糊查询的字段是不需要分词的。每个字段对应不同的域，可以满足不同数据的需要，如记录中的课程名字段一般不需要分词，描述字段一般需要分词；同时可以对多个字段同时进行联合查询，实现SQL语句“SELECT filed0FROM tableName WHERE filed1＝value1 AND file2！＝value2 OR filed3LIKE‘％value3％‘”的效果。上述SQL语句转换为在域上的查询可以描述为，在域0上查询所有满足域1的值为value1，域2的值不等于value2，或者域3中的值包含value3的所有结果。域0必须是存储的和索引的；域1和域2必须是索引的，可以为分词的，也可以不为分词的；域3必须是索引的和分词的。同样可以实现按照某个域排序、某个域的多条件查询或者过滤等其他高级功能。
建立索引的时候，是先在内存中做缓存，达到一定数量以后，一并写入文件。索引中记录需要删除的时候，将需要删除的记录做一标识，在调用删除方法的时候，同一删除，提高效率。
二、记录的索引和压缩存储
从数据库中根据条件，查询出需要归档的记录。
需要预处理的数据，如时间日期格式，做预处理；过滤掉一些可能引起后续操作错误，并且无实际意义的特殊字符，如“＜”、“#”、“~”，“`”等。
根据归档记录的查询需要确定记录各个字段的索引，存储和分词方式，需要分词的字段用分词器进行分词。
判断写入哪个具体的归档文件，或者创建新的归档文件。
分批压缩原始的数据库记录，每次压缩M条记录，作为一个文件块写入数据文件，如图1所示。记录的文件指针包括包含当前记录的压缩块在数据文件中的位置(压缩块POS)，记录压缩块的压缩前后大小(压缩块SIZE)，记录在压缩块中的序号(记录SN)。对不同的数据，采取不同的压缩方式，文本数据采用无损压缩方式，如各种zip压缩，已经压缩过的数据如jpg图片等，可以不压缩或者有损压缩。记录分组压缩存储的好处有，每个压缩块都比较小，需要读写的时候，解压缩代价很小；由于数据库相邻的记录一般都有一定的相关性，相关的记录都存储在同一个或者几个压缩块里面；分组压缩同时也能够保证较大的压缩率(文本能够达到4-10倍的压缩率)，节省存储空间。
将预处理并压缩存储过的记录依次写入索引中相应的域，为了保证索引的一致性，写入的时候加写锁，只允许查询和读取索引记录，不允许其他进程或程序执行写操作；将当前记录的文件指针写入单独的一个域中，这个域不索引，只存储。
记录加入数据文件和索引以后，从数据库中删除。
三、归档记录的查询
首先解析用户的查询请求，对用户的输入做预处理，转换日期格式和去掉特殊字符。然后需要模糊查询的列，用分词器进行分词，和建立索引的时候采用同一个分词器。再根据用户的查询请求，确定查询的具体归档文件。
查询条件中有时间区间的查询，如类似这样的SQL语句查询“field1＞＝‘2008-06-18 18:00:00’AND filed1＜＝‘2008-08-08 18:00:00’”，转换为在对应的域上比较值是否在[2008061818000000，20080808180000]区间上，如果在，将这条记录在索引中的标志位值设为1，后续查询只在标志位值为1的索引上进行。
同一个域需要多条件查询，按照逻辑关系组合查询条件。多个域上需要多条件查询，也按照逻辑关系组合查询条件。将前面2种查询条件组合在一起，为了不对查询性能造成过大的影响，对查询条件的最大数量做限定。
将上面的查询条件传递到查询分析器，先在一个域上完成逻辑查询，将查询结果和下一个域的结果进行逻辑比较，直到所有的查询条件执行完成，返回查询到的结果的数量count和前N条记录的文件指针，并缓存这N条记录的索引信息，供二次查询和排序等使用。
查询的时候，由于索引的时候是按照字母顺序排序，用二分搜索算法快速定位关键词，一般一次查询在毫秒级别完成。
需要对某个域上进行排序，类似SQL语句的ORDER BY关键字，那么是将前面的命中结果进行排序；一般排序只在不分词的域上进行，对已分词的域上进行排序意义不大；同时排序时间复杂度和空间复杂度都比较高，没有特殊需要，对于大量的归档数据一般不采用排序操作。排序也需要比较两个值的大小，为了使得排序速度加快，能够转换成数值类型的数据，在建立索引的时候全部转换成数值，如IP地址，时间等。
举例说明读取记录的过程，如果根据需要显示的结果数量S，从查询结果中取得这S条记录的文件指针，处在同一压缩记录块的记录分为一组，这S条记录分成n组；依次从数据文件中读取相应的压缩块，并解压这n个压缩块，根据各条记录对应的文件指针的参数，即记录在数据块中的位置SN，从其对应的压缩块中取出所需要的那条记录。
如果有排序操作，需要对从数据文件取得的这N条记录再次排序。为了读取快速从数据文件中读取压缩记录，读取时候的分组破坏了从索引中返回结果的排序顺序，因此需要二次排序。不过这样的排序量一般都很小，因此速度很快。
将结果通过Web界面或者其他图形界面返回给用户，包括查询命中的总量，前N条记录的详细信息；如果有需要，也可以将结果反馈给第三方系统。
下面对本技术方案的一个具体实验及其数据和结果做一些说明。
硬件环境：Dell Vostro 1400笔记本T5470 1.6G/2G RAM/120G5400RPM HDD。
软件环境：数据库PostgreSQL 8.2，操作系统Microsoft WindowsVista Ultimate。
执行归档记录的速度：平均1000条记录＜2秒。
归档记录采用Zlib压缩算法，对每100条记录作为一个压缩块，平均压缩率在6∶1到7∶1之间。
索引的时候，在内存中缓存索引数量为100条，超过100条写入磁盘。
归档432，438条记录的大小：索引文件60.6MB，数据文件28.0MB，共88.6MB；在数据库中的大小为165.6MB，归档文件的大小为数据库文件大小的1/2。索引文件比数据文件大是因为索引文件的压缩比数据文件低很多。
查询条件内容如下表三所示，表中包括各查询条件所对应的SQL查询语句。Q1到Q5查询的数据量以432，438条记录为基准，即数据库表中和归档文件中的记录数量和内容是一致的，均为432，438条记录，查询条件也保持一致；记录保存在一个归档文件中。对需要条件比较的字段，数据库建立B树索引，每个查询做5次，取平均数值做最后的结果，数据库查询包括一次SELECT COUNT(*)操作用于结果数量和SELECT*操作用于查询前100条记录的具体内容。
表三
查询编号查询内容 Q1 查询满足单一条件的结果数量和前100条记录的详细信息 (SQL：field1＝？limit 100) Q2 查询满足多个查询条件的结果数量和前100条记录的详细信息 (SQL：filed1＝？AND field2＝？limit 100) Q3 查询某一字段上包含某个值的结果数量和前100条记录的详细信息 (SQL：field1 like‘％value％’) Q4 查询满足单一条件的结果的数量和前100条记录的详细信息，并按另外一个条件对结果排序 (SQL：field1＝？ORDER BY field2 limit 100) Q5 查询满足多个查询条件的结果数量和前100条记录的详细信息，并按其中一个条件进行排序 (SQL：field1＝？AND field2＝？ORDER BY field2 limit 100) Q6 选择数据是时间的某一字段，查询在某一时间区间内，满足另一条件的结果数量和前100条记录的详细信息，并按另外一个条件对结果排序 (SQL：field1＝？AND field2 BETWEEN‘value1’AND‘value2’ORDER BY field3 limit 100)

图2为本发明的海量数据库记录的查询方法和数据库查询性能对比，可以看出本发明从归档文件中查询的速度比数据库查询快2-10倍，特别是复杂查询的时候，归档文件查询比数据库查询快很多。数据库进行排序操作的时候，性能恶化非常明显，从Q4查询比Q5查询慢主要是因为排序量差别的原因；但由于在索引的时候，对归档文件的排序做了优化，因此对归档文件的排序效果要好很多。将记录的数量上升到百万级别，执行数据库查询，复杂查询时间会超过20秒或者更多，性能下降很严重；但在归档文件中查询，复杂查询时间不超过2秒，对不需要排序的查询，查询时间通常在在300ms左右。因此本方案能够很好的满足海量记录的归档和归档后的查询。