一种海量数据加载和查询的方法

1.一种海量数据的加载方法，其步骤如下：
1)解析程序模块按照时间顺序生成目录，产生文件，生成数据源；
2)用临时表缓存各个连续时间段的数据，得到各分区段的数据；
3)将上述各分区段的数据统一建立索引；
4)加载程序模块调用数据转移接口，将数据转移到分区表。
2.如权利要求1所述的一种海量数据的加载方法，其特征在于所述步骤2)中的各个连续时间段的长度相同。
3.如权利要求1所述的一种海量数据的加载方法，其特征在于在步骤4)后增加如下步骤；对分区表中的数据进行合并，按照新的时间单位生成大的分区业务表。
4.一种海量数据的查询方法，其步骤如下：
I)采用如权利要求1所述的方法加载数据；
II)将分区表中的数据合并成大的分区业务表；
III)数据库对临时表和分区表进行查询。
5.如权利要求4所述的一种海量数据的查询方法，其特征在于步骤I)中的加载数据中各个连续时间段的长度相同。
6.如权利要求4所述的一种海量数据的查询方法，其特征在于步骤III)中的数据库进行的查询为：数据库根据调用时间条件判断查询是在临时表还是在分区表，并判断在哪些临时表和哪些分区表，当查询时间段出现在临时表时，即调用临时表查询接口；当查询时间段出现在分区表时，即调用分区表查询接口，然后将两个结果集进行联合。

