WO2014173279A1 - 一种面向Hbase数据库的复合查询方法 - Google Patents

一种面向Hbase数据库的复合查询方法 Download PDF

Info

Publication number
WO2014173279A1
WO2014173279A1 PCT/CN2014/075901 CN2014075901W WO2014173279A1 WO 2014173279 A1 WO2014173279 A1 WO 2014173279A1 CN 2014075901 W CN2014075901 W CN 2014075901W WO 2014173279 A1 WO2014173279 A1 WO 2014173279A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
record
index table
query
query method
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.)
Ceased
Application number
PCT/CN2014/075901
Other languages
English (en)
French (fr)
Inventor
刘磊
何东杰
王海冰
才华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Unionpay Co Ltd
Original Assignee
China Unionpay Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by China Unionpay Co Ltd filed Critical China Unionpay Co Ltd
Publication of WO2014173279A1 publication Critical patent/WO2014173279A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures

Definitions

  • the invention belongs to the technical field of data query, and relates to a composite query method for a Hbase database. Background technique
  • NoSQL database has achieved good scalability by simplifying data models and weakening data consistency requirements, providing an option for managing massive data.
  • the HBase database is one of the most widely used NoSQL databases. It is a distributed, column-oriented open source database that is scalable and ideal for massive data storage.
  • each record in the HBase database is a simple byte array with a relatively fixed Key-Value structure, that is, each record has a unique Key (primary key) that can be used as an index.
  • Key is a variable-length string, and all other fields are stored in Value.
  • the Key is first queried according to the query condition, and then the traversal query is performed on the value of each record according to each of the other query conditions. Because of the high content of Value, such a query is very time consuming, so it does not support fast queries based on non-primary keys.
  • a user will generate a record after a store based on a P0S machine card transaction, which may include the following:
  • the card number is the number of the credit card
  • the merchant is the merchant that the user conducts the transaction, such as a shopping mall or a restaurant. Since the Key needs to guarantee uniqueness in HBase, and a card number can generate multiple records, when the record is stored in the HBase database, the card number and a random number are connected, and this is used as the Key, which will be ⁇ transaction time, transaction merchant , transaction area, transaction amount > as Value, stored in the HBase database.
  • the query based on the user card number is relatively simple. For example, if you query all transaction records of a certain period of time based on the user card number, you only need to perform the following steps:
  • the combined conditions of the compound query include: the transaction area, the transaction time, and the transaction amount.
  • all records in the HBase database are sequentially read in a violent manner, and each record is compared and filtered according to the query condition and the value of the value in the record.
  • the specific steps are as follows: (1) creating a Scan object; (2) performing a Scan action; (3) filtering each record in the ResultScanner returned by the Scan according to the search condition, such as a composite condition; otherwise, repeating the action, Until you traverse all the records in the ResultScanner.
  • Hive open source software developed specifically for HBase can not support the non-primary key information query function, which can realize non-primary key based query, is widely used in the industry.
  • the Hive software is based on Hadoop's Map-reduce parallel task processing mechanism. It also traverses all records based on the brute force method, filters them, and obtains the required data on the basis of this, and then submits the final result to the user.
  • China Patent Application No. 201210408753.7 entitled “Hedoop-based Distributed Search Engine Construction Method” patent, also reveals a relatively efficient parallel query method.
  • Hive software overcomes some limitations of HBase database in query function, due to its internal implementation mechanism, its retrieval response time is up to several minutes or even hours, which can not achieve real-time response to user query requirements, especially Is the compound query application.
  • the object of the present invention is to improve the efficiency of compound query for the Hbase database.
  • the present invention provides a composite query method for an Hbase database, wherein each record in the Hbase database is stored in a main record table by a primary key (Key)-key value structure.
  • the condition of the compound query includes M combination conditions corresponding to the key value part of the main record table, and M is an integer greater than or equal to 2;
  • the composite query method includes the following steps:
  • a data retrieval step that includes:
  • c) for the obtained record define an element corresponding to the Key of the main record table in the value of the corresponding index table as a second key, and perform a primary key query at least in the main record table.
  • a composite query method further comprising the steps of: outputting the records retrieved in the step (3) quantitatively for browsing by a user, and browsing the output of a batch of the user At the time of recording, the retrieval process of the step (3) is simultaneously performed to further retrieve other records of the subsequent batch.
  • the user acts after browsing a certain batch of records, and according to the action, the next batch of the records is quantitatively output.
  • N M.
  • the step c) further includes: a condition other than the N conditions among the M combined conditions. As a filter condition, traverse the value of the main record table.
  • the records in the step (2), may be inserted into the index table according to the structure of the index table, one by one or in batches.
  • the method includes the following steps:
  • the N combinations are arranged according to their data filtering degree in the Key of the index table.
  • the order of the N combination conditions in the first key is the same as the order of the N combination conditions of the Key of the index table.
  • the record may be a credit card transaction record.
  • the technical effect of the invention is that the compound query method can greatly reduce the retrieval time and improve the retrieval efficiency, and the method is very suitable for data query of a massive database.
  • FIG. 1 is a flow chart of a composite query method for a Hbase database according to an embodiment of the invention.
  • FIG. 2 is a schematic diagram showing the structural change of the record at the time of index establishment. detailed description
  • the HBase database formed by storing data for the user's card transaction record is taken as an example to illustrate the composite query method exemplarily.
  • the application of the Hbase database that is, the type of data it stores, is not limited by the embodiment of the present invention.
  • the record stored in the HBase database is a swipe transaction record, which can also be understood as a byte array, which can include but is not limited to the following information: card number, transaction time, merchant code, area code, transaction amount, acquirer code and many more.
  • each record is stored in a main record table (herein referred to as a main transaction record table) in a Key-Value structure, and the Key-Value structure of the record is reflected.
  • the structure of the master record table is a swipe transaction record, which can also be understood as a byte array, which can include but is not limited to the following information: card number, transaction time, merchant code, area code, transaction amount, acquirer code and many more.
  • the Key of the main record table is defined as the card number
  • the Value part of the main record table can be defined as the transaction time, the merchant code (reflecting "transaction merchant"), the area code (reflecting "transaction area”), and the transaction amount.
  • the card number is combined with the random number, corresponding to the Key of the main transaction record table, that is, the Key1 of the record 210 stored in the main transaction record table as shown in FIG. 2 is formed, at least The combination of transaction time, merchant code, area code, transaction amount, etc. should be in the Value of the main transaction record table, that is, the Valuel of the record 210 stored in the main transaction record table as shown in FIG.
  • the random number inserted in Keyl guarantees its uniqueness in the Hbase database (even if a card number can generate multiple transactions).
  • FIG. 1 is a schematic flow chart of a composite query method for an Hbase database according to an embodiment of the present invention
  • FIG. 2 is a schematic diagram showing a structural change of a record at the time of index establishment.
  • the record 210 reflects the structure inserted in the main record table
  • the record 220 reflects the structure inserted in the search table.
  • the structural changes in the records also reflect the structural definition differences between the master record table and the index table.
  • step S110 of FIG. 1 the Key and Value of the index table are defined.
  • a composite index table is designed for the compound query, and the following conditions of the composite query are taken as an example to retrieve all the records that meet the following combination conditions: Shanghai,
  • design index table structure is as follows:
  • the reason for adding a random number in the Key is that there may be multiple transaction records in the same region and at the same time. After adding the random number, the uniqueness of the Key in the index table can be ensured.
  • the design of the Key is related to the query needs (that is, according to which conditions), and also related to the distribution of the data, so the design index table can be customized for the query requirements.
  • the usual query time is a certain month.
  • the data can be filtered to a few thousandths according to the regional filtering records, and only 1/12 can be filtered according to the monthly filtering;
  • the previous field is the area code, and the following field is the month (ie, the transaction time).
  • the amount is ranked according to its data filtering degree from high to low, wherein the data filtering degree is defined as the value obtained by dividing the amount of data filtered by all the retrieved data when filtering according to a certain condition. In this way, in the subsequent query process, it is beneficial to improve the efficiency of the primary key query.
  • One of the tables stores the original transaction record, that is, the main record table, whose Key is the card number; the other table is the index table, and its Key is "area code + transaction time + transaction amount + random number", and its value corresponds to the record.
  • Key in the main record table ie card number).
  • the records are correspondingly inserted into the index table according to the structure of the index table.
  • index establishment there are two implementations of index establishment.
  • the first way is to insert the index into the index table while inserting the record into the main transaction record table, that is, insert the record into the index table according to the structure of the index table one by one;
  • the second way is to use the map of Hadoop
  • the -reduce parallel run mechanism traverses the main record table and inserts the index into the index table in batch mode.
  • step S120 can be implemented in the manner shown in FIG. 2, which specifically includes the following steps:
  • read Keyl such as card number
  • Value 1 such as transaction time, merchant code, area code, transaction amount, etc.
  • At least the Key elements of the corresponding index table in Valuel are combined to generate Key2 (for example, area code, merchant code, transaction time, transaction amount, etc.), and Keyl is formed into Value2 (for example, card number);
  • Key2 for example, area code, merchant code, transaction time, transaction amount, etc.
  • Value2 for example, card number
  • Figure 2 reflects the structural changes in the records at the time of index creation, and also reflects the structural differences between the index table and the main record table.
  • the order of the plurality of elements in the Key 2 of the record 220 (corresponding to a plurality of combination conditions) is the same as the order of the elements of the Key of the index table, for example, the region The code, merchant code, trading time, and transaction amount are therefore arranged.
  • the elements included in the Key2 include, but are not limited to, elements corresponding to the combination condition, for example, it may include a merchant code, and may also include elements of non-corresponding combination conditions such as an acquirer code.
  • Key 2 of record 220 is a composite primary key.
  • a random number is inserted into the Key of the index table to ensure the uniqueness of each Key of the index table. Therefore, the Key 2 of the record 220 can be defined as: area code + merchant code + transaction time + transaction amount + random number.
  • the index table is first queried and then the main record table is queried, and specifically includes steps S130 to S150.
  • Step S130 Extract a plurality of combination conditions to generate a first Key according to the condition of the input compound query. E.g, The transaction time, area code, and transaction amount are extracted as the first key.
  • Step S140 Perform a primary key query in the established index table according to the first key, thereby obtaining a corresponding record that meets the multiple combination conditions, for example, obtaining a transaction record that meets three conditions of transaction time, area code, and transaction amount. .
  • step S150 for the transaction record obtained in step S140, the key element (ie, the card number) of the corresponding main record table in the value corresponding to the index table is defined as the second key, and the primary key query is performed at least in the main record table. In this way, you can query the transaction records that meet the four conditions of the card number, trading time, area code, and transaction amount.
  • the key element ie, the card number
  • the primary key query is performed at least in the main record table.
  • the three combined conditional transaction time, the area code, and the transaction amount are all defined as the Key of the index table, and accordingly, the Key 2 of the record 220 also includes the transaction time, the area code, and the transaction amount.
  • any two of the three combination conditions may be defined as a Key of the index table.
  • the design index table structure is as follows:
  • Key 2 of record 220 may also not include the transaction amount.
  • the length of the primary key is relatively reduced and storage is relatively easy. Therefore, in the data retrieval step, the steps may also be included:
  • the transaction amount condition entered by the user is used as a filter condition, and the value of the query master record table is traversed.
  • this method embodiment requires a traversal of the value of the query master record table, although the relative traversal approach reduces time, but it may be relatively delayed.
  • the retrieved record is outputted in a delayed manner, that is, step S160.
  • the corresponding record can be output in the following steps.
  • the system can continue to run the data retrieval process in the background to retrieve the next batch or batches of quantitative records that meet the conditions, for example, retrieve the next batch of 20 records;
  • step (3) When the user clicks to browse the next page, it returns to the search result of step (2); then repeats step (2), so that all the qualified records are output to the user for browsing. In this way, the system can continue to perform the retrieval operation automatically in the background by using the time when the user browses the query result. Even if the previous step of the S160 is relatively time consuming, since the user does not immediately output the result, the user can immediately obtain the result when browsing the subsequent record, and the user may I don't feel the delay of data retrieval, and realize delay hiding.
  • the retrieval time can be greatly reduced and the retrieval efficiency can be improved.
  • the response time based on the open source Hive query is 240 seconds (4 minutes).
  • the response time is less than 3 seconds. Therefore, this method is very suitable for data query of massive databases.
  • the above example mainly illustrates the composite query method for the Hbase database of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Software Systems (AREA)

Abstract

本发明提供一种面向Hbase数据库的复合查询方法，属于数据查询技术领域。该复合查询方法包括建立索引表、索引建立、数据检索步骤，在建立索引表时，定义索引表的Key和Value；其中，索引表的Key的要素包括M个组合条件的N个，索引表的Value的要素至少包括对应主记录表的Key，2≤N≤M，M为大于或等于2 的整数；在数据检索步骤中，根据提取N个组合条件生成的第一Key，在索引表中进行主键查询，然后根据主记录表的Key的要素定义为第二Key，至少在主记录表中进行主键查询。该方法查询效率高，尤其适用于海量数据库的数据查询。

Description

一种面向 Hbase数据库的复合査询方法
技术领域
本发明属于数据查询技术领域， 涉及面向 Hbase数据库的复合查询方法。 背景技术
近年来， 企业 IT系统数据量呈爆炸性增长， 传统的数据库已难以有效管理高达 几十亿条记录甚至更多的数据规模。 NoSQL数据库作为一种新兴的数据管理技术， 通过简化数据模型、 弱化数据一致性要求而获得了良好的可扩展性， 为管理海量数 据提供了一种选择。 HBase数据库即是目前获得较广泛应用的 NoSQL数据库之一， 其是一种分布式的、 面向列的开源数据库， 它可扩展性好， 非常适用于海量数据存 储。
通常地， HBase数据库的中的每条记录就是一个简单的字节数组， 具有相对固定 的 Key-Value (主键-键值） 结构， 即每条记录有唯一的 Key (主键） ， 其可以作为索 引， Key为可变长度的字符串， 而所有其他字段均保存在 Value (键值） 中。
因此， HBase数据库的数据查询过程中， 首先根据查询条件对 Key进行查询， 然 后在根据其他每一个查询条件对每一条记录的 Value进行遍历方式的查询。 由于 Value的内容多， 这样的查询方式非常耗时， 因此， 其不支持基于非主键进行快速查 询。
以用于存储用户刷卡交易记录的 HBase为例， 用户在一个商场基于 P0S机刷卡 交易后将产生一条记录， 该记录可以包括如下内容：
<卡号、 交易时间、 交易商户、 交易地区、 交易金额>
其中， 卡号为信用卡的号码， 商户为用户所进行交易的商户， 如商场或饭店。 由 于在 HBase中 Key需要保证唯一性， 而一个卡号可以产生多条记录， 因此在该记录 存入 HBase数据库时， 要将卡号和一个随机数连接， 将其作为 Key, 将<交易时间、 交易商户、 交易地区、 交易金额>作为 Value, 存入 HBase数据库中。
根据用户卡号的查询实现比较简单， 例如， 根据用户卡号查询某一段时间类的所 有交易记录， 则只需要执行如下步骤：
a、 创建一个新的 Scan (扫描） 对象；
b、 在 Scan对象的 Filter (过滤器） 选项中设置交易时间过滤规则； c、 执行 Scan动作。
以上只是单个条件的查询， 相对来说， 其查询效率还是可以接受的。 但是， 如果 要对 Hbase数据库实现复合查询， 也即除 Key之外的多个组合条件的查询，
例如， 同样对于存储用户刷卡交易记录的 HBase数据库， 如果需要查询满足诸如 如下多个条件的所有记录：
交易地区： 上海，
交易时间： 2012年 10月 至 2012年 12月，
交易金额： 1000元至 2000元。
那么， 复合查询的组合条件包括： 交易地区、 交易时间和交易金额。 在实现该复 合查询时， 采取暴力方式依次读取 HBase数据库中的所有记录， 对每一条记录根据 查询条件和记录中的 Value的值进行比较和过滤。具体步骤为： （ 1 )创建 Scan对象； ( 2 ) 执行 Scan动作； （3 ) 对 Scan返回的 ResultScanner中的每条记录， 根据检索 条件进行过滤， 如复合条件则输出； 否则重复执行该动作， 直到遍历 ResultScanner 中的所有记录。
明显地， 对于包含海量数据的 Hbase数据库来说， 其并不能根据非主键信息来检 索数据， 因此， 符合查询过程非常耗时， 效率低下， 并且随着数据的增加， 其效率 下降非常明显。
为提升 HBase数据库的复合查询的效率，提出了一种专门针对 HBase不能支持非 主键信息查询功能局限而开发的 Hive开源软件， 其可以实现基于非主键的查询， 在 业界使用比较广泛。 Hive软件内部是基于 Hadoop的 Map-reduce并行任务处理机制， 同样基于暴力方法遍历所有记录， 对其进行过滤， 在此基础上得到符合要求的数据， 然后将最终结果提交给用户。中国专利申请号 201210408753.7、名称为 "基于 Hadoop 的分布式搜索引擎构建方法" 的专利中， 也揭示了一种相对高效的并行式查询方法。
虽然 Hive软件等克服了 HBase数据库在查询功能方面的某些局限性， 但由于其 内部实现的机制所限， 其检索响应时间高达几分钟甚至数小时， 无法实现对用户查 询要求的实时响应， 尤其是复合查询应用时。
有鉴于此， 有必要提出一种新的面向 Hbase数据库的复合查询方法。 发明内容
本发明的目的在于， 提高面向 Hbase数据库的复合查询效率。 为实现以上目的或者其他目的， 本发明提供一种面向 Hbase数据库的复合查询方 法， 其中， 所述 Hbase数据库中的每条记录按主键 （Key) -键值 （Value) 结构存储 于主记录表， 复合查询的条件中包括对应主记录表的键值部分的 M个组合条件， M 为大于或等于 2的整数； 该复合查询方法包括以下步骤：
( 1 ) 建立索引表步骤： 定义索引表的 Key和 Value, 其中， 索引表的 Key的要 素包括所述 M个组合条件的 N个， 所述索引表的 Value的要素至少包括对应所述主 记录表的 Key, 2^N^M;
( 2) 索引建立步骤： 将所述记录按照所述索引表的结构相应插入索引表中；
( 3 ) 数据检索步骤， 其包括：
a) 根据输入的复合查询的条件， 提取所述 N个组合条件生成第一 Key, b )根据所述第一 Key在所述索引表中进行主键查询， 以得到符合所述 N个组 合条件的相应记录，
c) 针对得到的所述记录， 将其对应索引表的 Value中的对应所述主记录表的 Key的要素定义为第二 Key, 至少在所述主记录表中进行主键查询。
按照本发明一优选实施例的复合查询方法， 其中， 还包括步骤： 将所述步骤 （3 ) 中检索得到的记录按批定量地输出以供用户浏览， 并且， 在用户浏览某一批输出的 记录时， 同时进行所述步骤 （3 ) 的检索过程以进一步检索出之后批次的其他记录。
在之前所述实施例的复合查询方法中，具体地，用户在浏览完某一批记录后动作， 根据该动作， 下一批所述记录被定量输出。
优选地， 在所述步骤 （1 ) 中， N=M。
优选地，，所述索引表的 Key中被插入随机数以保证索引表的每个 Key的唯一性。 按照本发明还一实施例的复合查询方法， 其中， 在 N小于 M时， 所述步骤 （3 ) 中， 步骤 c) 还包括： 将 M个组合条件中的所述 N个条件之外的条件， 作为过滤条 件， 遍历查询所述主记录表的 Value。
在之前所述任一实施例的复合查询方法中， 所述步骤 （2) 中， 可以逐条地或分 批地将所述记录按照所述索引表的结构相应插入索引表中。
按照本发明又一实施例的复合查询方法， 其中， 所述步骤 （2) 中， 包括以下步 骤：
A) 对于每条记录， 读取其按主记录表的定义的 Keyl和 Valuel ;
B ) 至少将 Valuel中的对应索引表的 Key的要素组合生成 Key2， 将 Keyl形成 Value2;
C) 将记录以 Key2-Value2的结构形式插入所述索引表中。
按照本发明再一实施例的复合查询方法， 其中， 所述 N个组合条件在所述索引表 的 Key中按照其数据过滤度排列， 数据过滤度越高， 相应的组合条件排列越靠前。
具体地， 所述第一 Key中的所述 N个组合条件的排列顺序与所述索引表的 Key 的 N个组合条件的排序顺序相同。
具体地， 所述记录可以为刷卡交易记录。
本发明的技术效果是， 该复合查询方法可以大大减少检索时间， 提高检索效率， 该方法非常适用于海量数据库的数据查询。 附图说明
从结合附图的以下详细说明中， 将会使本发明的上述和其他目的及优点更加完整 清楚， 其中， 相同或相似的要素采用相同的标号表示。
图 1是按照本发明一实施例的面向 Hbase数据库的复合查询方法流程示意图。 图 2是在索引建立时的记录的结构变化示意图。 具体实施方式
下面介绍的是本发明的多个可能实施例中的一些， 旨在提供对本发明的基本了 解， 并不旨在确认本发明的关键或决定性的要素或限定所要保护的范围。 容易理解， 根据本发明的技术方案， 在不变更本发明的实质精神下， 本领域的一般技术人员可 以提出可相互替换的其他实现方式。 因此， 以下具体实施方式以及附图仅是对本发 明的技术方案的示例性说明， 而不应当视为本发明的全部或者视为对本发明技术方 案的限定或限制。
在以下实施例中， 以用于存储用户刷卡交易记录的数据形成的 HBase数据库为 例， 示例性地说明复合查询方法。 但是， 需要理解的是， Hbase数据库的应用场合， 也即其所存储的数据类型， 不受本发明实施例限制。
HBase数据库中所存储的记录即为刷卡交易记录，其也可以理解为一个字节数组， 其可以包括但不限于以下信息： 卡号、 交易时间、 商户代码、 地区代码、 交易金额、 收单机构代码等等。 同样地， 在本发明的 Hbase数据库中， 每条记录以 Key-Value 结构存储于主记录表（在此或称为主交易记录表）中， 记录的 Key-Value结构即反映 主记录表的结构。 在该实施例中， 主记录表的 Key定义为卡号， 主记录表的 Value 部分可以定义为交易时间、 商户代码 （反映 "交易商户" ） 、 地区代码 （反映 "交 易地区" ） 、 交易金额。 在每条记录存储于该 Hbase数据库时， 将卡号与随机数组 合， 对应于主交易记录表的 Key, 也即形成如图 2所示的存储在主交易记录表的记录 210的 Keyl， 至少将交易时间、 商户代码、 地区代码、 交易金额等组合应于主交易 记录表的 Value, 也即形成如图 2所示的存储在主交易记录表的记录 210的 Valuel。 Keyl中插入的随机数可以保证其在 Hbase数据库中唯一性 （即使一个卡号可以产生 多条交易记录） 。
图 1所示为按照本发明一实施例的面向 Hbase数据库的复合查询方法流程示意 图， 图 2所示为在索引建立时的记录的结构变化示意图。 其中， 记录 210反映插入 在主记录表中的结构， 记录 220反映插入在检索表中的结构。 记录的结构变化也反 映了主记录表与索引表之间的结构定义差异。 以下具体说明该实施例的复合查询方 法过程。
首先， 索引表设计。
如图 1步骤 S110, 定义索引表的 Key和 Value; 在该实施例中， 针对复合查询设 计复合的索引表， 以以下复合查询的条件为例， 检索所有符合如下组合条件的记录: 交易地区： 上海，
交易时间： 2012年 10月至 2012年 12月，
交易金额： 1000元至 2000元。
具体地， 设计索引表结构如下：
Key: 地区代码 +交易时间 +交易金额 +随机数；
Value: 记录主表中的主键即卡号。
在 Key中加入随机数的原因在于：同一地区、同一时间可能会存在多个交易记录， 加入随机数后可确保索引表中的 Key的唯一性。 Key的设计与查询需要有关 （即根 据哪些条件查询） ， 也与数据的分布有关， 因此可以针对查询需求定制设计索引表。
例如， 全国有上千个地区， 而通常查询时间为某一个月。 为了简化分析， 假设在 不同地区、 不同月份的交易记录是均匀分布的， 则根据地区过滤记录， 可以将数据 过滤到几千分之一； 而根据月份过滤， 则只能过滤 1/12; 因此在 Key设计中， 前面 字段为地区代码， 后面字段为月份 （即交易时间） 。
因此， 优选地， 在索引表的 Key中， 三个组合条件地区代码、 交易时间、 交易金 额按照其数据过滤度由高至低依次排列， 其中， 数据过滤度定义为按照某一条件过 滤时， 被过滤掉的数据量除以所有被检索的数据量所得到的值。 这样， 在后面的查 询过程中， 有利于提高主键查询的效率。
因此， 针对上述复合需求， 共建立了 2张表。 其中一张表存储原始交易记录， 即 主记录表， 其 Key为卡号； 另外一张表为索引表， 其 Key为 "地区代码 +交易时间 + 交易金额 +随机数" ， 其 Value对该记录对应的主记录表中的 Key (即卡号） 。
进一步地， 索引建立。
如图 1步骤 S120, 将记录按照索引表的结构相应地插入索引表中。 具体地， 索引 的建立可以有 2种实施方式。 第一种方式为在向主交易记录表中插入记录的同时将 索引插入索引表中， 也即逐条地将记录按照索引表的结构相应地插入索引表中； 第 二种方式为利用 Hadoop的 Map-reduce并行运行机制遍历主记录表， 将索引以批量 方式插入到索引表中。
在一实施例中步骤 S120, 可以通过图 2所示的方式实现， 其具体包括以下步骤：
A)对于每条记录， 读取其按主记录表的定义的 Keyl (例如卡号） 和 Value 1 (例 如交易时间、 商户代码、 地区代码、 交易金额等） ；
B )至少将 Valuel中的对应索引表的 Key的要素组合生成 Key2 (例如地区代码、 商户代码、 交易时间、 交易金额等） ， 将 Keyl形成 Value2 (例如卡号） ；
C) 将记录以 Key2-Value2的结构形式插入索引表中。
图 2中反映了索引建立时的记录的结构变化， 也反映了索引表与主记录表之间的 结构差异。 在该实施例中， 在插入索引表后， 记录 220的 Key2中的多个要素的 （对 应包括多个组合条件） 的排列顺序与索引表的 Key的多个要素的排列顺序相同， 例 如， 地区代码、 商户代码、 交易时间、 交易金额因此排列。 需要理解的是， 可以在 Key2中， 其包括的要素包括但不限于组合条件对应的要素， 例如， 其可以包括商户 代码， 还可以包括收单机构代码等非对应组合条件的要素。
这样， 记录 220的 Key2是一个复合主键。 在一实施例中， 索引表的 Key中被插 入随机数以保证索引表的每个 Key的唯一性，因此，记录 220的 Key2可以被定义为： 地区代码 +商户代码 +交易时间 +交易金额 +随机数。
进一步， 数据检索。 该步骤中， 先查询索引表再查询主记录表， 具体地包括步骤 S130至 S150。
步骤 S130,根据输入的复合查询的条件，提取多个组合条件生成第一 Key。例如， 提取交易时间、 地区代码、 交易金额作为第一 Key。
步骤 S140， 根据该第一 Key在所建立的索引表中进行主键查询， 从而得到符合 所述多个组合条件的相应记录， 例如， 得到符合交易时间、 地区代码、 交易金额三 个条件的交易记录。
步骤 S150, 针对步骤 S140得到的交易记录， 将其对应索引表的 Value中的对应 主记录表的 Key的要素 （即卡号） 定义为第二 Key, 至少在主记录表中进行主键查 询。 这样， 就可以查询得到满足卡号、 交易时间、 地区代码、 交易金额四个相关条 件的交易记录。
至此， 数据检索过程基本完成。
需要理解的是， 在以上实施例中， 三个组合条件交易时间、 地区代码、 交易金额 均被定义为索引表的 Key, 相应地， 记录 220的 Key2也包括交易时间、 地区代码、 交易金额。 在其他实施例中， 也可以为， 三个组合条件中的任意两个可以定义为索 引表的 Key, 例如， 设计索引表结构如下：
Key: 地区代码 +交易时间 +随机数；
Value: 记录主表中的主键即卡号。
相应地， 记录 220的 Key2也可以不包括交易金额。 这样主键的长度相对减小， 存储相对容易。 因此， 在数据检索步骤中， 还可以包括步骤：
在对主记录表进行主键查询后， 将用户输入的交易金额条件， 作为过滤条件， 遍 历查询主记录表的 Value。
这样， 同样可以查询得到满足卡号、 交易时间、 地区代码、 交易金额四个相关条 件的交易记录。 但是， 这种方法实施例需要遍历查询主记录表的 Value, 虽然相对传 统的遍历方式要减少时间， 但是其可能相对要延迟一些。
进一步， 延迟隐藏方式地输出检索得到的记录， 即步骤 S160。 具体地， 可以按以 下步骤输出相应的记录。
( 1 ) 在接收到用户的查询请求后， 执行数据检索操作 （即步骤 S130至 S150) ， 但每次可以检索出符合条件的一定量的交易记录， 如 20条， 返回给用户浏览；
( 2) 在用户浏览时， 系统同时可以在后台继续运行数据检索过程， 检索符合条 件的下一批或多批的定量记录， 例如， 检索出下一批的 20条记录；
( 3 ) 用户点击浏览下一个页面时， 返回步骤 （2) 的检索结果； 然后执行重复步 骤 （2) ， 这样， 直到， 所有符合条件的记录均输出给用户浏览。 这样系统可以利用用户浏览查询结果的时间在后台继续自动执行检索操作， 即 使， S160之前步骤相对耗时， 但是由于不是即时输出， 因此， 用户在浏览后续的记 录时， 可以立即得到结果， 用户可能感觉不到数据检索的延迟， 实现了延迟隐藏。
通过以上示例的复合查询方法， 可以大大减少检索时间， 提高检索效率。 例如， 在 Hbase数据库的记录规模为两千万条的规模时， 基于开源软件 Hive查询的响应时 间为 240秒（4分钟） ， 采用以上实施例复合查询方法后， 响应时间小于 3秒。 因此， 该方法非常适用于海量数据库的数据查询。 以上例子主要说明了本发明的面向 Hbase 数据库的复合查询方法。 尽管只对其 中一些本发明的实施方式进行了描述， 但是本领域普通技术人员应当了解， 本发明 可以在不偏离其主旨与范围内以许多其他的形式实施。 因此， 所展示的例子与实施 方式被视为示意性的而非限制性的， 在不脱离如所附各权利要求所定义的本发明精 神及范围的情况下， 本发明可能涵盖各种的修改与替换。

Claims

权 利 要 求
1. 一种面向 Hbase数据库的复合查询方法， 其中， 所述 Hbase数据库中的每条 记录按主键 （Key ) -键值 （Value) 结构存储于主记录表， 复合查询的条件中包括对 应主记录表的键值部分的 M个组合条件， M为大于或等于 2的整数； 其特征在于， 包括以下步骤：
( 1 ) 建立索引表步骤： 定义索引表的 Key和 Value, 其中， 索引表的 Key的要 素包括所述 M个组合条件的 N个， 所述索引表的 Value的要素至少包括对应所述主 记录表的 Key, 2^N^M;
( 2) 索引建立步骤： 将所述记录按照所述索引表的结构相应插入索引表中；
( 3 ) 数据检索步骤， 其包括：
a) 根据输入的复合查询的条件， 提取所述 N个组合条件生成第一 Key, b ) 根据所述第一 Key在所述索引表中进行主键查询， 以得到符合所述 N个 组合条件的相应记录，
c)针对得到的所述记录， 将其对应索引表的 Value中的对应所述主记录表的 Key的要素定义为第二 Key, 至少在所述主记录表中进行主键查询。
2. 如权利要求 1所述的复合查询方法， 其特征在于， 还包括步骤： 将所述步骤 ( 3 ) 中检索得到的记录按批定量地输出以供用户浏览， 并且， 在用户浏览某一批输 出的记录时， 同时进行所述步骤 （3 ) 的检索过程以进一步检索出之后批次的其他记 录。
3. 如权利要求 2所述的复合查询方法， 其特征在于， 用户在浏览完某一批记录 后动作， 根据该动作， 下一批所述记录被定量输出。
4. 如权利要求 1所述的复合查询方法， 其特征在于， 在所述步骤（1 )中， N=M。
5. 如权利要求 1或 4所述的复合查询方法， 其特征在于， 所述索引表的 Key中 被插入随机数以保证索引表的每个 Key的唯一性。
6. 如权利要求 1所述的复合查询方法， 其特征在于， 在 N小于 M时， 所述步骤 ( 3 ) 中， 步骤 c) 还包括： 将 M个组合条件中的所述 N个条件之外的条件， 作为过 滤条件， 遍历查询所述主记录表的 Value。
7. 如权利要求 1所述的复合查询方法， 其特征在于， 所述步骤 （2) 中， 逐条地 或分批地将所述记录按照所述索引表的结构相应插入索引表中。
8. 如权利要求 1或 7所述的复合查询方法， 其特征在于， 所述步骤 （2) 中， 包 括以下步骤：
A) 对于每条记录， 读取其按主记录表的定义的 Keyl和 Valuel ;
B ) 至少将 Valuel中的对应索引表的 Key的要素组合生成 Key2， 将 Keyl形成 Value2;
C) 将记录以 Key2-Value2的结构形式插入所述索引表中。
9. 如权利要求 1所述的复合查询方法， 其特征在于， 所述 N个组合条件在所述 索引表的 Key中按照其数据过滤度排列， 数据过滤度越高， 相应的组合条件排列越
、
罪刖。
10. 如权利要求 9所述的复合查询方法，其特征在于，所述第一 Key中的所述 N 个组合条件的排列顺序与所述索引表的 Key的 N个组合条件的排序顺序相同。
11. 如权利要求 1所述的复合查询方法，其特征在于，所述记录为刷卡交易记录。
PCT/CN2014/075901 2013-04-22 2014-04-22 一种面向Hbase数据库的复合查询方法 Ceased WO2014173279A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201310139785.6 2013-04-22
CN201310139785.6A CN104111955B (zh) 2013-04-22 2013-04-22 一种面向Hbase数据库的复合查询方法

