CN102214176A - 超大维表的切分与表连接方法 - Google Patents
超大维表的切分与表连接方法 Download PDFInfo
- Publication number
- CN102214176A CN102214176A CN2010101427190A CN201010142719A CN102214176A CN 102214176 A CN102214176 A CN 102214176A CN 2010101427190 A CN2010101427190 A CN 2010101427190A CN 201010142719 A CN201010142719 A CN 201010142719A CN 102214176 A CN102214176 A CN 102214176A
- Authority
- CN
- China
- Prior art keywords
- dimension table
- dimension
- super large
- sublist
- data
- 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
Images
Abstract
本发明提供一种超大维表的切分方法,包括:从所述超大维表的各个表项中提取一层次的维的一个属性值以及与该属性值所对应的连接键的值域范围;将所述层次的维中的所有属性值以及与各个属性值相对应的连接键的值域范围保存在一子表中;重复上述步骤,直到将所述超大维表中所有层次的维的信息保存到对应子表中。本发明还提供了一种超大维表连接方法。本发明通过压缩维表,然后在表连接时将合适的压缩后子表调入维表内存,由于子表较原有维表的更小,因此可以常驻内存,避免大量不必要的磁盘I/O操作。
Description
技术领域
本发明涉及数据库领域及数据分析领域,特别涉及一种超大维表的切分与表连接方法。
背景技术
数据处理是计算机研究领域的一个重要方向。根据数据的存在形态,数据处理分为对静态数据的处理和对动态数据(即数据流)的处理。静态数据处理以数据为中心,整个数据集存储在一个庞大的、相对稳定的中央存储介质中,并随时准备接受随机到来的用户数据请求(即“查询”)。在数据集的生命周期内,绝大部分数据是稳定不变的,而频繁变化的是用户随时可能提交的查询。数据库管理系统、信息检索系统、数据仓库系统等多种应用中都采用了静态数据处理的处理方式。但在某些应用中,如互联网管理系统、证券交易系统、电信系统、金融交易系统,数据本身具有高度流动性,而用户查询则相对稳定,这就使得这些应用的数据处理不再是对静态数据的处理,而是对动态数据的处理。在对动态数据进行处理时,由于所要处理的对象是在线的、持续的高速数据流,且因为存储空间的限制,所接收到的数据不可能完全保存到存储器中,同时又必须不间断、无延迟地处理这些数据流,以获得实时处理结果,因此,对静态数据的处理方式并不适合在动态数据处理过程中使用,动态数据处理需要采用新的数据结构与计算方法。
传统的关系型数据库系统主要面向基本的、日常的事务处理,如银行的交易事务,因此也被称为联机事务处理系统(On-Line TransactionProcessing,简称OLTP),但对于如何利用已有的海量数据提取对企业决策分析有用的信息(即分析处理)的支持一直不能令人满意,因此,由关系数据库之父E.F.Codd于1993年提出了OLAP(联机分析处理,On-LineAnalytical Processing),OLAP是使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业维特性的信息进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。OLAP的目标是满足决策支持或者满足在多维环境下特定的查询和报表需求,它的技术核心是“维”这一概念,因此OLAP也可以说是多维数据分析工具的集合。与传统的关系型数据库中所采用的联机事务处理OLTP相比,OLAP主要应用在数据仓库系统中,它能够支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。
对数据流的处理与OLAP原本是两个相互独立的概念,但在实时数据多维分析领域中,如实时网络安全监控数据分析、实时银行交易记录分析,两者得到了紧密的结合。由于数据流本身具有快速变化、海量和潜在无限的特点,而在联机分析处理时又需要对数据做大量的操作,影响了数据流处理的实时性,因此,在现有技术中,本领域技术人员提出了采用数据流立方体(StreamCube)来提高查询速度,以克服数据流海量与实时性之间的矛盾。所述的数据流立方体是指对数据流数据建立的数据立方体(Cube),它由多个预定义的数据流聚集查询结果组成,而其中的数据立方体则是一种能快速分析数据的数据结构,它允许从多维对数据加以建模和观察。
在现有技术中,对数据流立方体的构建主要包括以下步骤:将所接收到的数据流与维表进行表连接;对表连接后的结果做聚集查询;存储聚集查询后的结果。在构建数据流立方体时之所以要将数据流与维表做表连接是因为数据流数据是单层次、单粒度的,通过数据流元组与维表连接可获取多层次、多粒度的详细属性信息。由于数据流表连接是构建数据流立方体的必要步骤,因此,提高数据流表连接效率将有助于提高数据流立方体的生成效率。
现有技术中存在多种数据流表连接方法,如哈希连接(Hash join)、嵌套循环连接(Nested-Loop Join)和排序合并连接(Sort-Merge join)。这些现有方法有各自的应用范围,但也存在各自的缺陷。如哈希连接方法在数据流系统的表连接中,驻入内存的表为维表,当维表大于内存限制时,需要反复地读取磁盘中维表的剩余数据,I/O开销过大。当数据流速率达到一定程度时,可能会使数据流中的数据未能及时连接处理而被丢弃,导致最终结果不正确,或只能得到近似的结果。维表的规模越大,这一问题越发突出。
发明内容
本发明的目的是克服现有的数据流表连接方法I/O开销大,实时性较差的缺点,从而提供一种超大维表连接方法。
为了实现上述目的,本发明提供了一种超大维表的切分方法,包括:
步骤1)、从所述超大维表的各个表项中提取一层次的维的一个属性值以及与该属性值所对应的连接键的值域范围;
步骤2)、将所述层次的维中的所有属性值以及与各个属性值相对应的连接键的值域范围保存在一子表中;
步骤3)、重复上述步骤,直到将所述超大维表中所有层次的维的信息保存到对应子表中。
上述技术方案中,在所述的步骤1)之前,还包括将所述超大维表的表项按连接键字段的值做排序的步骤。
上述技术方案中,所述排序按照连接键字段的值做升序排序。
本发明还提供了一种超大维表连接方法,包括:
步骤1)、采用所述的超大维表的切分方法将所述的超大维表按照维的层次分成多个子表,所述子表中包括所述超大维表中某一层次或某些层次的属性信息;
步骤2)、为压缩后所生成的子表建立索引;
步骤3)、在收到用户的查询请求后,根据所述索引调用相应的子表,实现数据流中数据的表连接。
上述技术方案中,所述的步骤3)包括:
步骤3-1)、数据流中的数据流元组根据用户的查询请求查询步骤2)所创建的索引,调用相应的子表,从所述子表中读取相应的属性字段;
步骤3-2)、将从各个维的子表中所读取的属性字段合并,得到连接结果。
上述技术方案中,在所述的步骤2)中,为所述子表所建立的索引为B+Tree索引、B-tree索引、二叉树索引中的一种。
本发明的优点在于:
本发明通过压缩维表,然后在表连接时将合适的压缩后子表调入维表内存,由于子表较原有维表的更小,因此可以常驻内存,避免大量不必要的磁盘I/O操作。
附图说明
图1为本发明的超大维表连接方法的流程图;
图2为数据流Eventlog的实例;
图3为图2所示数据流Eventlog的事实表与维表的示意图。
图4(a)为一个超大维表的示例图;
图4(b)-图4(d)为图4(a)所示超大维表经过切分后所得到的子表的示例图;
图5是为图4(b)中属性city的子表所建立的B+tree索引的示意图。
具体实施方式
在对本发明的具体实施方式做详细说明前,首先对本发明中所涉及的相关概念予以具体说明。
维(Dimension):人们观察数据的特定角度,是考虑问题时的一类属性,一类属性的集合构成一个维,如时间维、地理维等。
维的层次(Level):人们观察数据的某个特定角度(即某个维)还可以存在细节程度不同的各个描述方面,如在时间维中包括日期、月份、季度、年等多个层次。
维的成员(Member):维的一个取值,是数据项在某维中位置的描述。如“某年某月某日”是在时间维上位置的描述。
维表(Dimension Table):维在关系数据库中的表现形式,具体表示为一个数据表。
度量(measure):多维数组的取值,如(2000年1月,上海,笔记本电脑,销售额$100000)中的销售额。
事实表(Fact Table):包含度量和关联到维表的外键。
在对本发明中所涉及的相关概念做上述说明后,下面结合附图和具体实施方式对本发明加以说明。
通过对数据流表连接过程的分析可以知道,数据流表连接效率提高的主要障碍在于用于实现数据流处理的计算机系统本身资源的限制,此处所述的资源限制包括CPU处理能力的限制和内存容量的限制。CPU处理能力的限制是因为对于高速到达的数据流元组,CPU没有足够快的能力及时处理这些到达的元组。内存容量的限制是因为对于大量到达的数据流元组,计算机无法将这些元组都放入可用内存中。针对资源限制的上述特点,本发明提出了相应的表连接方法。
在对本发明方法的具体实现步骤做详细说明之前,首先对本发明中所涉及到的数据结构做相应的说明。
在背景技术中已经提到,表连接操作的对象包括数据流与维表。下面首先对数据流加以说明。
在实时数据多维分析领域中,数据流为数据查询提供了查询所需的所有信息。数据流的基本组成单位被称为数据流元组,同一类型的数据流元组中所包含的数据的类型基本相同。例如,在一个互联网管理系统所发出的数据流Eventlog中,各个数据流元组都包括ID、SrcIP、DstIP、EvenTypeID、InOutID属性,即标识、源地址、目的地址、事件类型标识、设备出入口标识。在图2中给出了数据流Eventlog的实例中,其中的每一行代表一个所述的数据流元组,可以用r[1]、r[2]、r[3]、r[4]分别表示其中的SrcIP、DstIP、EvenTypeID以及InOutID这四类属性。在数据流元组的各个属性中,一般都包含有内容丰富的信息。如果不对数据流元组中的信息做一定的加工处理,那么将很难从海量的动态变化的数据中快速找出用户所需要的数据。因此,在计算机系统接收到数据流信息后,需要对数据流中所包含的大量信息做一定的处理,以利于后续快速查找的实现。仍然以前面所提到的数据流Eventlog为例,由于SrcIP、DstIP、EvenTypeID、InOutID等属性中各自包含有内容丰富的信息,而且这些信息都各自从属于所在的类,因此在对数据流的处理过程中分别用SrcIPaddress、DstIPaddress、Event以及Inout四个维表来保存SrcIP、DstIP、EvenTypeID、InOutID四类属性的信息,而在事实表中则包含有关联到前述四个维表的外键。图3中给出了数据流Eventlog所生成的事实表以及维表的示意图。从图中可以看出,在各个维表中给出了各个维所包含的具体的属性信息。
以上是对数据流的说明,虽然在对数据流说明过程中提到了维表,但并不详细,作为表连接操作的另一个对象,为了便于理解,下面对维表的概念、内容做详细说明。
如前所述,维表是OLAP中用于表示同一类属性的集合的维在关系数据库中的表现形式。正如维表概念中所提到的,一张维表中所保存的是同一类属性,这些属性之间通常会存在层次关系。以前面所提到的数据流Eventlog中的SrcIP属性为例,一个SrcIP地址通常包含该IP地址所在市、省、国家的信息,显而易见,国家、省、市间按照区域大小具有层级关系,因此IP地址中市、省、国家等属性信息间存在层次关系。图4(a)给出了图3中所述SrcIP维表的一个实例,从该实例中可以看出,该维表包括IP、city、province和country等属性信息,且其中的city、province和country属性间具有层次关系。
从前面对数据流处理的说明过程中可以看出,数据流在经过处理后,其中的多数信息被保存在各个维表中,因此维表的规模必然会随着所接收数据流的增多而变大。从另一个角度看,维表的规模还与该维表中所含属性的层次数有关,对于一个维表,其中的属性的层次数越多,该维表的规模就越大。维表规模的变大使得将该维表调用到内存中时所要占据的内存空间变大。因此,有必要减小单个维表的规模,以避免由于内存容量有限所带来的维表重复调用问题。
要使得单独一个维表的规模变小且维表中原有信息不丢失的一种可能的实现方法是将原有维表进行切分,将原有维表中某一层次或某些层次的属性归到一个子表中,从而将原有维表分成多个由同层次的属性信息所组成的子表。作为一种优选实现方式,在将原有维表切分成子表的过程中,一个子表包括原有维表一个层次的属性信息。以图4(a)中所示的维表SrcIPaddress为例,对该维表的切分过程予以说明。图4(a)所示的维表包括有多个数据项,在各个数据项前包括有用于标识该数据项的ID号。每个数据项中包括有IP、city、province和country在内的多个属性,在前面已经提到,其中的属性city、province和country之间具有层次关系。因此,在切分过程中,首先,将维表按照连接键(连接键是指连接事实表和维表的码)的值做升序排序,并逐一读取。在关于IP地址的维表中,一般IP字段是该维表与事实表的连接键,因此也就是按照IP地址的值做升序排序。在图4(a)中已经将维表中的各个数据项按照IP地址的值做了升序排序。然后,从原有维表中计算某一层li的属性的值v1所对应的连接键的值域范围[start,end]。例如,从图4(a)可以看出,对于城市这一层中的属性city,值为C1的IP地址的范围是[1,8]。最后,将前文中所得到的li层的属性的值v1及[start,end]作为一个元组放入子表S中,重复上述操作,直到完成对原维表中所有数据项的处理。图4(a)所述的维表经过上述切分操作后得到图4(b)、图4(c)、图4(d)。如在图4(a)中,属性city的值为C1的项从IP值为1到IP值为8,因此在图4(b)中,属性city的值为C1的项的IP_Start值为1,IP_End的值为8;类似的,属性city的值为C2的项的IP_Start值为9,IP_End的值为12;属性city的值为C3的项的IP_Start值为13,IP_End的值为15;属性city的值为C4的项的IP_Start值为16,IP_End的值为19;属性city的值为C5的项的IP_Start值为20,IP_End的值为23;属性city的值为C6的项的IP_Start值为24,IP_End的值为29。
以上是对表连接操作中所涉及的数据结构的详细说明。从对上述说明中可以知道,如果能够将超大维表都按照上述方法予以切分,那么在表连接过程中可以按照数据查询的要求调用原超大维表的某一规模较小的子表,减小了维表反复调入调出内存的可能。下面对本发明方法的具体实现步骤予以说明。
步骤100)、首先,对维表进行切分,以得到多个规模更小的子表。在上文中已经对维表做切分的相关方法做了详细说明,所得到的子表中包含原有维表中某一层次或某些层次的属性信息。
步骤200)、其次,为压缩后所生成的各个子表建立索引。为压缩后的表所建立的索引可以有多种类型,如B+Tree索引、B-tree索引、二叉树索引等。以B+Tree树索引为例,在建立索引时,对每一个li层的压缩维表建立B+Tree索引。每条记录包含start、end两个字段值以及其他概念层次字段。k个概念层次的维表需要构建k个RB+Tree,以便于在表连接时装入内存。
图5是为图4(b)中属性city所对应的子表所建立的B+tree索引的示意图,在该图所示的B+tree索引中包含两类节点:内部结点和叶子节点。叶子结点为最后一层的结点,该节点用于存储元组数据。叶子节点以外的结点为内部结点,用于存放判断数值和指针。B+tree中每个节点内的对象个数M值是有用户设置的,图中设置为3,也就是每个节点最多3个最少2个对象。省略号表示在city子表中未出现但可能出现的元组。P1、P2、P3表示指针。通过索引,可以快速找到用户所需要查找的数据。
步骤300)、最后,在收到用户的查询请求后,根据前述步骤建立的索引实现表连接。
本领域技术人员应当了解,表连接操作与查询操作有密切的联系,通常在用户具有查询需求时,才需要做表连接操作,因此,在表连接之前首先要了解用户的查询请求是什么。用户所发出的查询请求中至少应当包括维信息、连接信息、工作层信息。其中,维信息用于描述查询中选择的维,连接信息用于描述连接数据流和维表的字段,工作层(Work Layer)是指Group-by聚集操作算子中所要查询的某个维di的最低层次l i 。例如,针对前文所提到的数据流Eventlog,有下列表示查询的SQL语句Q1:
Select SrcProvince,DstCountry,count(*)
From Eventlog e,SrcIPaddress ip1,DstIPaddress ip2
Where e.srcip=ip1.srcip,e.dstip=ip2.dstip
Group by SrcProvince,DstCountry
在上述SQL语句Q1中包括下列信息:数据流事实表Eventlog,维信息SrcIPaddress和DstIPaddress,连接信息e.srcip=ip1.srcip和e.dstip=ip2.dstip,度量信息count(*)及工作层信息SrcProvince、DstCountry。SrcProvince为SrcIPaddress维的工作层,DstCountry为DstIPaddress维的工作层。
针对上述查询语句,结合图3、图4中所示的相关表格,对表连接操作的实现过程予以详细说明。
步骤301)、根据查询请求,查询前一步骤所创建的索引树,获取相应维表中的属性字段。具体的说,在数据流DS的每一个元组r到达时,根据r在m个维中的连接属性值r[di](di代表第i维,1≤i≤m)分别查找rb[i,WLi](rb代表索引树,WLi代表第i个工作层),即获得维度di中的属性字段记录。在这一过程中,由于前面的说明中已经提到维表被分成多个子表,各个子表包括有原维表中某一层次或某些层次的属性信息,因此,当查找rb[i,WLi]时,就可以根据所要查找的工作层的层次选择相应子表进入到内存中,而不必将整个维表都放入内存里。例如,在前面的查询语句Q1中,需要查询SrcIPaddress维中工作层SrcProvince的信息,因此可以直接调用图4(c)中的子表,而不是图4(a)所示的整个维表。
在此处可以看出,如果在前面将原有超大维表切分成子表时,一个子表中包含有两层以上属性,则会在此处降低查询的性能。例如,某层属性L1与另一层属性L2共用一个子表的话,在切分过程中只能按L1或L2层来切分。假设按L1切分,而在表连接时使用的是L2层,那么其性能就会相对于使用独立的L2层优化要差。
步骤302)、将步骤301)中各个维的查询结果予以合并,得到连接结果t,将连接结果写入连接结果集T。这一连接过程为本领域技术人员所公知,因此不在此处重复说明。
以上是对本发明的超大维表连接方法在互联网管理系统中的应用的说明。在其它实施例中,本发明的超大维表连接方法同样可以在诸如金融交易系统、电子商务系统、电信系统等其它领域中应用。例如,在金融交易系统(股票、期货、银行业务)中分析实时交易数据。这些实时交易数据将分为多个维度:交易人、交易类型、交易场所、交易金额等。交易人维表分层为:交易人ID、客户类型、市、省;交易类型分层为:交易类型ID、交易类型、交易种类...。其中,交易人维表中交易人数量将达到几千万甚至上亿,属于明显的超大维表。另外,电子商务系统和电信系统的交易人维表中的自然人数量都将达到千万至亿数量级,也属于超大维表。上述几类维表都具有与IP维表同样的性质:数量大、层次多。因此,都可以采用本发明的方法对这些维表加以处理,提高超大维表做表连接时的效率。
从上面的说明可以看出,本发明方法将超大维表按照其中的属性的层次分为多个维表,然后在查询过程中根据需要选择划分后的多个维表中的某一些进行查询操作。由于划分后的维表的单个表较超大维表在数据大小上要小得多,因此本发明方法一方面可解决内存容量限制,避免磁盘I/O(因为内存不能满足超大维表需求,需频繁读磁盘来获取维表中不在内存的部分);另一方面,压缩维表可减少表连接时的探测时间(本文用到Nested-Loop Join,探测时间与维表的大小成反比,缩小维表可减少探测时间,最终减少表连接时间)。
最后所应说明的是,以上实施例仅用以说明本发明的技术方案而非限制。尽管参照实施例对本发明进行了详细说明,本领域的普通技术人员应当理解,对本发明的技术方案进行修改或者等同替换,都不脱离本发明技术方案的精神和范围,其均应涵盖在本发明的权利要求范围当中。
Claims (6)
1.一种超大维表的切分方法,包括:
步骤1)、从所述超大维表的各个表项中提取一层次的维的一个属性值以及与该属性值所对应的连接键的值域范围;
步骤2)、将所述层次的维中的所有属性值以及与各个属性值相对应的连接键的值域范围保存在一子表中;
步骤3)、重复上述步骤,直到将所述超大维表中所有层次的维的信息保存到对应子表中。
2.根据权利要求1所述的超大维表的切分方法,其特征在于,在所述的步骤1)之前,还包括将所述超大维表的表项按连接键字段的值做排序的步骤。
3.根据权利要求2所述的超大维表的切分方法,其特征在于,所述排序按照连接键字段的值做升序排序。
4.一种超大维表连接方法,包括:
步骤1)、采用权利要求1-3之一的超大维表的切分方法将所述的超大维表按照维的层次分成多个子表,所述子表中包括所述超大维表中某一层次或某些层次的属性信息;
步骤2)、为压缩后所生成的子表建立索引;
步骤3)、在收到用户的查询请求后,根据所述索引调用相应的子表,实现数据流中数据的表连接。
5.根据权利要求4所述的超大维表连接方法,其特征在于,所述的步骤3)包括:
步骤3-1)、数据流中的数据流元组根据用户的查询请求查询步骤2)所创建的索引,调用相应的子表,从所述子表中读取相应的属性字段;
步骤3-2)、将从各个维的子表中所读取的属性字段合并,得到连接结果。
6.根据权利要求4所述的超大维表连接方法,其特征在于,在所述的步骤2)中,为所述子表所建立的索引为B+Tree索引、B-tree索引、二叉树索引中的一种。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010142719.0A CN102214176B (zh) | 2010-04-02 | 2010-04-02 | 超大维表的切分与表连接方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010142719.0A CN102214176B (zh) | 2010-04-02 | 2010-04-02 | 超大维表的切分与表连接方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102214176A true CN102214176A (zh) | 2011-10-12 |
CN102214176B CN102214176B (zh) | 2014-02-05 |
Family
ID=44745491
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201010142719.0A Expired - Fee Related CN102214176B (zh) | 2010-04-02 | 2010-04-02 | 超大维表的切分与表连接方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102214176B (zh) |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102609440A (zh) * | 2011-12-23 | 2012-07-25 | 浙江大学 | 一种高维环境中资源分配问题的查询方法 |
CN102867066A (zh) * | 2012-09-28 | 2013-01-09 | 用友软件股份有限公司 | 数据汇总装置和数据汇总方法 |
CN103186653A (zh) * | 2011-12-30 | 2013-07-03 | 国际商业机器公司 | 辅助查询方法和设备、查询方法和设备及命名查询系统 |
CN103186651A (zh) * | 2011-12-31 | 2013-07-03 | 中国移动通信集团公司 | 一种分布式关系数据库及其建立、查询方法和装置 |
CN103838738A (zh) * | 2012-11-21 | 2014-06-04 | 大连灵动科技发展有限公司 | 一种决策支持系统中数据完整性的解决方法 |
CN103942184A (zh) * | 2013-12-30 | 2014-07-23 | 远光软件股份有限公司 | 具有附加项汇总报表的配置方法、生成方法及系统 |
CN103995855A (zh) * | 2014-05-14 | 2014-08-20 | 华为技术有限公司 | 存储数据的方法和装置 |
CN103186651B (zh) * | 2011-12-31 | 2016-12-14 | 中国移动通信集团公司 | 一种分布式关系数据库及其建立、查询方法和装置 |
WO2017148297A1 (zh) * | 2016-03-02 | 2017-09-08 | 阿里巴巴集团控股有限公司 | 数据表连接方法及装置 |
CN108363766A (zh) * | 2018-02-06 | 2018-08-03 | 福建星瑞格软件有限公司 | 一种均匀切分数据库表数据的方法及计算机设备 |
CN109325050A (zh) * | 2018-08-01 | 2019-02-12 | 吉林盘古网络科技股份有限公司 | 数据查询方法、装置及终端设备 |
CN110232074A (zh) * | 2019-05-31 | 2019-09-13 | 新华三大数据技术有限公司 | 流数据与维表关联方法及流计算装置 |
CN111327532A (zh) * | 2020-01-21 | 2020-06-23 | 南京贝伦思网络科技股份有限公司 | 一种网络设备超大转发策略表容量的实现方法 |
CN112256704A (zh) * | 2020-10-23 | 2021-01-22 | 山东超越数控电子股份有限公司 | 一种快速join方法、存储介质及计算机 |
CN113051443A (zh) * | 2019-12-26 | 2021-06-29 | 北京奇艺世纪科技有限公司 | 一种数据处理方法及相关设备 |
CN113672598A (zh) * | 2021-10-22 | 2021-11-19 | 国能(北京)商务网络有限公司 | 一种面向供应链采购的多视角数据维度模型的构建方法 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1198761A1 (en) * | 1999-01-15 | 2002-04-24 | Metaedge Corporation | Method for visualizing information in a data warehousing environment |
CN101533406A (zh) * | 2009-04-10 | 2009-09-16 | 北京锐安科技有限公司 | 一种海量数据查询方法 |
-
2010
- 2010-04-02 CN CN201010142719.0A patent/CN102214176B/zh not_active Expired - Fee Related
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1198761A1 (en) * | 1999-01-15 | 2002-04-24 | Metaedge Corporation | Method for visualizing information in a data warehousing environment |
CN101533406A (zh) * | 2009-04-10 | 2009-09-16 | 北京锐安科技有限公司 | 一种海量数据查询方法 |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102609440B (zh) * | 2011-12-23 | 2013-10-23 | 浙江大学 | 一种高维环境中资源分配问题的查询方法 |
CN102609440A (zh) * | 2011-12-23 | 2012-07-25 | 浙江大学 | 一种高维环境中资源分配问题的查询方法 |
CN103186653B (zh) * | 2011-12-30 | 2016-04-13 | 国际商业机器公司 | 辅助查询方法和设备、查询方法和设备及命名查询系统 |
CN103186653A (zh) * | 2011-12-30 | 2013-07-03 | 国际商业机器公司 | 辅助查询方法和设备、查询方法和设备及命名查询系统 |
US9811554B2 (en) | 2011-12-30 | 2017-11-07 | International Business Machines Corporation | Assisting query and querying |
CN103186651A (zh) * | 2011-12-31 | 2013-07-03 | 中国移动通信集团公司 | 一种分布式关系数据库及其建立、查询方法和装置 |
CN103186651B (zh) * | 2011-12-31 | 2016-12-14 | 中国移动通信集团公司 | 一种分布式关系数据库及其建立、查询方法和装置 |
CN102867066A (zh) * | 2012-09-28 | 2013-01-09 | 用友软件股份有限公司 | 数据汇总装置和数据汇总方法 |
CN102867066B (zh) * | 2012-09-28 | 2015-10-21 | 用友网络科技股份有限公司 | 数据汇总装置和数据汇总方法 |
CN103838738A (zh) * | 2012-11-21 | 2014-06-04 | 大连灵动科技发展有限公司 | 一种决策支持系统中数据完整性的解决方法 |
CN103942184A (zh) * | 2013-12-30 | 2014-07-23 | 远光软件股份有限公司 | 具有附加项汇总报表的配置方法、生成方法及系统 |
CN103995855A (zh) * | 2014-05-14 | 2014-08-20 | 华为技术有限公司 | 存储数据的方法和装置 |
CN103995855B (zh) * | 2014-05-14 | 2017-03-08 | 华为技术有限公司 | 存储数据的方法和装置 |
WO2017148297A1 (zh) * | 2016-03-02 | 2017-09-08 | 阿里巴巴集团控股有限公司 | 数据表连接方法及装置 |
CN108363766A (zh) * | 2018-02-06 | 2018-08-03 | 福建星瑞格软件有限公司 | 一种均匀切分数据库表数据的方法及计算机设备 |
CN109325050A (zh) * | 2018-08-01 | 2019-02-12 | 吉林盘古网络科技股份有限公司 | 数据查询方法、装置及终端设备 |
CN110232074A (zh) * | 2019-05-31 | 2019-09-13 | 新华三大数据技术有限公司 | 流数据与维表关联方法及流计算装置 |
CN113051443A (zh) * | 2019-12-26 | 2021-06-29 | 北京奇艺世纪科技有限公司 | 一种数据处理方法及相关设备 |
CN111327532A (zh) * | 2020-01-21 | 2020-06-23 | 南京贝伦思网络科技股份有限公司 | 一种网络设备超大转发策略表容量的实现方法 |
CN112256704A (zh) * | 2020-10-23 | 2021-01-22 | 山东超越数控电子股份有限公司 | 一种快速join方法、存储介质及计算机 |
CN113672598A (zh) * | 2021-10-22 | 2021-11-19 | 国能(北京)商务网络有限公司 | 一种面向供应链采购的多视角数据维度模型的构建方法 |
CN113672598B (zh) * | 2021-10-22 | 2022-01-21 | 国能(北京)商务网络有限公司 | 一种面向供应链采购的多视角数据维度模型的构建方法 |
Also Published As
Publication number | Publication date |
---|---|
CN102214176B (zh) | 2014-02-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102214176B (zh) | 超大维表的切分与表连接方法 | |
Chaudhuri et al. | An overview of business intelligence technology | |
Zhou et al. | Adaptive processing for distributed skyline queries over uncertain data | |
US10657116B2 (en) | Create table for exchange | |
CN104933112B (zh) | 分布式互联网交易信息存储处理方法 | |
CN103366015B (zh) | 一种基于Hadoop的OLAP数据存储与查询方法 | |
US9535956B2 (en) | Efficient set operation execution using a single group-by operation | |
CN104750681B (zh) | 一种海量数据的处理方法及装置 | |
CN105653609B (zh) | 基于内存的数据处理方法及装置 | |
CN109656958B (zh) | 数据查询方法以及系统 | |
US20080201296A1 (en) | Partitioning of nested tables | |
US6493728B1 (en) | Data compression for records of multidimensional database | |
CN102521406A (zh) | 海量结构化数据复杂查询任务的分布式查询方法和系统 | |
JP2003526159A (ja) | 多次元データベースおよび統合集約サーバ | |
Scabora et al. | Physical data warehouse design on NoSQL databases-OLAP query processing over HBase | |
Matei et al. | Column-oriented databases, an alternative for analytical environment | |
Petricioli et al. | The challenges of nosql data warehousing | |
Barez et al. | Benchmarking specialized databases for high-frequency data | |
Rashid et al. | Challenging issues of spatio-temporal data mining | |
Bou et al. | Scalable keyword search over relational data streams by aggressive candidate network consolidation | |
Li et al. | A Comparative Study of Row and Column Storage for Time Series Data | |
CN103309890A (zh) | 一种Linux文件系统与实时数据库索引融合的技术 | |
Ma et al. | Bank big data architecture based on massive parallel processing database | |
Zdenka et al. | Data analysis: tools and methods | |
Ming et al. | Research on multidimensional analysis method of drilling information based on Hadoop |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20140205 Termination date: 20160402 |