技术领域\n本发明属于计算机领域，具体涉及一种海量数据加载和查询的方法。\n背景技术\n随着企业信息化以及互联网的飞速发展，海量数据处理已经成为重中之重，特别是电信行业和互联网行业更是如此，必须使用一些特殊的方法来处理海量数据。基于此本发明提出一种能够快速加载海量数据，同时可查询的方法。\n通常情况下，提高查询速度的方法是建立索引，以空间来换时间。这对小批量的数据影响不大或者说感觉不到。但当数据量非常大的时候，该矛盾就比较明显，严重影响加载速度。当然，如果采用较好的硬件一定会有很大的改善，如使用巨型机比使用DELL 2850的速度快很多。现有技术中，数据加载的同时也建立索引，那么随着加载数据量增加，加载速度越来越小，原因是各个关系数据库随着数量的增加，索引的存储结构在不断地加大，而当插入一条数据的时候都需要维护这些索引，故造成加载速度在不断地下降。此外，加载是为查询服务，也就是说加载和查询要综合考虑，基于本文的加载方法，形成综合缓存数据和分区表数据同时查询的方法，完全与常用的单表查询方法不同。\n发明内容\n本发明是在相当的性价比的基础上，即都使用DELL 2850来寻找一个最优的方案。使用合适粒度的临时表缓存各个时间段的数据，在临时表上不建立索引，缓存完各自时间段的数据后，再将该时间段的数据统一建立索引后转移到分区表中。这样查询就分成两个部分联合查询：一种是缓存在临时表中的数据，一种是分区表的数据。\n本发明公开一种海量数据的加载方法，其步骤如下：\n1)解析程序模块按照时间顺序生成目录，产生文件，生成数据源；\n2)用临时表缓存各个连续时间段的数据，得到各分区段的数据；\n3)将上述各分区段的数据统一建立索引；\n4)加载程序模块调用数据转移接口，将数据转移到分区表。\n上述步骤2)中的各个连续时间段的长度相同。\n进一步，在步骤4)后增加如下步骤；对分区表中的数据进行合并，按照新的时间单位生成大的分区业务表。\n本发明还公开了一种海量数据的查询方法，其步骤如下：\n1)采用如权利要求1所述的方法加载数据；\n2)将分区表中的数据合并成大的分区业务表；\n3)数据库对临时表和分区表进行查询。\n本发明的海量数据查询是在数据加载的基础上进行的，在分布式海量数据处理产品中，加载和查询同时使用，可解决遇到的加载难题。\n本发明的优点和积极效果如下：\n1.使用本发明，原来在标准DELL 2850服务器上每秒只能加载500条左右(每条记录大概平均0.4K左右，一共有27个字段，11个索引)提高到每秒加载5000条左右，在保持当天数据查询速度的基础上使历史数据的查询速度也有所提高，原因是对分区表的数据按照业务需求进行合并，以供后期的查询使用。\n2.本发明基本不受时间和加载的总流量的限制，只与缓存时间段内的数据量有关系，但与总体数据量没有任何关系，因此可以满足高速海量数据加载以及有相关查询的业务需求。\n附图说明\n图1本发明的数据源生成方法示意图；\n图2本发明的加载方法操作图；\n图3本发明的分区段合并示意图；\n图4本发明的查询流程图。\n具体实施方式\n本实施例使用关系数据库oracle 10g来实现，其它关系数据库同样适用；操作系统采用RedFlag DC 5.0；硬件环境采用DELL 2850标准服务器，具体配置如表1所示，根据业务需求在该表上建立索引。此外，为了保证数据的合法性，需要在临时表上建立一个主键索引；在上述条件下对直接入普通表与直接入临时表加建立索引加转移数据方案对比产生的加载效果如表2所示，同时对已经积累的1亿条数据按照给出一个已知条件进行查询比较如表3所示。从表中数据可以看出在查询速度比较稳定的基础上，加载速度增加10倍左右。\n表1 Dell2850配置的结构表\n  项目   描述   处理器   Intel(R)Xeon(TM)CPU 2.80GHz*2   内存   4G   硬盘   SCSI硬盘，7200rpm，146G*4，做成raid5\n表2加载效果比较表\n  项目   单位   普通表   临时表+分区表   入库记录   条   1421567   1421567   入库时间   秒   2844   184\n  项目   单位   普通表   临时表+分区表   建立索引时间   秒   0   79.3   转移时间   秒   0   2.4   入库速度   条/秒   500   5345\n表3查询效果比较表\n  查询时间(天)   普通表(秒)  临时表+分区表(秒)   命中数据条数(条)   1   8  10   597   2   10  9   1349   30   16  14   6324\n本方法要求按照时间先后顺序生成目录，本实施例在对应的目录中按照时间先后顺序产生bcp文件，其生成的文件大小支持记录条数或时间超时两种配置，当任何条件触发的时候都可以生成文件，以此来作为加载的数据源。本实施例使用的数据源是解析程序模块，主要是对互联网协议数据进行实时还原解析，并生成待处理的加载文件，以5分钟生成的文件做为一个文件夹，该文件夹以整点5分钟的时间整数来命名，而且此实施方法的5分钟支持可配置。数据源的生成方法如图1所示。\n数据加载方式采用oracle OCI的Direct Path方式，加载程序模块按照时间目录先后来处理加载文件。本实施例中以1个小时为单位，1个小时是可以根据需求自行配置的，当缓存1个小时的数据后，加载程序模块再调用建立索引的接口，统一建立11个索引，完成建立索引后加载程序模块再调用数据转移接口，即将数据转移到分区表中。具体的操作流程图见图2。\n为了提高查询性能，对缓存分割的分区段进行合并，本实施例将每个小时产生的缓存时间段的数据，合并成按照天来保存的时间段数据，也就是说将每个小时分区段数据合并成每天的分区段数据，从而形成以一天为单位的大的分区业务表。合并是选择在业务量较小的每天晚上12:20触发并检验是否符合当天缓存数据全部交换至对应的分区表的分区。实际中的调用时间设置可以根据需要进行定制。合并流程如图3所示。\n本发明的整个查询方法流程如图4所示，当业务触发查询条件的时候，通过业务程序将调用分布式中间件，中间件再传给oracle数据库，数据库根据调用时间条件判断查询是在临时表还是在分区表，并判断在哪些临时表和哪些分区表，判断的依据就是根据记录表与查询时间段的关系，该记录表记录哪些数据在分布表，哪些数据在临时表。也就是说，当查询时间段包含临时表时间段，就按照给定的时间段来查询临时表，即调用临时表查询接口；当查询时间段包含分区表时间段，就按照给定的时间段来查询分区表，即调用分区表查询接口，然后将两个结果集进行联合。缓存表查询由于数据量小进行全表扫描或按照主键索引扫描，而分区表有索引以及分区设计，保证了查询准确性和快速性。\n尽管为说明目的公开了本发明的具体实施例和附图，其目的在于帮助理解本发明的内容并据以实施，但是本领域的技术人员可以理解：在不脱离本发明及所附的权利要求的精神和范围内，各种替换、变化和修改都是可能的。本发明不应局限于本说明书最佳实施例和附图所公开的内容，本发明要求保护的范围以权利要求书界定的范围为准。