Publications (1)

Publication Number Publication Date
WO2014173279A1 true WO2014173279A1 (zh) 2014-10-30

Family

ID=51708750

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/075901 Ceased WO2014173279A1 (zh) 2013-04-22 2014-04-22 一种面向Hbase数据库的复合查询方法

Country Status (2)

Country Link
CN (1) CN104111955B (zh)
WO (1) WO2014173279A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116126851A (zh) * 2022-10-28 2023-05-16 马上消费金融股份有限公司 一种目标数据排序方法、装置、设备和存储介质

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105205162A (zh) * 2015-09-29 2015-12-30 烽火通信科技股份有限公司 HBase二级索引存储和查询系统及其查询方法
CN105653628B (zh) * 2015-12-28 2019-08-13 湖南蚁坊软件股份有限公司 一种基于倒排索引的列存储数据库的查询方法
CN107515882B (zh) * 2016-06-17 2020-12-25 阿里巴巴集团控股有限公司 数据查询方法及装置
CN106383860A (zh) * 2016-08-31 2017-02-08 无锡雅座在线科技发展有限公司 数据查询方法及装置
CN108062329B (zh) * 2016-11-08 2022-04-15 北京国双科技有限公司 一种数据导入方法及装置
CN106776809B (zh) * 2016-11-24 2020-05-01 中国银联股份有限公司 一种数据查询方法及系统
CN106709851B (zh) * 2016-11-30 2021-07-09 中体彩科技发展有限公司 大数据检索方法及装置
CN106779981B (zh) * 2017-02-04 2020-12-08 广州中国科学院计算机网络信息中心 基于物联网标识的店铺信息的查询方法以及装置
CN108460052B (zh) * 2017-02-22 2022-11-01 中兴通讯股份有限公司 一种自动创建索引的方法、装置及数据库系统
CN110019212B (zh) * 2017-11-29 2021-06-18 杭州海康威视数字技术股份有限公司 一种数据处理方法、装置及数据库服务器
CN108388569B (zh) * 2018-01-09 2021-07-20 杭州电子科技大学 一种快速的键值数据库的系统及建立方法
CN109325013B (zh) * 2018-07-11 2022-07-08 中国银联股份有限公司 一种分布式系统的数据管理方法及装置
CN110737692A (zh) * 2018-07-19 2020-01-31 杭州海康威视数字技术股份有限公司 一种检索数据的方法、建立索引库的方法及装置
CN109284351A (zh) * 2018-08-14 2019-01-29 青海大学 一种基于HBase数据库的数据查询方法
CN109472906B (zh) * 2018-12-26 2020-11-10 上海银基信息安全技术股份有限公司 数字钥匙生成方法、应用方法、装置、系统、终端及介质
CN110619000A (zh) * 2019-09-25 2019-12-27 网易（杭州）网络有限公司 时序数据的查询方法、装置、存储介质及电子设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7472140B2 (en) * 2005-12-20 2008-12-30 Oracle International Corporation Label-aware index for efficient queries in a versioning system
CN101866358A (zh) * 2010-06-12 2010-10-20 中国科学院计算技术研究所 一种多维区间查询方法及系统
CN102750356A (zh) * 2012-06-11 2012-10-24 清华大学 一种键值库辅助索引的构建与管理方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7472140B2 (en) * 2005-12-20 2008-12-30 Oracle International Corporation Label-aware index for efficient queries in a versioning system
CN101866358A (zh) * 2010-06-12 2010-10-20 中国科学院计算技术研究所 一种多维区间查询方法及系统
CN102750356A (zh) * 2012-06-11 2012-10-24 清华大学 一种键值库辅助索引的构建与管理方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116126851A (zh) * 2022-10-28 2023-05-16 马上消费金融股份有限公司 一种目标数据排序方法、装置、设备和存储介质

Also Published As

Publication number Publication date
CN104111955B (zh) 2018-10-23
CN104111955A (zh) 2014-10-22

Similar Documents

Publication Publication Date Title
WO2014173279A1 (zh) 一种面向Hbase数据库的复合查询方法
US11816126B2 (en) Large scale unstructured database systems
MUS Comparison between SQL and NoSQL databases and their relationship with big data analytics
CN111971666B (zh) 优化sql查询计划的维度上下文传播技术
CN104699718B (zh) 用于快速引入业务数据的方法和装置
CN109885615B (zh) 一种基于索引的面向区块链轻客户端的范围查询可验证查询方法
CN111221791A (zh) 一种多源异构数据导入数据湖的方法
US11869051B2 (en) Usage monitoring and usage based data pricing
EP4158477A1 (en) Share replication between remote deployments
CN115248829A (zh) 数据存储方法、数据查询方法及装置
CN105740264A (zh) 一种分布式xml数据库的排序方法及装置
US20240056499A1 (en) Sharing of data share metrics to customers
Rohde et al. Optimization of the Mainzelliste software for fast privacy-preserving record linkage
Gupta et al. Faster as well as early measurements from big data predictive analytics model
CN115658680A (zh) 数据存储方法、数据查询方法和相关装置
Garba et al. A comparison of NoSQL and relational database management systems (rdbms)
WO2024187996A1 (zh) 管理数据的方法和计算设备
CN107220363B (zh) 一种支持全局复杂检索的跨地域查询方法及系统
CN110858210A (zh) 数据查询方法及装置
CN106326317A (zh) 数据处理方法及装置
Chihoub et al. A scalability comparison study of data management approaches for smart metering systems
CN111221814B (zh) 二级索引的构建方法、装置及设备
US11126401B2 (en) Pluggable sorting for distributed databases
CN115422198A (zh) 大数据拉链表处理方法、装置、设备及存储介质
CN115239060A (zh) 基于大数据分析的适航审定风险评定系统及其方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14788765

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC ( EPO FORM 1205A DATED 17/02/2015 )

122 Ep: pct application non-entry in european phase

Ref document number: 14788765

Country of ref document: EP

Kind code of ref document: A1