CN106383830A - 一种数据检索方法及设备 - Google Patents
一种数据检索方法及设备 Download PDFInfo
- Publication number
- CN106383830A CN106383830A CN201610713239.2A CN201610713239A CN106383830A CN 106383830 A CN106383830 A CN 106383830A CN 201610713239 A CN201610713239 A CN 201610713239A CN 106383830 A CN106383830 A CN 106383830A
- Authority
- CN
- China
- Prior art keywords
- querying condition
- data
- time
- field
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
- G06F16/2468—Fuzzy queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24564—Applying rules; Deductive queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
- G06F16/2477—Temporal data queries
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Mathematical Physics (AREA)
- Software Systems (AREA)
- Computational Linguistics (AREA)
- Data Mining & Analysis (AREA)
- Fuzzy Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Probability & Statistics with Applications (AREA)
- Automation & Control Theory (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种数据检索方法,该方法通过在获取到源数据之后将源数据分服务构建索引,当用户下发的查询条件符合预设策略时,将原查询条件中的时间字段进行修改之后生成新的查询条件,根据新的查询条件中确定所要查询的服务,并确定与查询结果对应的待返回的索引数据,根据待返回的索引数据与源数据之间的对应关系将源数据返回给用户。通过分服务构建索引减少了查询时遍历数据量,为多线程并行查询提供了基础;通过改进查询条件缩小了查询的范围,有效提升数据检索的效率。
Description
技术领域
本发明涉及视频监控技术领域,尤其涉及一种数据检索方法。本发明同时还涉及一种数据检索设备。
背景技术
智能交通系统(Intelligent Transportation System,简称ITS)是未来交通系统的发展方向,它是将先进的信息技术、数据通讯传输技术、电子传感技术、控制技术及计算机技术等有效地集成运用于整个地面交通管理系统而建立的一种在大范围内、全方位发挥作用的,实时、准确、高效的综合交通运输管理系统。随着智能交通行业的飞速发展,前端相机每日可采集千万条的过车数据,日积月累,当数据量达到千亿级别时,后台需要开发一种性能较优的数据存储、索引及查询的方法及系统。由于智能交通行业的特殊性,对查询的实时性和精确性要求极高。虽然随着互联网大数据的飞速发展,开源技术的不断更新,并逐步走向成熟。但是,面对千亿级别的大数据时,仅仅依赖于大数据开源技术是无法实现目标的。考虑到硬件级别、业务需求和开发技术等多方面因素,实现千亿数据秒级查询是一项非常严峻的挑战。
目前,大多数搜索引擎采用了倒排索引,比普通数据库索引与查询更高效、功能更强大。同时,搜索引擎在数据容灾、负载均衡、数据迁移以及扩容等方面都很成熟。但是,对于千亿级别的数据量,在存储、索引和查询等方面困难重重,申请人发现现有技术在具体应用过程中存在如下问题:
(1)在构建索引方面,单机索引数据量上限较小,大约20亿;索引数据段的大小与查询性能成反比,索引数据段的数量与查询性能也成反比;当索引段较大时,定时合并索引段的时间较长,合并过程中还容易引起环境不稳定、奔溃,甚至数据丢失等严重的问题;
(2)在数据查询方面,首先,当数据量较大时,数据索引段较多,查询时需要串行遍历更多的段,性能较差。其次,查询的结果集较大时,由于要查询的是千亿级别的数据量,较大的查询结果集会降低排序的效率,进而也会影响查询性能。
因此,如何在面对查询对象是千亿级别的数据量时,提供一种快速、高效的检索方法成为了本领域技术人员亟待解决的问题。
发明内容
有鉴于背景技术中存在的问题,本发明实施例提供了一种数据检索方法,通过对查询条件设定规则以及按照预设策略更新原查询条件的方式,极大地提升了面对千亿级数据量时的数据检索速度,从而提升了检索效率。
为了达到上述目的,本发明提供了一种数据检索方法,该方法包括:
接收用户下发的查询条件,当所述查询条件符合预设规则时,根据所述查询条件及其对应的数据密度生成新的查询条件,所述数据密度为单位时间内所述查询条件包括的查询字段对应查询结果的平均数;
根据所述新的查询条件中的时间字段查询服务,确定待返回的索引数据,所述服务为包括各个根据时间顺序排列的索引数据的集合;
根据索引数据与源数据之间的对应关系,将所述待返回的索引数据对应的源数据返回所述用户。
优选的,所述预设规则具体包括:
查询条件中仅包含时间字段;或,
查询条件中包括时间字段以及精确查询字段;或
查询条件中包括时间字段以及模糊查询字段;
当用户下发的查询条件符合所述预设规则中的任一项时,根据所述查询条件及其对应的数据密度生成新的查询条件。
优选的,根据所述查询条件及其对应的数据密度生成新的查询条件,具体为:
确定所述查询条件需要返回的查询结果数;
根据所述查询结果数和所述数据密度确定修改时间;
根据所述修改时间修改所述查询条件中的时间字段,使修改后的时间段包含于修改前的时间段之内;
将修改后的时间字段加入到原查询条件中生成所述新的查询条件。
优选的,所述方法还包括:
每隔预设周期更新各个查询字段对应的数据密度;
分别获取各个查询字段对应的第一数据密度及所述第一数据密度的更新时间T;
在当前系统时间与所述更新时间T的差值为预设周期时,统计从所述更新时间T至所述当前系统时间之间的时间范围内所述查询字段对应的第二数据密度;
将所述第一数据密度与所述第二数据密度的平均值作为所述查询字段在预设周期后更新的数据密度;
当接收到用户下发的查询条件时,获取所述查询条件包括的查询字段对应的数据密度;
其中,所述查询字段为单个检索字段和/或多个检索字段的组合。
优选的,所述方法还包括:
当获取到源数据时,遍历当前系统环境下所有处于正常状态的服务,对所述源数据进行构建索引操作;
若当前系统环境下只存在一个处于正常状态的服务,将所述源数据直接发送至该服务中进行构建索引并将生成的索引数据存储在该服务中;
若当前系统环境下存在多个处于正常状态的服务,将所述源数据发送至满足预设条件的服务中进行构建索引并将生成的索引数据存储在所述满足预设条件的服务中;
根据所述源数据和生成的索引数据确定索引数据与源数据之间的对应关系。
相应的,本申请同时还提出了一种数据检索设备,所述设备包括:
生成模块:接收用户下发的查询条件,当所述查询条件符合预设规则时,根据所述查询条件及其对应的数据密度生成新的查询条件,所述数据密度为单位时间内所述查询条件包括的查询字段对应查询结果的平均数;
确定模块:根据所述新的查询条件中的时间字段查询服务,确定待返回的索引数据,所述服务为包括各个根据时间顺序排列的索引数据的集合;
返回模块:根据索引数据与源数据之间的对应关系,将所述待返回的索引数据对应的源数据返回所述用户。
优选的,所述预设规则具体包括:
查询条件中仅包含时间字段;或,
查询条件中包括时间字段以及精确查询字段;或
查询条件中包括时间字段以及模糊查询字段;
当用户下发的查询条件符合所述预设规则中的任一项时,根据所述查询条件及其对应的数据密度生成新的查询条件。
优选的,所述生成模块具体用于:
确定所述查询条件需要返回的查询结果数;
根据所述查询结果数和所述数据密度确定修改时间;
根据所述修改时间修改所述查询条件中的时间字段,使修改后的时间段包含于修改前的时间段之内;
将修改后的时间字段加入到原查询条件中生成所述新的查询条件。
优选的,所述设备还包括:
更新模块:每隔预设周期更新各个查询字段对应的数据密度;
分别获取各个查询字段对应的第一数据密度及所述第一数据密度的更新时间T;
在当前系统时间与所述更新时间T的差值为预设周期时,统计从所述更新时间T至所述当前系统时间之间的时间范围内所述查询字段对应的第二数据密度;
将所述第一数据密度与所述第二数据密度的平均值作为所述查询字段在预设周期后更新的数据密度;
当接收到用户下发的查询条件时,获取所述查询条件包括的查询字段对应的数据密度;
其中,所述查询字段为单个检索字段和/或多个检索字段的组合。
优选的,所述设备还包括:
索引构建模块:当获取到源数据时,遍历当前系统环境下所有处于正常状态的服务,对所述源数据进行构建索引操作;
若当前系统环境下只存在一个处于正常状态的服务,将所述源数据直接发送至该服务中进行构建索引并将生成的索引数据存储在该服务中;
若当前系统环境下存在多个处于正常状态的服务,将所述源数据发送至满足预设条件的服务中进行构建索引并将生成的索引数据存储在所述满足预设条件的服务中;
根据所述源数据和生成的索引数据确定索引数据与源数据之间的对应关系。
与现有技术相比,本申请实施例所提出的技术方案的有益技术效果包括:
本申请实施例公开了一种数据检索方法,该方法通过在获取到源数据之后将源数据分服务构建索引,当用户下发的查询条件符合预设策略时,将原查询条件中的时间字段进行修改之后生成新的查询条件,根据新的查询条件中确定所要查询的服务,并确定与查询结果对应的待返回的索引数据,根据待返回的索引数据与源数据之间的对应关系将源数据返回给用户。通过分服务构建索引减少了查询时遍历数据量,为多线程并行查询提供了基础;通过改进查询条件缩小了查询的范围,有效提升数据检索的效率。
附图说明
图1为本申请实施例提出的一种数据检索方法流程示意图;
图2为本申请具体实施例中一种快速车辆检索方法的流程示意图;
图3为具体的应用场景中,对处理后的数据进行构建索引及存储的方法流程示意图;
图4为本申请实施例提出的一种数据检索设备的结构示意图。
具体实施方式
有鉴于现有技术中存在的问题,本发明实施例提供了一种数据检索方法,通过分服务构建索引的方式减少了查询时遍历的数据量,为多线程并行查询提供了基础,提升了查询性能,通过修改查询条件中的时间字段来更新查询条件缩小了查询范围,有效提升了数据检索的速度以及检索效率。
如图1所示,为本申请实施例提出的一种数据检索方法流程示意图,所述方法包括以下步骤:
步骤101:接收用户下发的查询条件,当所述查询条件符合预设规则时,根据所述查询条件及其对应的数据密度生成新的查询条件。
由于在现有技术中,当接收到用户下发的查询条件时,会根据查询条件中的时间条件遍历大量的索引数据,但是当用户按照某种规则只想返回大量索引中一部分索引数据对应的源数据时,通过现有技术的方案很容易造成时间上的浪费导致检索效率降低,因此有必要对于一些符合预设规则的查询条件进行改进并生成新的查询条件来提升检索效率。
在本申请优选实施例中,当接收到用户下发的查询条件时,会首先判断查询条件中包含的查询字段是否符合如下的预设规则:
1)、查询条件中仅包含时间字段;或,
2)、查询条件中包括时间字段以及精确查询字段;或
3)、查询条件中包括时间字段以及模糊查询字段;
其中,精确的查询字段对应的查询结果是一类结果,例如:当前的查询条件想要查询“车牌颜色为蓝色”的车辆信息,则“车牌颜色为蓝色”就是该查询条件对应查询字段的一个精确的检索字段,根据这个查询字段返回的查询结果其车牌颜色全为蓝色,换句话说,只要是车牌颜色为蓝色的车辆都会落入查询范围内,所以该查询字段为精确查询字段。同时,一个精确查询字段还可以包括多个精确的检索字段,例如:当前的查询条件想要查询的是“车牌颜色为蓝色的白色轿车”的车辆信息,则该查询条件对应的查询字段包含两个检索字段,分别是“车牌颜色为蓝色”和“白色轿车”,其中“车牌颜色为蓝色”对应的查询结果为一类结果,“白色轿车”对应的查询结果也是一类结果,所以二者均为精确的检索字段,那么同时包含二者的查询字段为精确查询字段。需要说明的是,精确查询字段中的检索字段不包括精确的车牌。如果查询字段包含的检索字段为精确的车牌字段的话,那么最终的查询结果是唯一的一个结果而不是一类结果,这样的话就有悖于通过查询条件筛选出符合条件的一类或几类查询结果的目的。
模糊查询字段为对应几种或者几类不确定查询结果的查询字段,其最终的查询结果是包含有几类相关结果的查询结果,并不是一类精确的查询结果,其中,模糊查询字段包含的模糊检索字段为模糊的车牌字段。例如:当前查询条件想要查询“车牌号为浙AXXXX”的车辆信息,其查询字段包含的检索字段为“车牌号为浙AXXXX”,那么最终查询出来的结果就是车牌号为与“浙A”相关的车辆信息,返回的查询结果中因为只包含了车辆的归属地信息,像车牌颜色、车辆类型、车辆颜色等信息都是不确定的,该查询字段对应的查询结果是不确定的,也就是模糊的,所以该查询字段也就是一个模糊的查询字段。
(1)、当查询条件符合预设规则中的任一项时,根据查询条件及其对应的数据密度生成新的查询条件,在本申请优选实施例中生成新的查询条件的步骤如下:
a、确定查询条件需要返回的查询结果数;
b、根据查询结果数和数据密度确定修改时间;
c、根据修改时间修改查询条件中的时间字段,使修改后的时间段包含于修改前的时间段之内;
d、将修改后的时间字段加入到原查询条件中生成所述新的查询条件。
通过对原查询条件中的时间条件进行紧缩修改生成新的查询条件,减少了查询条件覆盖的时间范围,从而在得到查询结果的过程中减少了需要遍历的数据;其次,由于新的查询条件对应的时间是原查询条件对应时间的子集,其对应的查询结果也要少于原查询条件对应的查询结果,提升了对于查询结果的排序速度,提高了查询效率。
其中,数据密度为单位时间内查询条件包括的查询字段对应查询结果的平均数。由于数据密度不是实时获取的,所以需要每隔一个预设周期对数据密度进行更新。当根据数据密度生成新的查询条件时,获取到的数据密度为最近一次更新过的数据密度。例如,查询条件下发的时间是7:30,数据密度更新的时间是每个整点时刻,那么获取的数据密度就应该是7:00整更新的数据密度,具体的数据密度更新方法如下:
a、每隔预设周期更新各个查询字段对应的数据密度;
b、分别获取各个查询字段对应的第一数据密度及第一数据密度的更新时间T;
c、在当前系统时间与更新时间T的差值为预设周期时,统计从更新时间T至当前系统时间之间的时间范围内查询字段对应的第二数据密度;
d、将第一数据密度与第二数据密度的平均值作为查询字段在预设周期后更新的数据密度;
e、当接收到用户下发的查询条件时,获取查询条件包括的查询字段对应的数据密度;
其中,查询字段为单个检索字段和/或多个检索字段的组合。需要说明的是,检索字段是构成查询字段的一个查询因子,一个查询字段可以同时包含一个或多个检索字段。但是数据密度是对应于查询字段的,一个相同的查询字段在一个数据密度更新周期内对应一个数据密度,与该查询字段包含的检索字段数量的多少无关。
(2)、当用户下发的查询条件不符合预设规则时,即查询条件同时包含模糊查询字段以及其他查询字段时,需要根据具体的数据总数以及实际的使用情况限定查询条件对应的时间跨度。例如:当前的查询条件对应的查询字段包括:模糊查询字段(即模糊的车牌字段)以及精确查询字段(如车身颜色为白色),若当前数据总量为千亿级别的数据量时,限定最佳的时间跨度为3天。当然,这里只是简单的举个例子,并不影响本申请方案的保护范围。在具体的应用场景中,具体限定的时间跨度是本领域技术人员根据实际的使用情况来设置的。
步骤102:根据所述新的查询条件中的时间字段查询服务确定待返回的索引数据。
由于将源数据通过分服务的方式构建了索引数据,所以在进行数据检索时首先要确定服务,然后在服务中确定对应查询条件的索引数据,最后根据索引数据来找到源数据,从而提高了数据检索的效率。
在本申请优选实施例中,首先根据生成的新的查询条件中的时间字段确定新的查询条件对应查询的时间区间,其次根据服务对应的时间区间确定服务对应的时间区间与新的查询条件对应的时间区间二者之间的交集,从而确定新的查询条件对应要查询的服务。其中,服务为初始数据容量固定,对应于各个顺序排列的时间段的索引数据集合,索引数据为将源数据通过构建索引操作生成的。例如:单个服务的索引数据存储量等于初始数据容量为200M,从7:00开始存入第一条索引数据为20K,之后会根据实时获取到的源数据情况在该服务中存入索引数据,若在7:30的时候该服务存储的索引数据大小达到初始的数据容量时,则将创建一个新的服务,将7:30之后获取到的源数据在新的服务中进行构建索引操作,新的服务对应的存储量等于初始的数据容量同样为200M以此类推。需要注意的是,服务与服务之间的索引数据的存储量相等,等于初始数据容量,但是服务与服务之间对应的时间长度可以不同,例如:第一个服务对应的时间区间可以是7:00-7:30,第二个服务对应的时间区间则有可能是7:31-8:10。也就是说,服务的初始数据容量都是固定的,但是不同服务对应的时间区间可能不同。
其中,将获取到的源数据进行构建索引的具体步骤如下:
a、当获取到源数据时,遍历当前系统环境下所有处于正常状态的服务,对源数据进行构建索引操作;
b、若当前系统环境下只存在一个处于正常状态的服务,将源数据直接发送至该服务中进行构建索引并将生成的索引数据存储在该服务中;
c、若当前系统环境下存在多个处于正常状态的服务,将源数据发送至满足预设条件的服务中进行构建索引并将生成的索引数据存储在满足预设条件的服务中;
d、根据源数据和生成的索引数据确定索引数据与源数据之间的对应关系。
其中,在当前系统环境中只有一个服务时,无论获取到的源数据是对应于当前时刻的实时获取到的数据,还是对应于之前时刻的补漏数据,都直接将获取到的源数据传入该服务进行构建索引及存储。
在当前系统环境中有多个服务时,由于获取到的源数据可以是对应于当前时刻的实时获取的数据,也可以是对应于之前时刻的补漏数据,所以会有以下两种情况出现:
1、如果获取到的源数据是实时获取的数据,则判断获取到的源数据对应的索引数据的大小是否超过了当前服务(即当前时刻对应的服务)可容纳的数据的大小。其中,每个服务的初始数据容量固定,若当前服务存储的数据容量达到初始数据容量时,系统将从当前时间开始向后顺序创建新的服务,创建的新的服务的数据容量大小等于初始数据容量,因此会有如下两种情况:
1)、如果获取到的源数据对应的索引数据的大小小于当前服务可容纳的大小,则将获取到的源数据传入当前服务进行索引数据的构建。
2)、如果获取到的源数据对应的索引数据的大小大于当前服务可容纳的大小,则创建新的服务,并将获取到的源数据传入新的服务中进行索引数据的构建。
2、如果获取到的源数据是补漏数据,则将获取到的源数据的时间与当前服务中数据最大时间比较,若该条数据的时间小于当前服务中数据最大时间,且大于前一个服务中数据的最大时间,则该条数据属于当前服务;反之,将前一个服务作为当前服务,继续将获取到的源数据的时间与当前服务中数据最大时间比较,直到找到该条补漏数据的归属服务,然后,对数据进行构建索引及存储;其中在有多个服务存在的情况下,服务与对应服务中数据的最大时间是一致有序的,在本申请优选实施例中,服务是有序单链表中的一个节点,而服务中数据的最大时间是该节点的数据值,一致有序是指后驱节点的数据值总是大于前驱节点的数据值。
需要注意的是,在将获取到的补漏数据在已有的服务中进行索引构建时,服务的容量上限可以动态进行配置,以使所述补漏数据对应的索引数据可以存储在其归属服务中。
步骤103:根据索引数据与源数据之间的对应关系,将所述待返回的索引数据对应的源数据返回所述用户。
在本申请优选实施例中,根据查询条件在服务中得出对应于新的查询条件的查询结果,需要说明的是,因为服务是索引数据的集合,所以查询结果也是对应于源数据的索引数据。在得到索引数据之后,根据索引数据与源数据之间的对应关系,将源数据返回给用户端结束查询。
与现有技术相比,本申请实施例所提出的技术方案的有益技术效果包括:
本申请实施例公开了一种数据检索方法,该方法通过在获取到源数据之后将源数据分服务构建索引,当用户下发的查询条件符合预设策略时,将原查询条件中的时间字段进行修改之后生成新的查询条件,根据新的查询条件中确定所要查询的服务,并确定与查询结果对应的待返回的索引数据,根据待返回的索引数据与源数据之间的对应关系将源数据返回给用户。通过分服务构建索引减少了查询时遍历数据量,为多线程并行查询提供了基础;通过改进查询条件缩小了查询的范围,有效提升数据检索的效率。
需要说明的是,所描述的实施例是本申请的一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
为了使本领域技术人员更好地理解本发明实施例提供的技术方案,下面结合具体应用场景对本发明实施例提供的技术方案进行描述。
如图2所示,为本申请具体实施例中一种快速车辆检索方法的流程示意图,所述方法具体包括:
步骤201:解析用户查询条件。
在本申请优选实施例中,在接收到用户下发的查询条件后,解析查询条件中包含的查询字段,其中时间条件是必须条件。
步骤202:判断是否符合自定义的查询条件约束规则(预设规则)。
在本申请优选实施例中,在通过解析客户下发的查询条件后,获取其中的查询字段,判断查询条件是否符合自定义的查询条件约束规则,如果符合,则利用改进的时间紧缩算法将初始的查询条件转换成新的查询条件;否则,则不对其进行时间紧缩;由于千亿数据规模较大及结合实际使用情况,所以在本具体实施例中仅对部分一到三个检索字段的组合条件进行了密度统计,自定义的查询条件约束规则具体如下:
a)用户下发的查询条件中除时间值之外,不包含其它字段值;即除了默认字段值之外,没有输入其它条件;
b)在a)不成立的条件下,当且仅当输入一个新的检索字段值,且该检索字段不是车牌字段;
c)在a)不成立的条件下,当且仅当输入一个新的检索字段值,且该检索字段是车牌字段,且该字段值不是精确的车牌值;
d)在a)不成立的条件下,当且仅当输入两个或三个除车牌之外的精确检索字段值;
e)在a),b),c),d)中任意一个成立的条件下,执行步骤204;
f)在a)、b)、c)、d)都不成立的条件下,执行步骤203。
步骤203:限定查询的最大时间范围。
在本申请优选实施例中,结合数据总数及实际使用情况,当数据量达到千亿时,限定查询的最佳时间跨度为3天,在限定查询最大时间跨度后跳过步骤204,执行步骤205。
步骤204:通过改进的时间紧缩算法生成新的查询条件。
在本申请优选实施例中,通过改进的时间缩紧算法生成新的查询条件遵循如下流程:
(1)离线统计查询字段对应的数据密度,并保存数据密度的值,其中,所述数据密度为单位时间里某个或某些组合检索字段值查询结果的平均条数;
如果查询字段只包含单个的检索字段,例如:检索字段是车身颜色,颜色可能有黑、白、蓝、红等,多次随机查询单位时间里黑、白、蓝、红的结果条数,最后计算所有结果的平均值,该值即为车身颜色的数据密度;
如果查询字段包括某些组合检索字段,例如:检索字段是车身颜色和车牌颜色,颜色可能有黑、白、蓝、红等,多次随机查询单位时间里黑白、蓝白、红黑组合条件的结果条数,最后计算所有结果的平均值,该值即为车身颜色和车牌颜色组合的数据密度;
(2)定期统计单个或某些组合检索字段对应的查询字段的数据密度并更新存储,使其数据密度更接近当前真实值;在本申请优选实施例中,查询某个或某些组合检索字段对应的查询结果时,查询的时间范围是上一次更新时间到当前时间,将重新计算出来的数据密度与上一次更新的的数据密度取均值,并将该平均值作为该查询条件对应查询字段的新的数据密度;
(3)解析用户下发的查询条件中需要返回的查询结果数(客户端页面显示的条数),计算查询时间长度;
计算方法:
其中,timeLength表示时间长度,returnNum表示用户实际需要返回的查询结果数目,ρ表示数据密度。为了保证查询结果数大于等于用户实际需要返回的结果数,所以(a)式中的分子需要乘以一个大于1的权重,建议值为1.5;
(4)通过(3)中计算出来的时间长度修改原查询条件中的时间,生成时间紧缩后的查询条件;在本申请优选实施例中,解析用户下发条件中的排序字段,如果按照时间降序,则修改查询的起始时间,起始时间等于结束时间减去(3)中的时间长度;如果按照时间升序,则修改查询的结束时间,结束时间等于起始时间加上(3)中的时间长度;其中,默认的排序条件为时间降序;
(5)通过对时间条件的紧缩,首先,减少了查询所需遍历的数据量;其次,减少了查询结果集,提升了查询结果的排序速度。
步骤205:解析新查询条件中的时间段。
在本申请优选实施例中,在根据时间紧缩算法生成新的查询条件之后,获取新的查询条件中的时间字段,进而获取到新的查询条件所要查询的时间段。
步骤206:与服务中的时间取交集,确定需要查询的服务并查询。
在本申请优选实施例中,将获取到的新的查询条件中的时间字段与服务对应的时间区间进行比较,确定二者时间重叠的部分即二者对应时间段的交集,因为每个服务对应于一个时间区间,通过判断二者之间时间段的交集落在哪个时间区间内,即可确定新的查询条件所要查询的服务。
其中,所述的服务是指包含部分索引数据以及能够提供独立查询功能且有独立属性的集合。所以,通过查询条件在服务中查询的数据均为索引数据,具体的构建索引流程如下:
(1)通过前端卡口相机或者爬取工具获取数据源;
(2)通过负载均衡技术将数据流分发到不同的服务器;
(3)每台服务器在对数据构建索引之前批量清理其中可能存在的垃圾数据;
(4)如图3所示,为对处理后的数据进行构建索引及存储的方法流程示意图,该方法包括:
步骤301:判断是否只有一个服务。
在本申请优选实施例中,遍历系统环境中所有正常的服务。如果判断结果为是,则执行步骤302;如果判断结果为否,则跳过步骤302,执行步骤303。
步骤302:无需判断时间,直接构建索引。
在本申请优选实施例中,在当前系统环境中只有一个服务时,无论获取到的源数据是对应于当前时刻的实时获取到的数据,还是对应于之前时刻的补漏数据,都直接将获取到的源数据传入该服务进行构建索引及存储。
步骤303:取出所有的服务,并从当前服务开始,按时间由近及远的顺序从时间最近的服务向时间最远的服务遍历,并继续执行步骤304.
步骤304:判断在所有数据中是否是符合条件的第一个服务,若判断结果为是则执行步骤305,否则执行步骤306。
在本申请优选实施例中,在当前系统环境中有多个服务时,由于获取到的源数据可以是对应于当前时刻的实时获取的数据,也可以是对应于之前时刻的补漏数据,所以会有以下两种情况出现:
1、如果获取到的源数据是实时获取的数据,则判断获取到的源数据对应的索引数据的大小是否超过了当前服务可容纳的数据的大小。其中,每个服务的初始数据容量固定,若当前服务存储的数据容量达到初始数据容量时,系统将从当前时间开始向后顺序创建新的服务,创建的新的服务的数据容量大小等于初始数据容量,因此会有如下两种情况:
1)、如果获取到的源数据对应的索引数据的大小小于当前服务可容纳的大小,则将获取到的源数据传入当前服务进行索引数据的构建。
2)、如果获取到的源数据对应的索引数据的大小大于当前服务可容纳的大小,则创建新的服务,并将获取到的源数据传入新的服务中进行索引数据的构建。
2、如果获取到的源数据是补漏数据,则将获取到的源数据的时间与当前服务中数据最大时间比较,若该条数据的时间小于当前服务中数据最大时间,且大于前一个服务中数据的最大时间,则该条数据属于当前服务;反之,将前一个服务作为当前服务,继续将获取到的源数据的时间与当前服务中数据最大时间比较,直到找到该条补漏数据的归属服务,然后,对数据进行构建索引及存储;其中在有多个服务存在的情况下,服务与对应服务中数据的最大时间是一致有序的,在本申请优选实施例中,服务是有序单链表中的一个节点,而服务中数据的最大时间是该节点的数据值,一致有序是指后驱节点的数据值总是大于前驱节点的数据值。
需要注意的是,在将获取到的补漏数据在已有的服务中进行索引构建时,服务的容量上限可以动态进行配置,以使所述补漏数据对应的索引数据可以存储在所述服务中。
步骤305:打入数据或者继续往前遍历。
步骤306:数据打入这个服务。
在本申请优选实施例中实施例中,通过现有技术构建索引的性能测试结果如下表1所示:
服务器数(台) | 数据总量(亿条) | 总耗时(分) | 平均速度(条/秒) |
1 | 10 | 650 | 25641 |
3 | 30 | 1352 | 36982 |
6 | 60 | 1491 | 67069 |
10 | 100 | 2368 | 70382 |
表1
在应用了本申请实施例提出的方案后,构建索引的性能测试结果如下表2所示:
服务器数(台) | 数据总量(亿条) | 总耗时(分) | 平均速度(条/秒) |
1 | 50 | 3160 | 26371 |
3 | 150 | 6867 | 36405 |
6 | 300 | 7611 | 65694 |
20 | 1000 | 10183 | 163671 |
表2
说明:a)单条数据大小大约78Byte。
(5)如果有补漏数据,同理(4);
(6)单个服务中数据容量的上限动态可配置,当单个服务中的数据总量达到上限时,系统自动建立新的服务,新的数据流传新的服务中;同时,系统自动将前一个服务中的所有索引段合并成一个索引段以提高查询性能;返回(3)。
1)、单个服务中的索引数据量最优值:
2)、环境中最优服务数:
其中,1)中的x表示每条数据的大小,单位是Byte;2)中的collectionNum表示服务的数量,replicationNum表示数据备份数,totalNum表示整个系统中数据总量,serverNum表示服务器的数量,dataNumPerCollection表示每个服务中的数据量。
步骤207:处理查询结果集,并排序。
在本申请优选实施例中,将对应新的查询条件的查询结果整理并进行排序,需要注意的是查询结果对应于服务中的索引数据,并不是用户想要查询的源数据。
步骤208:根据确定的索引数据取出完整的结果集返回并进行动态缓存。
在本申请优选实施例中,根据查询结果确定的索引数据,由于索引数据与源数据之间存在对应关系,因此,根据索引数据与源数据之间的对应关系查找到源数据,将源数据返回给用户并将查询结果对应的源数据进行动态缓存。
在本申请优选实施例中实施例中,通过现有技术对于百亿级数据进行查询的测试结果如下表3所示:
表3
在应用本申请实施例所提出的方案后,对于千亿级数据进行查询的测试结果如下表4所示:
表4
说明:a)数据:大约1.06亿/天。
本申请实施例所提出的技术方案,首先通过对数据流进行批量分服务构建索引,提升了单机数据量上限并且分服务减小了单个索引段的大小,从而减小了查询时遍历的数据量,提高了查询的性能;同时,通过解析用户下发的查询条件,根据约束规则及改进的时间紧缩算法缩短查询时间长度,再通过多线程对多服务的并行查询方式,可以同时返回查询结果、查询总数和查询时间,有效提升了查询效率。
需要说明的是,所描述的实施例是本申请的一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
为更清楚地说明本申请前述实施例提供的方案,基于与上述方法同样的发明构思,本申请实施例还提出了一种数据检索设备,其结构示意图如图4所示,所述检索设备具体包括:
生成模块410:接收用户下发的查询条件,当所述查询条件符合预设规则时,根据所述查询条件及其对应的数据密度生成新的查询条件,所述数据密度为单位时间内所述查询条件包括的查询字段对应查询结果的平均数;
确定模块420:根据所述新的查询条件中的时间字段查询服务,确定待返回的索引数据,所述服务为包括各个根据时间顺序排列的索引数据的集合;
返回模块430:根据索引数据与源数据之间的对应关系,将所述待返回的索引数据对应的源数据返回所述用户。
在具体的应用场景中,所述预设规则具体包括:
查询条件中仅包含时间字段;或,
查询条件中包括时间字段以及精确查询字段;或
查询条件中包括时间字段以及模糊查询字段;
当用户下发的查询条件符合所述预设规则中的任一项时,根据所述查询条件及其对应的数据密度生成新的查询条件。
在具体的应用场景中,所述生成模块410具体用于:
确定所述查询条件需要返回的查询结果数;
根据所述查询结果数和所述数据密度确定修改时间;
根据所述修改时间修改所述查询条件中的时间字段,使修改后的时间段包含于修改前的时间段之内;
将修改后的时间字段加入到原查询条件中生成所述新的查询条件。
在具体的应用场景中,所述设备还包括:
更新模块440:每隔预设周期更新各个查询字段对应的数据密度;
分别获取各个查询字段对应的第一数据密度及所述第一数据密度的更新时间T;
在当前系统时间与所述更新时间T的差值为预设周期时,统计从所述更新时间T至所述当前系统时间之间的时间范围内所述查询字段对应的第二数据密度;
将所述第一数据密度与所述第二数据密度的平均值作为所述查询字段在预设周期后更新的数据密度;
当接收到用户下发的查询条件时,获取所述查询条件包括的查询字段对应的数据密度;
其中,所述查询字段为单个检索字段和/或多个检索字段的组合。
在具体的应用场景中,所述设备还包括:
索引构建模块450:当获取到源数据时,遍历当前系统环境下所有处于正常状态的服务,对所述源数据进行构建索引操作;
若当前系统环境下只存在一个处于正常状态的服务,将所述源数据直接发送至该服务中进行构建索引并将生成的索引数据存储在该服务中;
若当前系统环境下存在多个处于正常状态的服务,将所述源数据发送至满足预设条件的服务中进行构建索引并将生成的索引数据存储在所述满足预设条件的服务中;
根据所述源数据和生成的索引数据确定索引数据与源数据之间的对应关系。
与现有技术相比,本申请实施例所提出的技术方案的有益技术效果包括:
本申请实施例公开了一种数据检索方法及设备,通过在获取到源数据之后将源数据分服务构建索引,当用户下发的查询条件符合预设策略时,将原查询条件中的时间字段进行修改之后生成新的查询条件,根据新的查询条件中确定所要查询的服务,并确定与查询结果对应的待返回的索引数据,根据待返回的索引数据与源数据之间的对应关系将源数据返回给用户。通过分服务构建索引减少了查询时遍历数据量,为多线程并行查询提供了基础;通过改进查询条件缩小了查询的范围,有效提升数据检索的效率。
需要说明的是,所描述的实施例是本申请的一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明可以通过硬件实现,也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解,本发明的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施场景所述的方法。
本领域技术人员可以理解附图只是一个优选实施场景的示意图,附图中的模块或流程并不一定是实施本发明所必须的。
本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中,也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明序号仅仅为了描述,不代表实施场景的优劣。
以上公开的仅为本发明的几个具体实施场景,但是,本发明并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明的保护范围。
Claims (10)
1.一种数据检索方法,其特征在于,该方法包括:
接收用户下发的查询条件,当所述查询条件符合预设规则时,根据所述查询条件及其对应的数据密度生成新的查询条件,所述数据密度为单位时间内所述查询条件包括的查询字段对应查询结果的平均数;
根据所述新的查询条件中的时间字段查询服务确定待返回的索引数据,所述服务为包括各个根据时间顺序排列的索引数据的集合;
根据索引数据与源数据之间的对应关系,将所述待返回的索引数据对应的源数据返回所述用户。
2.如权利要求1所述的方法,其特征在于,所述预设规则具体包括:
查询条件中仅包含时间字段;或
查询条件中包括时间字段以及精确查询字段;或
查询条件中包括时间字段以及模糊查询字段;
当用户下发的查询条件符合所述预设规则中的任一项时,根据所述查询条件及其对应的数据密度生成新的查询条件。
3.如权利要求1或2所述的方法,其特征在于,根据所述查询条件及其对应的数据密度生成新的查询条件,具体为:
确定所述查询条件需要返回的查询结果数;
根据所述查询结果数和所述数据密度确定修改时间;
根据所述修改时间修改所述查询条件中的时间字段,使修改后的时间段包含于修改前的时间段之内;
将修改后的时间字段加入到原查询条件中生成所述新的查询条件。
4.如权利要求3所述的方法,其特征在于,所述方法还包括:
每隔预设周期更新各个查询字段对应的数据密度;
分别获取各个查询字段对应的第一数据密度及所述第一数据密度的更新时间T;
在当前系统时间与所述更新时间T的差值为预设周期时,统计从所述更新时间T至所述当前系统时间之间的时间范围内所述查询字段对应的第二数据密度;
将所述第一数据密度与所述第二数据密度的平均值作为所述查询字段在预设周期后更新的数据密度;
当接收到用户下发的查询条件时,获取所述查询条件包括的查询字段对应的数据密度;
其中,所述查询字段为单个检索字段和/或多个检索字段的组合。
5.如权利要求4所述的方法,其特征在于,所述方法还包括:
当获取到源数据时,遍历当前系统环境下所有处于正常状态的服务,对所述源数据进行构建索引操作;
若当前系统环境下只存在一个处于正常状态的服务,将所述源数据直接发送至该服务中进行构建索引并将生成的索引数据存储在该服务中;
若当前系统环境下存在多个处于正常状态的服务,将所述源数据发送至满足预设条件的服务中进行构建索引并将生成的索引数据存储在所述满足预设条件的服务中;
根据所述源数据和生成的索引数据确定索引数据与源数据之间的对应关系。
6.一种数据检索设备,其特征在于,所述设备包括:
生成模块:接收用户下发的查询条件,当所述查询条件符合预设规则时,根据所述查询条件及其对应的数据密度生成新的查询条件,所述数据密度为单位时间内所述查询条件包括的查询字段对应查询结果的平均数;
确定模块:根据所述新的查询条件中的时间字段查询服务,确定待返回的索引数据,所述服务为包括各个根据时间顺序排列的索引数据的集合;
返回模块:根据索引数据与源数据之间的对应关系,将所述待返回的索引数据对应的源数据返回所述用户。
7.如权利要求6所述的设备,其特征在于,所述预设规则具体包括:
查询条件中仅包含时间字段;或,
查询条件中包括时间字段以及精确查询字段;或
查询条件中包括时间字段以及模糊查询字段;
当用户下发的查询条件符合所述预设规则中的任一项时,根据所述查询条件及其对应的数据密度生成新的查询条件。
8.如权利要求6或7所述的设备,其特征在于,所述生成模块具体用于:
确定所述查询条件需要返回的查询结果数;
根据所述查询结果数和所述数据密度确定修改时间;
根据所述修改时间修改所述查询条件中的时间字段,使修改后的时间段包含于修改前的时间段之内;
将修改后的时间字段加入到原查询条件中生成所述新的查询条件。
9.如权利要求8所述的设备,其特征在于,所述设备还包括:
更新模块:每隔预设周期更新各个查询字段对应的数据密度;
分别获取各个查询字段对应的第一数据密度及所述第一数据密度的更新时间T;
在当前系统时间与所述更新时间T的差值为预设周期时,统计从所述更新时间T至所述当前系统时间之间的时间范围内所述查询字段对应的第二数据密度;
将所述第一数据密度与所述第二数据密度的平均值作为所述查询字段在预设周期后更新的数据密度;
当接收到用户下发的查询条件时,获取所述查询条件包括的查询字段对应的数据密度;
其中,所述查询字段为单个检索字段和/或多个检索字段的组合。
10.如权利要求9所述的设备,其特征在于,所述设备还包括:
索引构建模块:当获取到源数据时,遍历当前系统环境下所有处于正常状态的服务,对所述源数据进行构建索引操作;
若当前系统环境下只存在一个处于正常状态的服务,将所述源数据直接发送至该服务中进行构建索引并将生成的索引数据存储在该服务中;
若当前系统环境下存在多个处于正常状态的服务,将所述源数据发送至满足预设条件的服务中进行构建索引并将生成的索引数据存储在所述满足预设条件的服务中;
根据所述源数据和生成的索引数据确定索引数据与源数据之间的对应关系。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610713239.2A CN106383830B (zh) | 2016-08-23 | 2016-08-23 | 一种数据检索方法及设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610713239.2A CN106383830B (zh) | 2016-08-23 | 2016-08-23 | 一种数据检索方法及设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN106383830A true CN106383830A (zh) | 2017-02-08 |
CN106383830B CN106383830B (zh) | 2020-07-28 |
Family
ID=57916934
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610713239.2A Active CN106383830B (zh) | 2016-08-23 | 2016-08-23 | 一种数据检索方法及设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN106383830B (zh) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108664481A (zh) * | 2017-03-27 | 2018-10-16 | 中国移动通信集团内蒙古有限公司 | 一种数据检索方法及服务器 |
CN109858639A (zh) * | 2019-01-17 | 2019-06-07 | 上海易点时空网络有限公司 | 车辆召回信息查询系统、查询方法及计算机可读存储介质 |
CN109961632A (zh) * | 2017-12-26 | 2019-07-02 | 浙江宇视科技有限公司 | 一种以路由的方式快速查询过车记录的方法及装置 |
CN109960695A (zh) * | 2019-04-09 | 2019-07-02 | 苏州浪潮智能科技有限公司 | 云计算系统中数据库的管理方法和装置 |
CN112486979A (zh) * | 2019-09-12 | 2021-03-12 | 阿里巴巴集团控股有限公司 | 数据处理方法、装置和系统、电子设备以及计算机可读存储介质 |
CN116737172A (zh) * | 2023-08-11 | 2023-09-12 | 杭州初灵信息技术股份有限公司 | 一种小颗粒数据包的解析系统和方法 |
CN117688013A (zh) * | 2024-02-01 | 2024-03-12 | 北方健康医疗大数据科技有限公司 | 一种基于缓存索引的主索引生成方法、装置、设备及介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102486775A (zh) * | 2010-12-01 | 2012-06-06 | 金蝶软件(中国)有限公司 | 业务数据的查询方法及装置 |
CN103440249A (zh) * | 2013-07-23 | 2013-12-11 | 南京烽火星空通信发展有限公司 | 一种非结构化数据快速检索的系统及方法 |
CN103970853A (zh) * | 2014-05-05 | 2014-08-06 | 浙江宇视科技有限公司 | 优化搜索引擎的方法及装置 |
CN105159971A (zh) * | 2015-08-26 | 2015-12-16 | 成都布林特信息技术有限公司 | 一种云平台数据检索方法 |
-
2016
- 2016-08-23 CN CN201610713239.2A patent/CN106383830B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102486775A (zh) * | 2010-12-01 | 2012-06-06 | 金蝶软件(中国)有限公司 | 业务数据的查询方法及装置 |
CN103440249A (zh) * | 2013-07-23 | 2013-12-11 | 南京烽火星空通信发展有限公司 | 一种非结构化数据快速检索的系统及方法 |
CN103970853A (zh) * | 2014-05-05 | 2014-08-06 | 浙江宇视科技有限公司 | 优化搜索引擎的方法及装置 |
CN105159971A (zh) * | 2015-08-26 | 2015-12-16 | 成都布林特信息技术有限公司 | 一种云平台数据检索方法 |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108664481A (zh) * | 2017-03-27 | 2018-10-16 | 中国移动通信集团内蒙古有限公司 | 一种数据检索方法及服务器 |
CN108664481B (zh) * | 2017-03-27 | 2021-03-23 | 中国移动通信集团内蒙古有限公司 | 一种数据检索方法及服务器 |
CN109961632A (zh) * | 2017-12-26 | 2019-07-02 | 浙江宇视科技有限公司 | 一种以路由的方式快速查询过车记录的方法及装置 |
CN109858639A (zh) * | 2019-01-17 | 2019-06-07 | 上海易点时空网络有限公司 | 车辆召回信息查询系统、查询方法及计算机可读存储介质 |
CN109960695A (zh) * | 2019-04-09 | 2019-07-02 | 苏州浪潮智能科技有限公司 | 云计算系统中数据库的管理方法和装置 |
CN109960695B (zh) * | 2019-04-09 | 2020-03-13 | 苏州浪潮智能科技有限公司 | 云计算系统中数据库的管理方法和装置 |
CN112486979A (zh) * | 2019-09-12 | 2021-03-12 | 阿里巴巴集团控股有限公司 | 数据处理方法、装置和系统、电子设备以及计算机可读存储介质 |
CN112486979B (zh) * | 2019-09-12 | 2023-12-22 | 阿里巴巴集团控股有限公司 | 数据处理方法、装置和系统、电子设备以及计算机可读存储介质 |
CN116737172A (zh) * | 2023-08-11 | 2023-09-12 | 杭州初灵信息技术股份有限公司 | 一种小颗粒数据包的解析系统和方法 |
CN116737172B (zh) * | 2023-08-11 | 2023-12-12 | 杭州初灵信息技术股份有限公司 | 一种小颗粒数据包的解析系统和方法 |
CN117688013A (zh) * | 2024-02-01 | 2024-03-12 | 北方健康医疗大数据科技有限公司 | 一种基于缓存索引的主索引生成方法、装置、设备及介质 |
CN117688013B (zh) * | 2024-02-01 | 2024-04-30 | 北方健康医疗大数据科技有限公司 | 一种基于缓存索引的主索引生成方法、装置、设备及介质 |
Also Published As
Publication number | Publication date |
---|---|
CN106383830B (zh) | 2020-07-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106383830A (zh) | 一种数据检索方法及设备 | |
US10394813B2 (en) | Method and apparatus for performing query aware partitioning | |
US7877376B2 (en) | Supporting aggregate expressions in query rewrite | |
CA2317081C (en) | Estimation of column cardinality in a partitioned relational database | |
CN104737162B (zh) | 用于大规模集群中的分析型查询处理的自动反规范化 | |
US8610605B2 (en) | Method and system for data compression | |
US9665572B2 (en) | Optimal data representation and auxiliary structures for in-memory database query processing | |
US11176131B2 (en) | Parallel processing of queries with inverse distribution function | |
US20090063441A1 (en) | System and method of query transformation | |
CN102298650B (zh) | 一种海量数字信息的分布式推荐方法 | |
CN106844405A (zh) | 数据查询方法和装置 | |
CN106777093A (zh) | 基于空间时序数据流应用的Skyline查询系统 | |
CN106897280A (zh) | 数据查询方法及装置 | |
US10180960B2 (en) | Query processing | |
CN104462443B (zh) | 数据处理方法和装置 | |
CN104392001A (zh) | 数据库查询方法和装置 | |
CN103209328A (zh) | 多源卫星图像实时在线处理技术方法及装置 | |
CN107391749B (zh) | 一种查询分表数据实现瀑布流的方法 | |
CN108228654A (zh) | 一种大数据分布式存储方法和系统 | |
CN110765319A (zh) | 一种提高Janusgraph路径探索性能的方法 | |
WO2022267183A1 (zh) | 预计算模型的评分方法、装置、设备和存储介质 | |
CN109962956B (zh) | 用于向用户推荐通信业务的方法和系统 | |
CN115114289A (zh) | 一种数据查询方法、装置及电子设备 | |
CN114138828A (zh) | 数据连接方法、装置、电子设备、存储介质及程序产品 | |
CN112965825A (zh) | 一种面向负载均衡的动态均衡分区方法及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |