WO2017096892A1 - 索引构建方法、查询方法及对应装置、设备、计算机存储介质 - Google Patents

索引构建方法、查询方法及对应装置、设备、计算机存储介质 Download PDF

Info

Publication number
WO2017096892A1
WO2017096892A1 PCT/CN2016/089484 CN2016089484W WO2017096892A1 WO 2017096892 A1 WO2017096892 A1 WO 2017096892A1 CN 2016089484 W CN2016089484 W CN 2016089484W WO 2017096892 A1 WO2017096892 A1 WO 2017096892A1
Authority
WO
WIPO (PCT)
Prior art keywords
query
data
query item
item
indication information
Prior art date
Application number
PCT/CN2016/089484
Other languages
English (en)
French (fr)
Inventor
覃安
谭待
Original Assignee
百度在线网络技术(北京)有限公司
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 百度在线网络技术(北京)有限公司 filed Critical 百度在线网络技术(北京)有限公司
Publication of WO2017096892A1 publication Critical patent/WO2017096892A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • G06F16/24553Query execution of query operations
    • G06F16/24561Intermediate data storage techniques for performance improvement
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures

Definitions

  • the present invention relates to the field of database technologies, and in particular, to an index construction method, an inquiry method, and an apparatus.
  • An adaptive indexing technology is specifically: splitting data into different pieces of data according to a user's query sequence, and gradually forming a sliced order (ie, an index) by exchanging sorts, thereby providing an acceleration condition for subsequent users' queries.
  • Another adaptive indexing technology is specifically: treating each recorded data as an isolated data point. As the user's query request continues, the data points that meet the user's query requirements are automatically aggregated and gradually formed into fragments. Ordered (ie, indexed), which in turn provides acceleration conditions for subsequent users' queries.
  • aspects of the present invention provide an index construction method, an inquiry method, and an apparatus for creating an index for a big data storage system, thereby improving query efficiency.
  • An aspect of the present invention provides an index construction method, including:
  • a query method including:
  • the data line indication information is used to indicate a data line in which the data of the existing query item is satisfied;
  • a search construction apparatus including:
  • a request obtaining module configured to obtain a query request for querying the first data file
  • An extracting module configured to extract at least one query item from a query condition of the query request
  • An information obtaining module configured to acquire data row indication information corresponding to each query item, where the data row indication information is used to indicate a data row where data corresponding to the query item corresponding to the data row indication information is located;
  • the index construction module is configured to store the query items and the data row indication information corresponding to the query items in an index file of the first data file.
  • a query apparatus including:
  • a receiving module configured to receive a query request currently used to query the first data file
  • An extracting module configured to extract at least one query item from a query condition of the query request
  • a rewriting module configured to: according to an existing query item stored in an index file of the first data file and data row indication information corresponding to the existing query item, a query item that can be rewritten among the at least one query item Performing rewriting; the data row indication information is used to indicate a data row in which data of the existing query item is satisfied;
  • the querying module is configured to perform a query in the first data file to obtain data to be queried according to the rewritten query item and the unrewritten query item in the at least one query item.
  • the present invention extracts a query item from a query condition of a query request, and obtains data row indication information for indicating a data row in which the data of the query item is located, and further includes data row indication information corresponding to the query item and the query item.
  • the index of the data file is stored in the index file, the index construction process does not depend on the data layout in the data file, so the existing data layout is not destroyed, and the implementation is relatively simple.
  • the present invention searches for existing query items and existing query items stored in the index file.
  • the data line indication information should be rewritten to the query items that can be rewritten in the current query condition, so that the rewritten query condition becomes relatively simple, and the number of IOs can be reduced, which is beneficial to improve the query efficiency.
  • FIG. 1 is a schematic flowchart diagram of an index construction method according to an embodiment of the present invention
  • FIG. 2 is a schematic flowchart of a query method according to another embodiment of the present invention.
  • FIG. 3 is a schematic diagram showing the comparison between the effect of the present invention and an existing query method according to another embodiment of the present invention
  • FIG. 4 is a schematic diagram showing the comparison between the effect of the present invention and a service similar system according to another embodiment of the present invention.
  • FIG. 5 is a schematic structural diagram of an index construction apparatus according to another embodiment of the present invention.
  • FIG. 6 is a schematic structural diagram of a query apparatus according to another embodiment of the present invention.
  • FIG. 7 is a schematic structural diagram of a query apparatus according to another embodiment of the present invention.
  • FIG. 1 is a schematic flowchart diagram of an index construction method according to an embodiment of the present invention. As shown in Figure 1, the method includes:
  • the index construction method provided in this embodiment can be used to build an index for any data file.
  • the data file that needs to be indexed is referred to as a first data file in this embodiment, and the “first” here has neither concept of sequence. There is also no concept of quantity.
  • the first data file is a columnar storage file in columns.
  • the embodiment provides a method for constructing an index for the first data file.
  • the embodiment does not depend on the first in the process of constructing the index.
  • the data layout of the data file is obtained by extracting the query item from the query condition of the query request, obtaining data row indication information for indicating the data row of the data satisfying the query item, and indicating the data row corresponding to the query item and the query item.
  • the index file forming the first data file as an index makes the index construction process not depend on the data layout of the first data file, overcomes the defects of the existing adaptive indexing technology, and reduces the cost of index construction.
  • the embodiment builds an index based on the user's query request according to the user behavior characteristics and habits. Therefore, first, the query request for querying the first data file needs to be obtained.
  • index construction The purpose of index construction is to meet the needs of users to quickly query data. Users with different levels of requirements have different requirements for query speed, which means that users with different levels of requirements can be built to match their needs. For example, if a user needs attention With recent data, and the index being built is not updated in time, users will not be able to quickly query the required data. Build different levels of indexing, the query requests required as raw materials are also different in timeliness and scale.
  • a period of time may be preset, which is recorded as a first specified period of time, for example, one month, three months or even longer.
  • a query request for querying the first data file by different users in the first specified time period may be obtained, and the query requests may constitute a query sequence.
  • the query sequence including the historical query request, also includes the current query request. According to these query requests, the index construction can be performed offline. This method is more suitable for application scenarios where the number of queries is small and the timeliness and query speed requirements are not very high.
  • a period of time may be preset, which is recorded as a second specified period of time, for example, a short period of time such as one week, three days, or five days.
  • a query request for querying the first data file by different users in the second specified time period may be obtained, and the query requests may be configured as a query sequence.
  • the query sequence including the historical query request, also includes the current query request.
  • the index construction can be performed in an offline manner. This method is more suitable for application scenarios with relatively high number of queries and high requirements on timeliness and query speed.
  • the query request of the current user requesting to query the first data file may be obtained, and the query may be performed in an online manner according to the query request. This method is more suitable for an application scenario that requires real-time query data.
  • the above query request may be from different users or may be from the same user.
  • the query request is generally a database statement written by various database languages. Taking SQL as an example, a query request may be similar.
  • the query condition in the query request of select..from table where C2>0 is C2>0, indicating that the data of the second column data greater than 0 needs to be acquired.
  • the query condition is composed of logical operators connected to multiple simple conditions. Common logical operators include: and (logical AND), or (logical OR), not (logical NOT), and so on. For example, suppose a query request is: select count(*)as result from table where C1 contains'A'and C2>0, where the query condition is: C1 contains'A'and C2>0, and the logical operator is "and" ".
  • a method for extracting a query item may be: using a logical operator in the query condition as a separator, and extracting each part of the query condition separated by the separator as a query item.
  • a logical operator in the query condition as a separator
  • extracting each part of the query condition separated by the separator as a query item.
  • “and” can be used as a separator
  • C1 contains 'A'" and "C2>0" separated by "and” are all query items.
  • the query condition does not include any logical operators, it means that the query condition itself only contains a part, and the query condition can be directly used as the query item. For example, select....from table where C2>0 is the query condition in the query request is C2>0, and C2>0 is a query item.
  • the query item of this embodiment generally includes: a name, an operator, and a target value of the data column.
  • C1 represents the name of the data column, contains is the operator, and 'A' is the target value;
  • C2 represents the data column.
  • the name, > is the operator, and 0 is the target value.
  • this embodiment does not limit the types of operators in the query item, such as arithmetic operators, join operators, relational operators, assignment operators, and logical operators. Any of the operators that are suitable as query conditions.
  • a manner of obtaining the data line indication information corresponding to each query item includes:
  • the data column corresponding to each query item that is, the data column identified by the name of the data column, for example, the query item "C1contains'A'"
  • the data column is the C1 column
  • the data column corresponding to the query item "C2>0" is the C2 column;
  • the data row corresponding to the data of the corresponding query item in each data column corresponding to each query item may be determined according to the operator and the target value in each query item; and then, according to each query
  • the data row corresponding to the data of the corresponding query item in the data column corresponding to the item generates the data line indication information corresponding to each query item. For example, taking the C2 column as an example, suppose that the C2 column includes: 0, 3, 4, 0, -1, -1, and 9, corresponding to the 1st to 7th rows, respectively, it can be determined that the query item "C2>0" is satisfied.
  • the data behavior of the data is in line 2, line 3, and line 7, so that data lines 2, 3, and 7 of the data behavior indicating that the data satisfying the query item "C2>0" is present can be generated.
  • the data line indicates the information.
  • the data line indication information may be a binary sequence 0110001, where a bit having a value of 1 represents a data line in which the data satisfying the query item "C2>0" is located.
  • each query item and the data row indication information corresponding to each query item may be stored as an index into an index file of the first data file.
  • the index file organizes and manages each query item and the data row indication information corresponding to each query item based on the data column, that is, the query item corresponding to the same data column and the data row indication information corresponding to the query item.
  • the data line indication information corresponding to the query item and the query item corresponding to each data column is stored in the order of the number of the data columns.
  • the query items corresponding to the same data column and the data line indication information corresponding to the query item may be sequentially stored according to the size of the target value.
  • the corresponding storage area may be first determined according to the data column, and then the search is performed in the determined area, thereby reducing the query range and facilitating the improvement.
  • the efficiency of the use of index files may be first determined according to the data column, and then the search is performed in the determined area, thereby reducing the query range and facilitating the improvement.
  • an implementation manner of storing the data line indication information corresponding to each query item and each query item in the index file of the first data file includes:
  • a query item corresponding to the same data column is determined from each query item, and data row indication information corresponding to the query item corresponding to the same data column is determined from the data row indication information corresponding to each query item;
  • the query items corresponding to the same data column and the data line indication information corresponding to the query items corresponding to the same data column are sequentially stored according to the size of the target value.
  • the data line indication information corresponding to the query item and the query item is stored in the above manner, and the index file shown in Table 2 below can be obtained, but is not limited thereto.
  • each query item is sequentially stored in descending order of the target value.
  • a storage rule of the query item including the relational operator is pre-defined, that is, the query item including the relational operator can only be preset according to the preset Rules are stored.
  • the specific storage rule is: for the operator with the inverse relationship in the relational operator, the provisions are specified. Store according to one of the operators. The following is a detailed description:
  • the data row indication information corresponding to each query item and each query item needs to be pre-processed or corrected. deal with.
  • each query item it is required to determine whether the operator in the query item belongs to a relational operator
  • the pre-processing operation of the query item is ended, and the data item indication information corresponding to the query item and the query item may be directly stored in the first data file.
  • the index file In the index file;
  • the data line corresponding to C2>5" indicates the information "0000001".
  • the type of the query item is more.
  • the logical storage structure of the data will affect the query efficiency of the data to a certain extent. Therefore, for different types of query items, when stored as an index into the index file, the logical storage structure can be used to improve the data query efficiency. .
  • each query item may be determined according to the type of the operator and/or the target value in each query item.
  • a logical storage structure such as a bit-map can be used.
  • a logical storage structure of bit-map is generally applicable to an arithmetic type query item; if the operator in the query item belongs to a set Types, such as operators are in or contain, not in or not contain, within (in), etc., generally can use the logical storage structure of inverted index, that is, inverted index
  • a logical storage structure is generally applicable to a query item of a collection type; if the target value in the query item belongs to a numeric type, such as a floating point type or an interval type, a logical storage structure of a binary tree can generally be used, that is, a binary tree Logical storage structures are generally suitable for query items that involve range or floating point types.
  • each query item and each query may be performed according to a logical storage structure applicable to each query item.
  • the data row indication information corresponding to the item is stored in the index file of the first data file.
  • the index file of the first data file can be written to the disk medium independent of the first data file through the IO interface.
  • the first data file may be cut into multiple data blocks and distributed on different storage nodes.
  • the index file of the first data file can also be divided into index file segments corresponding to each data block, and distributed on different disk media. In actual use, it is preferable to load only the index file fragments corresponding to the corresponding data block into the memory without loading all the index file fragments.
  • an index file that is independent of the first data file can also store multiple, for example, three copies, which can reduce the probability of index file corruption due to factors such as downtime in the update indexing process or disk corruption.
  • multiple index files can verify the consistency between the data. In actual use, only one index file is loaded into memory, which is used to speed up the query speed of the index.
  • the user will continuously query the first data file, which means that new query requests (specifically, new query items) will continue to appear, so the index file can be continuously updated.
  • the update here includes phasing out obsolete or expired query items and their corresponding data line indications, adding new query items and their corresponding data line indications, and merging new and existing query items. Wait. Among them, in the process of eliminating the query items, the Least Recently Used (LRU) strategy can be adopted.
  • LRU Least Recently Used
  • the query request used to build the index file includes Q0, Q1, Q2, and Q3, in which:
  • the index file of the first data file is null (null) in the initial stage; when Q0 is obtained, the query item "C2>0" is extracted from Q0, and it is determined that the query item "C2>0" is satisfied.
  • the data row where the data is located, and then the data row indication information is generated, and the query item "C2>0" and the corresponding data row indication information are stored in the index file.
  • the index file at this time is as shown in Table 3 below.
  • the bit-map data storage structure is used in this example.
  • obtain Q1 extract the query item "C2>5" from Q1, determine the data row where the data satisfying the query item "C2>5" is located, and then generate data row indication information, and query item "C2>5" And the corresponding data line indication information is stored in the index file, and the index file at this time is as shown in Table 4 below.
  • obtain Q2 extract the query item "C1 contains'A' from Q2, determine the data line where the data satisfying the query item "C1 contains'A'” is located, and then generate data line indication information, and query items "C1 contains 'A'" and the corresponding data line indication information are stored in the index file, and the index file at this time is as shown in Table 5 below.
  • C2>5 C1 contains ‘A’ 0 0 1 1 0 1 1 0 0 0 0 0 0 0 0 1 0 0 0 1 1 0 0 0 1 1 0
  • the query item existing in the index file is duplicated.
  • the inverted operation may be performed on the extracted query items, and the inverted query items are matched in the index file; if the inverted query item is matched in the index file, the processing of the query item is ended. And the process of processing the next query item is entered; if the inverted query item is not matched in the index file, the data line indication information corresponding to the query item and subsequent operations are continued.
  • the data line indication information corresponding to the query item and the query item in this embodiment is in the Whether the timing can improve the query speed and the process of updating the index file during the application process will be described in the following embodiments.
  • FIG. 2 is a schematic flowchart diagram of a query method according to another embodiment of the present invention. As shown in Figure 2, the method includes:
  • the index file may be pre-built, and then the data query may be performed based on the constructed index file; or the process of constructing the index file may be combined with the data query process, that is, the data query is performed based on the built index file. And constantly improve the index file in the data query process.
  • the index file may be formed in advance offline, or may be formed online during the previous data query process.
  • the data query process based on the index file is specifically as follows: First, the query request currently used to query the first data file is received. In the prior art, when the query request is obtained, it will directly go according to the query condition in the query request. The first data file reads each column data involved in the query condition, and after reading the required column data into the memory, performs data filtering and the like to finally obtain the required data. This involves a lot of IO operations, resulting in less efficient data query.
  • the present embodiment does not directly read the data in the first data file as in the prior art, but extracts at least one query item from the query condition of the query request, and then stores the information according to the index file stored in the first data file. Having the query item and the data row indication information corresponding to the existing query item, rewriting the query item that can be rewritten in the at least one query item, and then according to the rewritten query item and the unrewritten query item in the at least one query item, A query is made in the first data file to obtain data to be queried.
  • the above data line indication information is used to indicate the data line in which the data of the existing query item is satisfied.
  • a columnar storage system that stores in columns, if you know the data row where the data to be queried is located, and further add other conditions, you can lock the data to be queried in a smaller data range, and even determine the data.
  • the precise location in the row and column, which is beneficial to reduce IO operations and improve query efficiency compared to reading all possible data.
  • the query item that can be rewritten is the query item that can be rewritten by using the existing query item stored in the index file and the data line indication information corresponding to the existing query item.
  • the data row indication information indicates the data row in which the data of the existing query item is located, which means that the data query range corresponding to the rewritten query item is greatly reduced, which is beneficial to reducing IO operations and improving query efficiency.
  • step 202 the specific implementation is the same as the corresponding step in the process of constructing the index file, and the description of the corresponding part in the foregoing embodiment is omitted, and details are not described herein again.
  • step 203 may be implemented by using the following implementation manners:
  • the query item For each query item in at least one query item, the query item can be matched in the index file;
  • the query item is rewritten according to the data line indication information corresponding to the matched existing query item.
  • the query item may be rewritten to be a data row indicated by the data row indication information corresponding to the matched existing query item.
  • the rewritten query item directly gives the data row where the data to be queried is located, which can greatly reduce the data range.
  • the data line indication information is directly used to indicate the indicated data line, but is not limited thereto.
  • the rewritten query item clearly defines the data row where the data to be queried is located, and the data to be queried can be directly read from the second, third and seventh rows, and the data range is small. The number of IO operations is relatively small, and the query efficiency is high.
  • the query may be directly performed in the first data file according to each of the rewritten query items to obtain data to be queried.
  • each of the rewritten query items may be combined according to the original logical operation relationship to form a new query condition, and the new query condition is used to query the first data file.
  • the query item before the query item is matched in the index file, it can be determined whether the operator in the query item belongs to the relational operator; when the operator in the query item belongs to the relational operator, further determining the Whether the operator in the query item belongs to a predetermined operator that can be stored in the index file; if the judgment result is no, the operator in the query item does not belong to a predetermined operator that can be stored in the index file. Then, the query item may be reversed to obtain the inverted query item, and then the inverted query item is matched in the index file to determine whether the query item can be rewritten.
  • the data line indicates that the two query items are rewritten.
  • the data line indication information is directly used to indicate the indicated data line, but is not limited thereto.
  • the rewritten query item clearly defines the data row where the data to be queried is located, and can directly read the data to be queried from the second, third and seventh rows.
  • the data range is small, the number of IO operations is relatively small, and the query efficiency is high.
  • the query may be directly performed in the first data file according to each of the rewritten query items to obtain data to be queried.
  • each of the rewritten query items may be combined according to the original logical operation relationship to form a new query condition, and the new query condition is used to query the first data file.
  • the index file does not match the existing query item with the same query item, when the query item represents a numerical range, it can be further determined whether the data range can be matched or included in the index file.
  • An existing query item if the judgment result is yes, meaning that it can match an existing query item whose value range is included or contains the query item, the query item can be split into a rewritable part and a non-rewritable part. And rewriting the rewritable part according to the data row indication information corresponding to the matched existing query item, and using the unrewritable part as a new query item. For example, the rewritable portion may be rewritten to be a data row indicated by the data row indication information corresponding to the matched existing query item.
  • the index file does not match the existing range of the query item that contains or contains the query item, it means that the query item is a new query item and belongs to a non-rewriteable query item.
  • the query item remains as it is.
  • the data row indication information corresponding to the query item can be obtained in the data query process, and then the query item and the data row indication information corresponding to the query item are correspondingly stored in the index file, thereby implementing the index.
  • Update of the file For the process of updating the index file, refer to the description of the foregoing index construction method embodiment, which are substantially the same, and are not described herein again.
  • the inventors of the present invention respectively tested the present invention and the existing query method in a real scene (Gunir system with frequent ad-hoc query), and obtained the effect as shown in FIG. Compare the schematics.
  • the abscissa indicates the number of query requests that gradually increase with time, and the ordinate indicates the time consumed by a single query, in milliseconds.
  • the lower line indicates the present invention
  • the upper line indicates the existing query method. It can be seen from FIG. 3 that the present invention is obviously superior to the existing query method in terms of query speed.
  • the index file is continuously updated and improved, so that the query speed is further improved, and finally the orientation is converged.
  • the inventor of the present invention also uses the internationally accepted TPC-H benchmark to compare and test the present invention with the same system in the industry (w/B-Tree scheme in the MySQL system).
  • a comparison diagram of the effects as shown in FIG. 4 is obtained.
  • the abscissa indicates the number of query requests that gradually increase with time, and the ordinate indicates the time consumed by a single query, in milliseconds.
  • the lower line indicates the present invention, and the upper line indicates a service similar system. It can be seen from FIG. 4 that the present invention is obviously superior to the similar system in the industry in terms of query speed.
  • the index file is continuously updated and improved, so that the query speed is further improved, and finally the orientation is converged.
  • FIG. 5 is a schematic structural diagram of an index construction apparatus according to another embodiment of the present invention. As shown in FIG. 5, the apparatus includes a request acquisition module 51, an extraction module 52, an information acquisition module 53, and an index construction module 54.
  • the request obtaining module 51 is configured to obtain a query request for querying the first data file.
  • the extracting module 52 is configured to extract at least one query item from the query condition of the query request.
  • the information obtaining module 53 is configured to obtain data row indication information corresponding to each query item, where the data row indication information is used to indicate a data row in which data corresponding to the query item corresponding to the data row indication information is located.
  • the index construction module 54 is configured to store the query items and the data row indication information corresponding to the query items in an index file of the first data file.
  • the extraction module 52 is specifically configured to:
  • the logical operator in the query condition is used as a separator, and each part of the query condition divided by the separator is extracted as the query item.
  • each query item includes a name, an operator, and a target value of the data column. Based on this, the information obtaining module 53 is specifically configured to:
  • the index building module 54 is specifically configured to:
  • the data row indication information corresponding to the query item corresponding to the same data column and the query item corresponding to the same data column are sequentially stored according to the size of the target value.
  • the index construction module 54 is further configured to: before the data row indication information corresponding to the query items and the query items are correspondingly stored in an index file of the first data file, execute The following operations:
  • the data item indication information corresponding to the query item and the query item is reversed to obtain the inverted query item and the data line indication corresponding to the inverted query item. information.
  • the index construction module 54 is configured to store the inverted query item and the data row indication information corresponding to the inverted query item in an index file.
  • the index building module 54 is specifically configured to:
  • the index construction apparatus extracts a query item from the query condition of the query request, and obtains data row indication information for indicating the data row of the data satisfying the query item, and further indicates the data row corresponding to the query item and the query item.
  • the information is stored in the index file as an index of the data file.
  • the index construction process does not depend on the data layout in the data file, so the existing data layout is not destroyed, and the implementation is relatively simple, which provides conditions for improving query efficiency.
  • FIG. 6 is a schematic structural diagram of a query apparatus according to another embodiment of the present invention.
  • the querying device includes: a receiving module 61, an extracting module 62, a rewriting module 63, and a query module 64.
  • the receiving module 61 is configured to receive a query request currently used to query the first data file.
  • the extracting module 62 is configured to extract at least one query item from the query condition of the query request.
  • the rewriting module 63 is configured to query the at least one query item that can be rewritten according to the existing query item stored in the index file of the first data file and the data line indication information corresponding to the existing query item. The item is rewritten; the data line indication information is used to indicate a data line in which the data of the existing query item is satisfied.
  • the querying module 64 is configured to perform a query in the first data file to obtain data to be queried according to the rewritten query item and the unrewritten query item in the at least one query item.
  • the rewriting module 63 is specifically configured to:
  • the query item is rewritten according to the data line indication information corresponding to the matched existing query item.
  • the rewriting module 63 is further configured to:
  • the existing query item that is the same as the query item is not matched in the index file, when the query item represents a numerical range, it is determined whether the data range can be matched in the index file by the query item.
  • the query item is split into a rewritable part and a non-rewritable part according to the value range represented by the matched existing query item and the numerical range represented by the query item, and according to the The data row indication information corresponding to the matched existing query item is performed on the rewritable portion, and the non-rewritable portion is used as a new query item.
  • the querying device further includes: an updating module 64.
  • the update module 64 is configured to: when the determination result is negative, acquire the data row indication information corresponding to the query item, and store the query item and the data row indication information corresponding to the query item correspondingly to the index file. .
  • the query device provided in this embodiment may perform data query based on the index file provided in the foregoing embodiment.
  • the indication information rewrites the query item that can be rewritten in the current query condition, so that the rewritten query condition becomes relatively simple, and the number of IO times can be reduced, which is beneficial to improving the query efficiency.
  • the disclosed system, apparatus, and method may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • there may be another division manner for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in an electrical, mechanical or other form.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
  • each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or in the form of hardware plus software functional units.
  • the above-described integrated unit implemented in the form of a software functional unit can be stored in a computer readable storage medium.
  • the above software functional unit is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor to perform the methods of the various embodiments of the present invention. Part of the steps.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like, which can store program codes. .

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)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)

Abstract

一种索引构建方法、查询方法及装置、设备、计算机存储介质,在索引构建过程中,从查询请求的查询条件中提取查询项,获取用于指示满足查询项的数据所在数据行的数据行指示信息,将查询项及对应的数据行指示信息作为索引存储到索引文件中,由于不依赖于数据文件中的数据布局,因此不会破坏现有的数据布局,实现相对简单。另外,在使用索引文件进行数据查询过程中,根据索引文件中存储的已有查询项和已有查询项对应的数据行指示信息,对当前查询条件中能够被改写的查询项进行改写,使得改写后的查询条件变得相对简单,可以减少IO次数,有利于提高查询效率。

Description

索引构建方法、查询方法及对应装置、设备、计算机存储介质
本申请要求了申请日为2015年12月7日,申请号为201510887819.9发明名称为“索引构建方法、查询方法及装置”的中国专利申请的优先权。
技术领域
本发明涉及数据库技术领域,尤其涉及一种索引构建方法、查询方法及装置。
背景技术
在现有存储系统中,一种加快数据查询速度的常用而有效的方法是利用数据访问的局部性(Data Locality)来为常用的数据区间建立索引。然而,现有建立索引的方法都需要先验知识,即知道那些属性的数据访问频率高才能建立。同时,索引一旦建立完成,对索引进行更新也是一项异常繁重的工作;同时还伴随着索引与数据、索引与索引之间的一致性等问题。这些问题进一步制约了索引加速数据访问的灵活性和可扩展性,也提高了索引的使用成本。
针对上述问题,出现了自适应索引技术(Adaptive Indexing)。一种自适应索引技术具体为:根据用户的查询序列,将数据分裂成不同的数据片,并通过交换排序来逐步形成分片有序(即索引),进而为后续用户的查询提供加速条件。另一种自适应索引技术具体为:将每个记录数据视为孤立的数据点,随着用户查询请求的不断到来,符合用户查询需求的数据点自动聚合(Merging)在一起,逐步形成分片有序(即索引),进而为后续用户的查询提供加速条件。
在上述自适应索引技术中,均需要挪动数据的物理位置。而在百TB 级到PB级别的大型存储系统中,数据被切成多个数据块(Data Block),分布在不同的存储节点上;而且,为了容错,每个数据块都多个副本。在这样的场景下移动数据需要跨越分布在不同网络区域的存储节点才能完成,而且需要同时修改多个副本,实现代价极高,可行性较差。
发明内容
本发明的多个方面提供一种索引构建方法、查询方法及装置,用以为大数据存储系统创建索引,提高查询效率。
本发明的一方面,提供一种索引构建方法,包括:
获取用于查询第一数据文件的查询请求;
从所述查询请求的查询条件中提取至少一个查询项;
获取各查询项对应的数据行指示信息,所述数据行指示信息用于指示满足所述数据行指示信息对应查询项的数据所在的数据行;
将所述各查询项以及所述各查询项对应的数据行指示信息对应存储在所述第一数据文件的索引文件。
本发明的另一方面,提供一种查询方法,包括:
接收当前用于查询第一数据文件的查询请求;
从所述查询请求的查询条件中提取至少一个查询项;
根据所述第一数据文件的索引文件中存储的已有查询项和所述已有查询项对应的数据行指示信息,对所述至少一个查询项中能够被改写的查询项进行改写;所述数据行指示信息用于指示满足所述已有查询项的数据所在的数据行;
根据所述至少一个查询项中被改写的查询项和未被改写的查询项,在所述第一数据文件中进行查询,以获取待查询的数据。
本发明的又一方面,提供一种搜索构建装置,包括:
请求获取模块,用于获取用于查询第一数据文件的查询请求;
提取模块,用于从所述查询请求的查询条件中提取至少一个查询项;
信息获取模块,用于获取各查询项对应的数据行指示信息,所述数据行指示信息用于指示满足所述数据行指示信息对应查询项的数据所在的数据行;
索引构建模块,用于将所述各查询项以及所述各查询项对应的数据行指示信息对应存储在所述第一数据文件的索引文件。
本发明的又一方面,提供一种查询装置,包括:
接收模块,用于接收当前用于查询第一数据文件的查询请求;
提取模块,用于从所述查询请求的查询条件中提取至少一个查询项;
改写模块,用于根据所述第一数据文件的索引文件中存储的已有查询项和所述已有查询项对应的数据行指示信息,对所述至少一个查询项中能够被改写的查询项进行改写;所述数据行指示信息用于指示满足所述已有查询项的数据所在的数据行;
查询模块,用于根据所述至少一个查询项中被改写的查询项和未被改写的查询项,在所述第一数据文件中进行查询,以获取待查询的数据。
由上述技术方案可知,本发明从查询请求的查询条件中提取查询项,获取用于指示满足查询项的数据所在数据行的数据行指示信息,进而将查询项及查询项对应的数据行指示信息作为该数据文件的索引存储到索引文件中,该索引构建过程不依赖于数据文件中的数据布局,因此不会破坏现有的数据布局,实现相对简单。另外,本发明在使用索引文件进行数据查询过程中,根据索引文件中存储的已有查询项和已有查询项对 应的数据行指示信息,对当前查询条件中能够被改写的查询项进行改写,使得改写后的查询条件变得相对简单,可以减少IO次数,有利于提高查询效率。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明一实施例提供的索引构建方法的流程示意图;
图2为本发明另一实施例提供的查询方法的流程示意图;
图3为本发明又一实施例提供的本发明与现有查询方法的效果对比示意图;
图4为本发明又一实施例提供的本发明与业务同类系统的效果对比示意图;
图5为本发明又一实施例提供的索引构建装置的结构示意图;
图6为本发明又一实施例提供的查询装置的结构示意图;
图7为本发明又一实施例提供的查询装置的结构示意图。
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚,下面结合附图和具体实施例对本发明进行详细描述。
图1为本发明一实施例提供的索引构建方法的流程示意图。如图1所示,该方法包括:
101、获取用于查询第一数据文件的查询请求。
102、从查询请求的查询条件中提取至少一个查询项。
103、获取各查询项对应的数据行指示信息,该数据行指示信息用于指示满足该数据行指示信息对应的查询项的数据所在的数据行。
104、将上述各查询项以及各查询项对应的数据行指示信息对应存储在第一数据文件的索引文件中。
本实施例提供的索引构建方法可用于为任意数据文件构建索引,为便于描述,本实施例将需要构建索引的数据文件称为第一数据文件,这里的“第一”既没有先后顺序的概念,也没有数量的概念。优选的,第一数据文件为以列为单位的列式存储文件。
为加快对第一数据文件的查询速度,本实施例提供一种为第一数据文件构建索引的方法。为了在为第一数据文件构建索引的过程中不影响第一数据文件中数据的布局,例如不移动数据的物理位置,降低构建索引的代价,本实施例在构建索引过程中不依赖于第一数据文件的数据布局,而是通过从查询请求的查询条件中提取查询项,获取用于指示满足查询项的数据所在数据行的数据行指示信息,将查询项和查询项对应的数据行指示信息作为索引形成第一数据文件的索引文件,使得索引构建过程不依赖于第一数据文件的数据布局,克服现有自适应索引技术存在的缺陷,降低索引构建的代价。
具体的,本实施例根据用户行为特征与习惯,基于用户的查询请求构建索引,因此,首先需要获取用于查询第一数据文件的查询请求。
索引构建的目的是为了满足用户快速查询数据的需求。不同需求层次的用户,其对查询速度的要求有所不同,这意味着,可以为不同需求层次的用户构建与其需求相适应的索引。例如,如果一个用户需要关注 近期的数据,而所构建的索引未及时更新,则用户将无法快速查询到所需数据。构建不同层次的索引,所需的作为原材料的查询请求在时效性、规模上也有所不同。
在一可选实施方式中,可以预先设定一时间段,记为第一指定时间段,例如可以是一个月、三个月甚至更长时间。可以获取第一指定时间段内不同用户请求查询第一数据文件的查询请求,这些查询请求可构成以查询序列。在该查询序列中,包括历史查询请求,也包括当前查询请求。根据这些查询请求可以采用离线方式进行索引构建,这种方式更加适用于查询次数较少,对时效性和查询速度要求均不是很高的应用场景。
在一可选实施方式中,可以预先设定一时间段,记为第二指定时间段,例如可以是一个周、三天或五天等较短时间。可以获取第二指定时间段内不同用户请求查询第一数据文件的查询请求,这些查询请求可构成以查询序列。在该查询序列中,包括历史查询请求,也包括当前查询请求。根据这些查询请求可以采用离线方式进行索引构建,这种方式更加适用于查询次数相对较多,对时效性和查询速度要求较高的应用场景。
在一可选实施方式中,可以获取当前用户请求查询第一数据文件的查询请求,根据这些查询请求可以采用在线方式实时进行索引构建,这种方式更加适用于需要实时查询数据的应用场景。
另外,根据第一数据文件面向用户的不同,上述查询请求可以来自不同用户,也可以来自同一用户。
无论是哪种需求层次,在获取查询请求之后,可以从查询请求的查询条件中提取至少一个查询项。在本实施例中,查询请求一般是由各种数据库语言编写的数据库语句,以SQL为例,一种查询请求可以是类似 select….from table where….的结构。其中,select后面的“……”表示待查询数据,而where后面的“……”表示查询条件。例如,select….from table where C2>0这一查询请求中的查询条件为C2>0,表示需要获取第二列数据大于0的数据。
一般情况下,查询条件会由逻辑运算符连接多个简单的条件构成。常见的逻辑运算符包括:and(逻辑与)、or(逻辑或)、not(逻辑非)等。例如,假设一查询请求为:select count(*)as result from table where C1 contains‘A’and C2>0,其中,查询条件为:C1 contains‘A’and C2>0,逻辑运算符为“and”。
基于上述,一种提取查询项的方式可以是:将查询条件中的逻辑运算符作为分隔符,提取查询条件中被分隔符分割出的各部分作为查询项。例如,以上述查询条件为例,则可以将“and”作为分隔符,则由“and”分割出的“C1 contains‘A’”和“C2>0”均为查询项。
在此说明,若查询条件未包括任何逻辑运算符,意味着该查询条件本身只包含一部分,可以直接将查询条件作为查询项。例如,select….from table where C2>0这一查询请求中的查询条件为C2>0,该C2>0即为一查询项。
由上述可见,本实施例的查询项一般包括:数据列的名称、运算符和目标数值。例如,查询项“C1 contains‘A’”中,C1表示数据列的名称,contains为运算符,而‘A’为目标数值;相应的,查询项“C2>0”中,C2表示数据列的名称,>为运算符,而0为目标数值。
值得说明的是,本实施例并不限定查询项中运算符的类型,例如可以是算术运算符、连接运算符、关系运算符、赋值运算符和逻辑运算符 等中任意适于作为查询条件的运算符。
基于上述查询项的数据格式,一种获取各查询项对应的数据行指示信息的方式包括:
根据各查询项中数据列的名称,从第一数据文件中读取各查询项对应的数据列,亦即该数据列的名称所标识的数据列,例如查询项“C1contains‘A’”对应的数据列即为C1列,查询项“C2>0”对应的数据列即为C2列;
在读取各查询项对应的数据列之后,可以根据各查询项中的运算符和目标数值,确定各查询项对应的数据列中满足相应查询项的数据所在的数据行;之后,根据各查询项对应的数据列中满足相应查询项的数据所在的数据行,生成各查询项对应的数据行指示信息。例如,以C2列为例,假设C2列包括:0,3,4,0,-1,-1,9,分别对应第1行至第7行,则可以确定满足查询项“C2>0”的数据所在的数据行为第2行、第3行和第7行,于是可以生成用于指示满足查询项“C2>0”的数据所在的数据行为第2行、第3行和第7行的数据行指示信息。例如,该数据行指示信息可以是二进制序列0110001,其中取值为1的位代表满足查询项“C2>0”的数据所在的数据行。
在获得各查询项以及各查询项对应的数据行指示信息之后,可以将各查询项以及各查询项对应的数据行指示信息作为索引存储到第一数据文件的索引文件中。
在一可选实施方式中,索引文件以数据列为依据对各查询项以及各查询项对应的数据行指示信息进行组织管理,即将对应相同数据列的查询项以及查询项对应的数据行指示信息存储在同一区域内。优选的,可 以按照数据列的编号由大到小的顺序,对对应各数据列的查询项及查询项对应的数据行指示信息进行存储。另外,在同一区域内,对应相同数据列的查询项及查询项对应的数据行指示信息可以按照目标数值的大小依次存储。基于这种有序有规则的索引存储方式,在查询索引文件的过程中,可以首先根据数据列确定对应的存储区域,然后在所确定的区域内进行查找,这样可以减少查询范围,有利于提高索引文件的使用效率。
基于上述,一种将各查询项以及各查询项对应的数据行指示信息对应存储在第一数据文件的索引文件的实施方式包括:
首先,从各查询项中,确定对应相同数据列的查询项,并从各查询项对应的数据行指示信息中,确定对应相同数据列的查询项对应的数据行指示信息;
将各查询项中对应相同数据列的查询项以及对应相同数据列的查询项对应的数据行指示信息存储在索引文件的同一区域内;
在同一区域内,对应相同数据列的查询项以及对应相同数据列的查询项对应的数据行指示信息按照目标数值的大小依次存储。
以如下表1所示为第一数据文件,则按照上述方式存储查询项及查询项对应的数据行指示信息后,可以得到如下表2所示的索引文件,但不限于此。
表1
C1 C2
A:B 0
A 3
B 4
B:C 0
A:B:C -1
C:D -1
C 9
表2
Figure PCTCN2016089484-appb-000001
在表2中,左侧3列是存储数据列C2的区域,右侧两列是存储数据列C1的区域。在存储数据列C2的区域中,各查询项是按照目标数值由小到大的顺序依次进行存储的。
在一可选实施方式中,为了进一步规范索引文件,提高索引文件的使用效率,预先规定了包含关系运算符的查询项的存储规则,即对于包含关系运算符的查询项只能按照预设的规则进行存储。
具体存储规则为:对于关系运算符中具有取反关系的运算符,规定 按照其中一种运算符进行存储。下面进行具体说明:
对于关系运算符中的大于“>”与小于等于“<=”,两者满足取反关系,即对“>”取反可以得到“<=”,本实施例规定只能按照“>”的方式进行存储;意味着,对于包含“<=”的查询项需要通过取反操作转换成包含“>”的查询项进行存储;
对于关系运算符中的等于“==”与不等于“!=”,两者满足取反关系,即对“==”取反可以得到“!=”,本实施例规定只能按照“==”的方式进行存储;意味着,对于包含“!=”的查询项需要通过取反操作转换成包含“==”的查询项进行存储;
对于关系运算符中的小于“<”与大于等于“>=”,两者满足取反关系,即对“<”取反可以得到“>=”,本实施例规定只能按照“>=”的方式进行存储;意味着,对于包含“<”的查询项需要通过取反操作转换成包含“>=”的查询项进行存储。
基于上述,在将各查询项以及各查询项对应的数据行指示信息对应存储在第一数据文件的索引文件之前,需要对各查询项以及各查询项对应的数据行指示信息进行预处理或修正处理。
具体的,对于每个查询项,需要判断该查询项中的运算符是否属于关系运算符;
如果判断出该查询项中的运算符不属于关系运算符,则结束对该查询项的预处理操作,可以直接将该查询项和该查询项对应的数据行指示信息存储到第一数据文件的索引文件中;
如果判断出该查询项中的运算符属于关系运算符,则需要进一步判断该运算符是否属于预先规定的可以存储到索引文件中的运算符;如果 该查询项中的运算符属于预先规定的可以存储到索引文件中的运算符,例如上述规定的“>”、“>=”或“==”,则可以结束对该查询项的预处理操作;如果该查询项中的运算符不属于预先规定的可以存储到索引文件中的运算符,例如可能是“<=”、“!=”或“<”,则可以对该查询项以及该查询项对应的数据行指示信息进行取反操作,以获得取反后的查询项及取反后的查询项对应的数据行指示信息。
举例说明,结合上述表1所示第一数据文件,假设一查询项为C2<=5,查询项“C2<=5”对应的数据行指示信息为一二进制序列“1111110”,经上述判断发现该查询项“C2<=5”中的运算符为“<=”,其属于关系运算符但不属于预设规定可以存储到索引文件中的运算符,于是对查询项“C2<=5”进行取反操作,获得取反后的查询项“C2>5”,并对查询项“C2<=5”对应的数据行指示信息“1111110”进行取反操作,获得取反后的查询项“C2>5”对应的数据行指示信息“0000001”。
在获得取反后的查询项以及取反后的查询项对应的数据行指示信息后,将取反后的查询项以及取反后的查询项对应的数据行指示信息存储到索引文件中,如表2中的查询项“C2>5”所在一列。
在一可选实施方式中,考虑到查询项中运算符的类型较多,导致查询项的类型较多。而数据的逻辑存储结构一定程度上会影响数据的查询效率,因此对于不同类型的查询项,在作为索引被存储到索引文件中时可以使用与其相适应的逻辑存储结构,以便于提高数据查询效率。
基于上述,在将各查询项以及各查询项对应的数据行指示信息对应存储在第一数据文件的索引文件之前,可以根据各查询项中运算符和/或目标数值的类型,确定各查询项适用的逻辑存储结构。例如,若查询 项中的运算符属于算术类型,例如运算符是+(加法符号)、-(减法符号)、*(乘法符号)、/(除法符号)、>、<、>=、<=、==或!=等,一般可以采用位图(bit-map)这种逻辑存储结构,也就是说,bit-map这种逻辑存储结构,一般适用于算术类型的查询项;若查询项中的运算符属于集合类型,例如运算符是in或contain(包含)、not in或not contain(不包含)、within(在…中)等,一般可以采用倒排索引这种逻辑存储结构,也就是说,倒排索引这种逻辑存储结构一般适用于集合类型的查询项;若查询项中的目标数值属于数值型,例如浮点类型或区间类型,一般可以采用二叉树这种逻辑存储结构,也就是说,二叉树这种逻辑存储结构一般适用于涉及区间范围或浮点类型的查询项。
值得说明的是,随着时间的变化,查询项的类型会越来越多,而查询项的类型与逻辑存储结构之间的映射关系也会不断积累和增长。
基于上述,在将各查询项以及各查询项对应的数据行指示信息对应存储在第一数据文件的索引文件的过程中,可以按照各查询项适用的逻辑存储结构,将各查询项以及各查询项对应的数据行指示信息存储到第一数据文件的索引文件中。
进一步,在生成第一数据文件的索引文件之后,可以通过IO接口将索引文件写入独立于第一数据文件的磁盘介质上。
值得说明的是,在实际应用中,第一数据文件可能会被切成多个数据块(Data Block),分布在不同的存储节点上。相应的,第一数据文件的索引文件也可以被切分成对应各数据块的索引文件片段,分布在不同的磁盘介质上。在实际使用时,优选的,可以只加载相应数据块对应的索引文件片段到内存中,而无需加载所有索引文件片段。
另外,在列式存储系统中,为了加强第一数据文件的可靠性,一般会为第一数据文件存储多个副本,例如三个副本,并且不同副本一般存储在不同存储节点上。与此相类似,独立于第一数据文件的索引文件也可以存储多个,例如三个副本,这样可以降低因更新索引过程的宕机、或者磁盘损坏等因素导致索引文件损坏的概率。其中,多个索引文件可以互相校验数据之间的一致性。在实际使用过程中,只有一个索引文件加载到内存,用于加快索引的查询速度。
进一步,用户会不断的对第一数据文件进行查询,这意味着新的查询请求(具体来说是新的查询项)会不断出现,因此,还可以不断地对索引文件进行更新。这里的更新包括淘汰已过时或已失效的查询项及其对应的数据行指示信息,添加新的查询项及其对应的数据行指示信息,以及对新的查询项和已有查询项进行合并等等。其中,在对查询项进行淘汰过程中,可以采用近期最少使用(Least Recently Used,LRU)策略。
以上述表1所示第一数据文件为例,结合实际查询请求详细说明构架索引文件的过程:
假设构建索引文件使用的查询请求依次包括Q0、Q1、Q2和Q3,其中:
Q0:select……from table where C2>0;
Q1:select……from table where C2>5;
Q2:select……from table where C1 contains‘A’;
Q3:select……from table where C2>0 and C2<=5;
假设初始阶段,第一数据文件的索引文件为空(null);当获取到Q0时,从Q0中提取出查询项“C2>0”,确定满足查询项“C2>0”的 数据所在的数据行,然后生成数据行指示信息,将查询项“C2>0”以及对应的数据行指示信息存储到索引文件中,此时的索引文件如下表3所示。在该实例中使用bit-map这一数据存储结构。
表3
C2>0
0
1
1
0
0
0
1
接下来,获取到Q1,从Q1中提取出查询项“C2>5”,确定满足查询项“C2>5”的数据所在的数据行,然后生成数据行指示信息,将查询项“C2>5”以及对应的数据行指示信息存储到索引文件中,此时的索引文件如下表4所示。
表4
C2>0 C2>5
0 0
1 0
1 0
0 0
0 0
0 0
1 1
接下来,获取到Q2,从Q2中提取出查询项“C1 contains‘A’”,确定满足查询项“C1 contains‘A’”的数据所在的数据行,然后生成数据行指示信息,将查询项“C1 contains‘A’”以及对应的数据行指示信息存储到索引文件中,此时的索引文件如下表5所示。
表5
C2>0 C2>5 C1包含(contain)‘A’
0 0 1
1 0 1
1 0 0
0 0 0
0 0 1
0 0 0
1 1 0
接下来,获取到Q3,从Q3中提取出查询项“C2>0”和“C2<=5”,确定满足查询项“C2>0”的数据所在的数据行,然后生成数据行指示信息,将查询项“C2>0”以及对应的数据行指示信息存储到索引文件中,此时,会发现查询项“C2>0”及对应的数据行指示信息已经存在于索引文件中,故可以将其丢弃。而关于查询项“C2<=5”,确定满足查询项 “C2<=5”的数据所在的数据行,然后生成数据行指示信息,将查询项“C2<=5”以及对应的数据行指示信息存储到索引文件中,由于查询项“C2<=5”不符合预设的存储要求,于是可以对查询项“C2<=5”及对应的数据行指示信息进行取反操作,从而获得查询项“C2>5”以及对应的数据行指示信息,此时会发现查询项“C2>5”以及对应的数据行指示信息已经存在于索引文件中,于是可以将其丢弃。在处理完Q0、Q1和Q2之后可以得到如表5所示的索引文件。
另外,在上述处理Q3的过程中可以发现,随着索引文件中查询项及其对应的数据行指示信息的不断逐渐增多,有可能会出现重复的查询项及数据行指示信息,为了节约处理资源,提高构建索引的效率,可以在获取各查询项对应的数据行指示信息之前,先将提取到的各查询项在已构建的索引文件中进行匹配,如果在索引文件中匹配到该查询项,则结束对该查询项的处理并进入对下一个查询项的处理过程;如果在索引文件中未匹配到该查询项,则继续执行获取该查询项对应的数据行指示信息以及后续操作。
进一步,有可能对查询项进行取反操作之后,与索引文件中已有的查询项存在重复,为了节约处理资源,提高构建索引的效率,可以在获取各查询项对应的数据行指示信息之前,可以对提取到的各查询项进行取反操作,将取反后的查询项在索引文件中进行匹配;如果在索引文件中匹配到该取反后的查询项,则结束对该查询项的处理并进入对下一个查询项的处理过程;如果在索引文件中未匹配到该取反后的查询项,则继续执行获取该查询项对应的数据行指示信息以及后续操作。
关于本实施例中的查询项和查询项对应的数据行指示信息在作为索 引时是否能够提高查询速度,以及在应用过程中对索引文件进行更新的过程将在下面实施例中进行描述。
图2为本发明另一实施例提供的查询方法的流程示意图。如图2所示,该方法包括:
201、接收当前用于查询第一数据文件的查询请求。
202、从查询请求的查询条件中提取至少一个查询项。
203、根据第一数据文件的索引文件中存储的已有查询项和已有查询项对应的数据行指示信息,对至少一个查询项中能够被改写的查询项进行改写;所述数据行指示信息用于指示满足已有查询项的数据所在的数据行。
204、根据至少一个查询项中被改写的查询项和未被改写的查询项,在第一数据文件中进行查询,以获取待查询的数据。
本实施例的执行可基于前述各方法实施例给出的索引文件。关于相关数据的定义或解释可参见前述实施例中的描述,在此不再赘述。
在此说明,可以预先构建索引文件,然后基于所构建的索引文件进行数据查询;或者,也可以将构建索引文件的过程与数据查询过程糅合在一起,即基于已构建的索引文件进行数据查询,并在数据查询过程中不断完善索引文件。
在本实施例中,假设在获取当前用于查询第一数据文件的查询请求之前,已经存在索引文件,该索引文件可以是预先离线形成的,也可以是在之前的数据查询过程中在线形成的。则基于索引文件的数据查询过程具体如下:首先,接收当前用于查询第一数据文件的查询请求。在现有技术中,当拿到查询请求后,会直接根据查询请求中的查询条件,去 第一数据文件中读取查询条件涉及的各列数据,当将所需的各列数据读取到内存之后,再进行数据筛选等处理,最终获得所需的数据。这会涉及大量IO操作,导致数据查询效率较低。而本实施例并不像现有技术那样直接去第一数据文件中读取数据,而是从查询请求的查询条件中提取至少一个查询项,然后根据第一数据文件的索引文件中存储的已有查询项和已有查询项对应的数据行指示信息,对至少一个查询项中能够被改写的查询项进行改写,然后根据至少一个查询项中被改写的查询项和未被改写的查询项,在第一数据文件中进行查询,以获得待查询数据。
上述数据行指示信息用于指示满足已有查询项的数据所在的数据行。对于以列为单位进行存储的列式存储系统中,如果知道了待查询数据所在的数据行,进一步加上其它条件,可以将待查询数据锁定在较小的数据范围内,甚至可以确定数据的精确位置(所在行和所在列),这与读取所有可能的数据相比,有利于减少IO操作,有利于提高查询效率。
上述能够被改写的查询项是指能够利用索引文件中存储的已有查询项和已有查询项对应的数据行指示信息进行改写的查询项。而数据行指示信息指示出满足已有查询项的数据所在的数据行,这意味着被改写后的查询项所对应的数据查询范围将极大缩小,有利于减少IO操作,提高查询效率。
关于上述步骤202,其具体实施方式,与构建索引文件过程中的相应步骤相同,可参见前述实施例中相应部分的描述,在此不再赘述。
在一可选实施方式中,上述步骤203具体可采用以下实施方式实现:
对于至少一个查询项中每个查询项,可以将该查询项在索引文件中进行匹配;
如果在索引文件中匹配到与该查询项相同的已有查询项,则根据所述匹配到的已有查询项对应的数据行指示信息对该查询项进行改写。例如,可以将该查询项改写为待查询项数据行等于所述匹配到的已有查询项对应的数据行指示信息所指示的数据行。与改写前的查询项相比,改写后的查询项直接给出待查询数据所在的数据行,其能够极大的减少数据范围。
举例说明,以上述表1所示第一数据文件为例,并结合上述表5所示索引文件,则假设接收到查询请求Q4:select count(*)as result from table where C1 contains‘A’and C2>0,从Q4中提取查询项“C1 contains‘A’”和查询项“C2>0”,通过将两个查询项在表5所示的索引文件中进行比较,发现表5中已经存在这两个查询项,意味着这两个查询项可以被改写,于是根据表5所示索引文件中的已有查询项及其对应的数据行指示信息对这两个查询项进行改写。例如,可以将查询项“C2>0”改写为行号(line)=0110001,将查询项“C1 contains‘A’”改写为line=1100100。这里直接使用数据行指示信息表示所指示的数据行,但不限于此。与“C2>0”这一查询条件相比,改写后的查询项明确限定了待查询数据所在的数据行,可以直接从第2、3和7行中读取待查询数据,数据范围较小,IO操作的次数相对较少,查询效率较高。
在上述举例的查询请求中,不存在未被改写的查询项,则可以直接根据各被改写的查询项在第一数据文件中进行查询,以获得待查询数据。例如,可以将各被改写的查询项按照原来的逻辑运算关系进行组合,以形成新的查询条件,使用新的查询条件到第一数据文件中进行查询。例如,将由查询项“C2>0”改写的line=0110001与由查询项“C1 contains ‘A’”改写的line=1100100进行与运算,从而获得新的查询条件为line=0100000,从而将待查询数据限定在第2行数据中。
进一步,假设接收到查询请求Q5:select……from table where C2>0and C2<=5,从Q5中提取查询项“C2>0”和查询项“C2<=5”,通过将两个查询项在表5所示的索引文件中进行比较,发现表5中已经存在查询项“C2>0”,意味着查询项“C2>0”属于可改写的查询项;而表5中不存在查询项“C2<=5”,但是查询项“C2<=5”取反后得到的查询项“C2>5”存在于表5中,这意味着查询项“C2<=5”实际上也属于可改写的查询项。
在上述分析中发现,在将查询项在索引文件中进行匹配之前,可以判断该查询项中的运算符是否属于关系运算符;当该查询项中的运算符属于关系运算符时,进一步判断该查询项中的运算符是否属于预先规定的可以存储到索引文件中的运算符;若判断结果为否,即该查询项中的运算符不属于预先规定的可以存储到索引文件中的运算符,则可以先对该查询项进行取反操作,以获得取反后的查询项,然后将取反后的查询项在索引文件中进行匹配,以判断该查询项是否可以被改写。
在经过上述匹配操作后,发现查询项“C2>0”和查询项“C2<=5”都属于可改写的查询项,于是根据表5所示索引文件中的已有查询项及其对应的数据行指示信息对这两个查询项进行改写。例如,可以将查询项“C2>0”改写为行号(line)=0110001,将查询项“C2<=5”改写为line=1111110。这里直接使用数据行指示信息表示所指示的数据行,但不限于此。与“C2>0”这一查询条件相比,改写后的查询项明确限定了待查询数据所在的数据行,可以直接从第2、3和7行中读取待查询数据, 数据范围较小,IO操作的次数相对较少,查询效率较高。
在上述举例的查询请求中,不存在未被改写的查询项,则可以直接根据各被改写的查询项在第一数据文件中进行查询,以获得待查询数据。例如,可以将各被改写的查询项按照原来的逻辑运算关系进行组合,以形成新的查询条件,使用新的查询条件到第一数据文件中进行查询。例如,将由查询项“C2>0”改写的line=0110001与由查询项“C2<=5”改写的line=1111110进行与运算,从而获得新的查询条件为line=0110000,从而将待查询数据限定在第2和3行数据中。
进一步,若未在索引文件中匹配到与查询项相同的已有查询项,则当查询项表示数值范围时,可以进一步判断在索引文件中是否能够匹配到数据范围被查询项包含或包含查询项的已有查询项;如果判断结果为是,意味着能够匹配到数值范围被查询项包含或包含该查询项的已有查询项,则可以将该查询项拆分为可改写部分和不可改写部分,并根据所述匹配到的已有查询项对应的数据行指示信息对该可改写部分进行改写,将不可改写部分作为新的查询项。例如,可以将所述可改写部分改写为待查询数据行等于匹配到的已有查询项对应的数据行指示信息所指示的数据行。
结合上述表1所示第一数据文件和表5所示索引文件为例,以查询项“C2>3”为例,在表5中不存在查询项“C2>3”,但是发现数值范围被查询项“C2>3”包含的已有查询项“C2>5”,于是将查询项“C2>3”拆分为可改写部分“C2>5”和不可改写部分“3<C2<=5”,并将可改写部分“C2>5”改写为:line=0000001,而不可改写部分“3<C2<=5”作为新的查询项。与查询项“C2>3”相比,“3<C2<=5”限定的数据范围 相对较小,再加上改写一部分限定的line=0000001可以进一步缩小数据范围,从而有利于减少IO操作,提高查询效率。
值得说明的是,在上述举例中,由于索引文件是按照“>”或“>=”的方式进行存储,所以需要获取数值范围被查询项包含的已有查询项;若索引文件是按照“<”或“<=”的方式进行存储,则需要获取数值范围包含查询项的已有查询项。
进一步,若未能在索引文件中匹配到数值范围被查询项包含或包含该查询项的已有查询项,则意味着该查询项是新的查询项,属于不可改写的查询项,可以将该查询项保持原样,同时,在数据查询过程中可以获取该查询项对应的数据行指示信息,然后将该查询项以及该查询项对应的数据行指示信息对应存储到索引文件中,从而实现对索引文件的更新。关于更新索引文件的过程,可参见前述索引构建方法实施例的描述,其实质相同,在此不再赘述。
为了更加清楚地说明本发明的有益效果,本发明发明人分别对本发明与现有查询方法在真实场景(ad-hoc查询频繁的Gunir系统)中进行了测试,并得到如图3所示的效果对比示意图。在图3中,横坐标表示随着时间逐渐递增的查询请求的数量,而纵坐标表示单次查询消耗的时间,单位为毫秒(milli-seconds)。在图3中,下面一条线表示本发明,上面一条线表示现有查询方法。通过图3可以看出:在查询速度上,本发明明显优于现有查询方法,另外,随着查询请求的不断增多,索引文件不断被更新完善,使得查询速度进一步提高,并最终取向收敛。
另外,本发明发明人还采用国际上通用的TPC-H benchmark对本发明和业界同类系统(MySQL系统中的w/B-Tree方案)进行了对比测试, 得到如图4所示的效果对比示意图。在图4中,横坐标表示随着时间逐渐递增的查询请求的数量,而纵坐标表示单次查询消耗的时间,单位为毫秒(milli-seconds)。在图4中,下面一条线表示本发明,上面一条线表示业务同类系统。通过图4可以看出:在查询速度上,本发明明显优于业界同类系统,另外,随着查询请求的不断增多,索引文件不断被更新完善,使得查询速度进一步提高,并最终取向收敛。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
图5为本发明又一实施例提供的索引构建装置的结构示意图。如图5所示,该装置包括:请求获取模块51、提取模块52、信息获取模块53和索引构建模块54。
请求获取模块51,用于获取用于查询第一数据文件的查询请求。
提取模块52,用于从所述查询请求的查询条件中提取至少一个查询项。
信息获取模块53,用于获取各查询项对应的数据行指示信息,所述数据行指示信息用于指示满足所述数据行指示信息对应查询项的数据所在的数据行。
索引构建模块54,用于将所述各查询项以及所述各查询项对应的数据行指示信息对应存储在所述第一数据文件的索引文件。
在一可选实施方式中,提取模块52具体用于:
以所述查询条件中的逻辑运算符为分隔符,提取所述查询条件中被所述分隔符分割出的各部分作为所述查询项。
在一可选实施方式中,各查询项包括数据列的名称、运算符以及目标数值。基于此,信息获取模块53具体用于:
根据所述各查询项中数据列的名称,从所述第一数据文件中读取所述各查询项对应的数据列;
根据所述各查询项中的运算符和目标数值,确定所述各查询项对应的数据列中满足相应查询项的数据所在的数据行;
根据所述各查询项对应的数据列中满足相应查询项的数据所在的数据行,生成所述各查询项对应的数据行指示信息。
在一可选实施方式中,索引构建模块54具体用于:
将所述各查询项中对应相同数据列的查询项以及所述对应相同数据列的查询项对应的数据行指示信息存储在所述索引文件的同一区域内;
其中,在同一区域内,所述对应相同数据列的查询项以及所述对应相同数据列的查询项对应的数据行指示信息按照目标数值的大小依次存储。
在一可选实施方式中,索引构建模块54还用于:在将所述各查询项以及所述各查询项对应的数据行指示信息对应存储在所述第一数据文件的索引文件之前,执行以下操作:
对于每个查询项,判断所述查询项中的运算符是否属于关系运算符;
当所述查询项中的运算符属于关系运算符时,判断所述查询项中的运算符是否属于预先规定的可以存储到所述索引文件中的运算符;
若判断结果为否,则对所述查询项以及所述查询项对应的数据行指示信息进行取反操作,以获得取反后的查询项以及所述取反后的查询项对应的数据行指示信息。
具体的,索引构建模块54用于将取反后的查询项以及所述取反后的查询项对应的数据行指示信息存储到索引文件中。
在一可选实施方式中,索引构建模块54具体用于:
根据所述各查询项中运算符和/或目标数值的类型,确定所述各查询项适用的逻辑存储结构;
按照所述各查询项适用的逻辑存储结构,将所述各查询项以及所述各查询项对应的数据行指示信息存储到所述第一数据文件的索引文件。
本实施例提供的索引构建装置,从查询请求的查询条件中提取查询项,获取用于指示满足查询项的数据所在数据行的数据行指示信息,进而将查询项及查询项对应的数据行指示信息作为该数据文件的索引存储到索引文件中,该索引构建过程不依赖于数据文件中的数据布局,因此不会破坏现有的数据布局,实现相对简单,为提高查询效率提供了条件。
图6为本发明又一实施例提供的查询装置的结构示意图。如图6所示,该查询装置包括:接收模块61、提取模块62、改写模块63和查询模块64。
接收模块61,用于接收当前用于查询第一数据文件的查询请求。
提取模块62,用于从所述查询请求的查询条件中提取至少一个查询项。
改写模块63,用于根据所述第一数据文件的索引文件中存储的已有查询项和所述已有查询项对应的数据行指示信息,对所述至少一个查询项中能够被改写的查询项进行改写;所述数据行指示信息用于指示满足所述已有查询项的数据所在的数据行。
查询模块64,用于根据所述至少一个查询项中被改写的查询项和未被改写的查询项,在所述第一数据文件中进行查询,以获取待查询的数据。
在一可选实施方式中,改写模块63具体用于:
对于所述至少一个查询项中的每个查询项,将所述查询项在所述索引文件中进行匹配;
若在所述索引文件中匹配到与所述查询项相同的已有查询项,则根据所述匹配到的已有查询项对应的数据行指示信息对所述查询项进行改写。
在一可选实施方式中,改写模块63还用于:
若在所述索引文件中未匹配到与所述查询项相同的已有查询项,当所述查询项表示数值范围时,判断在所述索引文件中是否能够匹配到数据范围被所述查询项包含或包含所述查询项的已有查询项;
若判断结果为是,则根据所述匹配到的已有查询项表示的数值范围和所述查询项表示的数值范围,将所述查询项拆分为可改写部分和不可改写部分,并根据所述匹配到的已有查询项对应的数据行指示信息对所述可改写部分进行,将所述不可改写部分作为新的查询项。
在一可选实施方式中,如图7所示,该查询装置还包括:更新模块64。
更新模块64,用于在上述判断结果为否时,获取所述查询项对应的数据行指示信息,并将所述查询项以及所述查询项对应的数据行指示信息对应存储到所述索引文件。
本实施例提供的查询装置,可基于前述实施例提供的索引文件进行数据查询,在使用索引文件进行数据查询过程中,根据索引文件中存储的已有查询项和已有查询项对应的数据行指示信息,对当前查询条件中能够被改写的查询项进行改写,使得改写后的查询条件变得相对简单,可以减少IO次数,有利于提高查询效率。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本发明所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。
上述以软件功能单元的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。

Claims (24)

  1. 一种索引构建方法,其特征在于,包括:
    获取用于查询第一数据文件的查询请求;
    从所述查询请求的查询条件中提取至少一个查询项;
    获取各查询项对应的数据行指示信息,所述数据行指示信息用于指示满足所述数据行指示信息对应查询项的数据所在的数据行;
    将所述各查询项以及所述各查询项对应的数据行指示信息对应存储在所述第一数据文件的索引文件。
  2. 根据权利要求1所述的方法,其特征在于,所述从所述查询请求的查询条件中提取至少一个查询项,包括:
    以所述查询条件中的逻辑运算符为分隔符,提取所述查询条件中被所述分隔符分割出的各部分作为所述查询项。
  3. 根据权利要求1所述的方法,其特征在于,所述各查询项包括数据列的名称、运算符以及目标数值;
    所述获取各查询项对应的数据行指示信息,包括:
    根据所述各查询项中数据列的名称,从所述第一数据文件中读取所述各查询项对应的数据列;
    根据所述各查询项中的运算符和目标数值,确定所述各查询项对应的数据列中满足相应查询项的数据所在的数据行;
    根据所述各查询项对应的数据列中满足相应查询项的数据所在的数据行,生成所述各查询项对应的数据行指示信息。
  4. 根据权利要求3所述的方法,其特征在于,所述将所述各查询项以及所述各查询项对应的数据行指示信息对应存储在所述第一数据文 件的索引文件,包括:
    将所述各查询项中对应相同数据列的查询项以及所述对应相同数据列的查询项对应的数据行指示信息存储在所述索引文件的同一区域内;
    其中,在同一区域内,所述对应相同数据列的查询项以及所述对应相同数据列的查询项对应的数据行指示信息按照目标数值的大小依次存储。
  5. 根据权利要求3所述的方法,其特征在于,所述将所述各查询项以及所述各查询项对应的数据行指示信息对应存储在所述第一数据文件的索引文件之前,包括:
    对于每个查询项,判断所述查询项中的运算符是否属于关系运算符;
    当所述查询项中的运算符属于关系运算符时,判断所述查询项中的运算符是否属于预先规定的可以存储到所述索引文件中的运算符;
    若判断结果为否,则对所述查询项以及所述查询项对应的数据行指示信息进行取反操作,以获得取反后的查询项以及所述取反后的查询项对应的数据行指示信息。
  6. 根据权利要求1-5任一项所述的方法,其特征在于,所述将所述各查询项以及所述各查询项对应的数据行指示信息对应存储在所述第一数据文件的索引文件之前,还包括:
    根据所述各查询项中运算符和/或目标数值的类型,确定所述各查询项适用的逻辑存储结构;
    所述将所述各查询项以及所述各查询项对应的数据行指示信息对应存储在所述第一数据文件的索引文件,包括:
    按照所述各查询项适用的逻辑存储结构,将所述各查询项以及所述 各查询项对应的数据行指示信息存储到所述第一数据文件的索引文件。
  7. 一种查询方法,其特征在于,包括:
    接收当前用于查询第一数据文件的查询请求;
    从所述查询请求的查询条件中提取至少一个查询项;
    根据所述第一数据文件的索引文件中存储的已有查询项和所述已有查询项对应的数据行指示信息,对所述至少一个查询项中能够被改写的查询项进行改写;所述数据行指示信息用于指示满足所述已有查询项的数据所在的数据行;
    根据所述至少一个查询项中被改写的查询项和未被改写的查询项,在所述第一数据文件中进行查询,以获取待查询的数据。
  8. 根据权利要求7所述的方法,其特征在于,所述根据所述第一数据文件的索引文件中存储的已有查询项和所述已有查询项对应的数据行指示信息,对所述至少一个查询项中能够被改写的查询项进行改写,包括:
    对于所述至少一个查询项中的每个查询项,将所述查询项在所述索引文件中进行匹配;
    若在所述索引文件中匹配到与所述查询项相同的已有查询项,则根据所述匹配到的已有查询项对应的数据行指示信息对所述查询项进行改写。
  9. 根据权利要求8所述的方法,其特征在于,若在所述索引文件中未匹配到与所述查询项相同的已有查询项,所述方法还包括:
    在所述查询项表示数值范围时,判断在所述索引文件中是否能够匹配到数据范围被所述查询项包含或包含所述查询项的已有查询项;
    若判断结果为是,则根据所述匹配到的已有查询项表示的数值范围和所述查询项表示的数值范围,将所述查询项拆分为可改写部分和不可改写部分,并根据所述匹配到的已有查询项对应的数据行指示信息对所述可改写部分进行,将所述不可改写部分作为新的查询项。
  10. 根据权利要求9所述的方法,其特征在于,还包括:
    若判断结果为否,则获取所述查询项对应的数据行指示信息,并将所述查询项以及所述查询项对应的数据行指示信息对应存储到所述索引文件。
  11. 一种索引构建装置,其特征在于,包括:
    请求获取模块,用于获取用于查询第一数据文件的查询请求;
    提取模块,用于从所述查询请求的查询条件中提取至少一个查询项;
    信息获取模块,用于获取各查询项对应的数据行指示信息,所述数据行指示信息用于指示满足所述数据行指示信息对应查询项的数据所在的数据行;
    索引构建模块,用于将所述各查询项以及所述各查询项对应的数据行指示信息对应存储在所述第一数据文件的索引文件。
  12. 根据权利要求11所述的装置,其特征在于,所述提取模块具体用于:
    以所述查询条件中的逻辑运算符为分隔符,提取所述查询条件中被所述分隔符分割出的各部分作为所述查询项。
  13. 根据权利要求11所述的装置,其特征在于,所述各查询项包括数据列的名称、运算符以及目标数值;
    所述信息获取模块具体用于:
    根据所述各查询项中数据列的名称,从所述第一数据文件中读取所述各查询项对应的数据列;
    根据所述各查询项中的运算符和目标数值,确定所述各查询项对应的数据列中满足相应查询项的数据所在的数据行;
    根据所述各查询项对应的数据列中满足相应查询项的数据所在的数据行,生成所述各查询项对应的数据行指示信息。
  14. 根据权利要求13所述的装置,其特征在于,所述索引构建模块具体用于:
    将所述各查询项中对应相同数据列的查询项以及所述对应相同数据列的查询项对应的数据行指示信息存储在所述索引文件的同一区域内;
    其中,在同一区域内,所述对应相同数据列的查询项以及所述对应相同数据列的查询项对应的数据行指示信息按照目标数值的大小依次存储。
  15. 根据权利要求13所述的装置,其特征在于,所述索引构建模块还用于:
    对于每个查询项,判断所述查询项中的运算符是否属于关系运算符;
    当所述查询项中的运算符属于关系运算符时,判断所述查询项中的运算符是否属于预先规定的可以存储到所述索引文件中的运算符;
    若判断结果为否,则对所述查询项以及所述查询项对应的数据行指示信息进行取反操作,以获得取反后的查询项以及所述取反后的查询项对应的数据行指示信息。
  16. 根据权利要求11-15任一项所述的装置,其特征在于,所述索引构建模块具体用于:
    根据所述各查询项中运算符和/或目标数值的类型,确定所述各查询项适用的逻辑存储结构;
    按照所述各查询项适用的逻辑存储结构,将所述各查询项以及所述各查询项对应的数据行指示信息存储到所述第一数据文件的索引文件。
  17. 一种查询装置,其特征在于,包括:
    接收模块,用于接收当前用于查询第一数据文件的查询请求;
    提取模块,用于从所述查询请求的查询条件中提取至少一个查询项;
    改写模块,用于根据所述第一数据文件的索引文件中存储的已有查询项和所述已有查询项对应的数据行指示信息,对所述至少一个查询项中能够被改写的查询项进行改写;所述数据行指示信息用于指示满足所述已有查询项的数据所在的数据行;
    查询模块,用于根据所述至少一个查询项中被改写的查询项和未被改写的查询项,在所述第一数据文件中进行查询,以获取待查询的数据。
  18. 根据权利要求17所述的装置,其特征在于,所述改写模块具体用于:
    对于所述至少一个查询项中的每个查询项,将所述查询项在所述索引文件中进行匹配;
    若在所述索引文件中匹配到与所述查询项相同的已有查询项,则根据所述匹配到的已有查询项对应的数据行指示信息对所述查询项进行改写。
  19. 根据权利要求18所述的装置,其特征在于,所述改写模块还用于:
    若在所述索引文件中未匹配到与所述查询项相同的已有查询项,当 所述查询项表示数值范围时,判断在所述索引文件中是否能够匹配到数据范围被所述查询项包含或包含所述查询项的已有查询项;
    若判断结果为是,则根据所述匹配到的已有查询项表示的数值范围和所述查询项表示的数值范围,将所述查询项拆分为可改写部分和不可改写部分,并根据所述匹配到的已有查询项对应的数据行指示信息对所述可改写部分进行,将所述不可改写部分作为新的查询项。
  20. 根据权利要求19所述的装置,其特征在于,还包括:
    更新模块,用于在判断结果为否时,获取所述查询项对应的数据行指示信息,并将所述查询项以及所述查询项对应的数据行指示信息对应存储到所述索引文件。
  21. 一种设备,包括
    一个或者多个处理器;
    存储器;
    一个或者多个程序,所述一个或者多个程序存储在所述存储器中,当被所述一个或者多个处理器执行时:
    获取用于查询第一数据文件的查询请求;
    从所述查询请求的查询条件中提取至少一个查询项;
    获取各查询项对应的数据行指示信息,所述数据行指示信息用于指示满足所述数据行指示信息对应查询项的数据所在的数据行;
    将所述各查询项以及所述各查询项对应的数据行指示信息对应存储在所述第一数据文件的索引文件。
  22. 一种设备,包括
    一个或者多个处理器;
    存储器;
    一个或者多个程序,所述一个或者多个程序存储在所述存储器中,当被所述一个或者多个处理器执行时:
    接收当前用于查询第一数据文件的查询请求;
    从所述查询请求的查询条件中提取至少一个查询项;
    根据所述第一数据文件的索引文件中存储的已有查询项和所述已有查询项对应的数据行指示信息,对所述至少一个查询项中能够被改写的查询项进行改写;所述数据行指示信息用于指示满足所述已有查询项的数据所在的数据行;
    根据所述至少一个查询项中被改写的查询项和未被改写的查询项,在所述第一数据文件中进行查询,以获取待查询的数据。
  23. 一种计算机存储介质,所述计算机存储介质被编码有计算机程序,所述程序在被一个或多个计算机执行时,使得所述一个或多个计算机执行如下操作:
    获取用于查询第一数据文件的查询请求;
    从所述查询请求的查询条件中提取至少一个查询项;
    获取各查询项对应的数据行指示信息,所述数据行指示信息用于指示满足所述数据行指示信息对应查询项的数据所在的数据行;
    将所述各查询项以及所述各查询项对应的数据行指示信息对应存储在所述第一数据文件的索引文件。
  24. 一种计算机存储介质,所述计算机存储介质被编码有计算机程序,所述程序在被一个或多个计算机执行时,使得所述一个或多个计算机执行如下操作:
    接收当前用于查询第一数据文件的查询请求;
    从所述查询请求的查询条件中提取至少一个查询项;
    根据所述第一数据文件的索引文件中存储的已有查询项和所述已有查询项对应的数据行指示信息,对所述至少一个查询项中能够被改写的查询项进行改写;所述数据行指示信息用于指示满足所述已有查询项的数据所在的数据行;
    根据所述至少一个查询项中被改写的查询项和未被改写的查询项,在所述第一数据文件中进行查询,以获取待查询的数据。
PCT/CN2016/089484 2015-12-07 2016-07-08 索引构建方法、查询方法及对应装置、设备、计算机存储介质 WO2017096892A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510887819.9A CN105550225B (zh) 2015-12-07 2015-12-07 索引构建方法、查询方法及装置
CN201510887819.9 2015-12-07

Publications (1)

Publication Number Publication Date
WO2017096892A1 true WO2017096892A1 (zh) 2017-06-15

Family

ID=55829414

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/089484 WO2017096892A1 (zh) 2015-12-07 2016-07-08 索引构建方法、查询方法及对应装置、设备、计算机存储介质

Country Status (2)

Country Link
CN (1) CN105550225B (zh)
WO (1) WO2017096892A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111241088A (zh) * 2018-11-09 2020-06-05 北京京东尚科信息技术有限公司 数据写入方法、数据查询方法、装置及设备
CN113949640A (zh) * 2020-06-29 2022-01-18 大唐移动通信设备有限公司 业务数据处理方法及装置
CN115809248A (zh) * 2022-12-30 2023-03-17 联通智网科技股份有限公司 数据查询方法和装置以及存储介质

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105550225B (zh) * 2015-12-07 2019-05-28 百度在线网络技术(北京)有限公司 索引构建方法、查询方法及装置
CN107273430B (zh) * 2017-05-16 2021-05-18 北京奇虎科技有限公司 一种数据存储方法和装置
CN109254962B (zh) * 2017-07-06 2020-10-16 中国移动通信集团浙江有限公司 一种基于t-树的索引优化方法、装置及存储介质
CN110019331A (zh) * 2017-09-08 2019-07-16 北京京东尚科信息技术有限公司 一种基于结构化查询语言的查询数据库的方法和装置
CN111026827A (zh) * 2019-12-06 2020-04-17 北京地拓科技发展有限公司 一种土壤侵蚀因子的数据服务方法、装置和电子设备
CN111400346A (zh) * 2020-03-13 2020-07-10 苏州浪潮智能科技有限公司 一种提升数据库一体机执行效率的方法、设备、装置和介质
CN112162982A (zh) * 2020-09-16 2021-01-01 中国建设银行股份有限公司 数据查询方法、装置、设备及介质
CN112231338A (zh) * 2020-12-14 2021-01-15 广东睿江云计算股份有限公司 一种数据库操作优化方法及其系统
CN113590736B (zh) * 2021-08-12 2024-05-07 成都数之联科技股份有限公司 索引管理方法、装置、电子设备和可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101295316A (zh) * 2008-05-29 2008-10-29 北京握奇数据系统有限公司 位图索引方法以及智能卡
CN102736986A (zh) * 2011-03-31 2012-10-17 国际商业机器公司 一种内容可寻址存储器及其检索数据的方法
CN102760165A (zh) * 2012-06-12 2012-10-31 上海方正数字出版技术有限公司 一种使用位图索引的全文检索方法和装置
CN105550225A (zh) * 2015-12-07 2016-05-04 百度在线网络技术(北京)有限公司 索引构建方法、查询方法及装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100578498C (zh) * 2006-06-07 2010-01-06 华为技术有限公司 数据集成服务系统及方法
WO2010019056A1 (en) * 2008-08-11 2010-02-18 Macfarlane Engel & Associates Improved treatment method and device
CN101727465B (zh) * 2008-11-03 2011-12-21 中国移动通信集团公司 分布式列存储数据库索引建立、查询方法及装置与系统
CN103810213B (zh) * 2012-11-14 2017-09-12 腾讯科技(深圳)有限公司 一种搜索方法和系统
CN103092958A (zh) * 2013-01-18 2013-05-08 深圳市龙视传媒有限公司 一种搜索结果展示方法和装置
US9535979B2 (en) * 2013-06-21 2017-01-03 International Business Machines Corporation Multifaceted search
US9361407B2 (en) * 2013-09-06 2016-06-07 Sap Se SQL extended with transient fields for calculation expressions in enhanced data models
CN104506906B (zh) * 2014-11-12 2019-01-18 科大讯飞股份有限公司 基于电视场景元素及语音助手的语音交互辅助方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101295316A (zh) * 2008-05-29 2008-10-29 北京握奇数据系统有限公司 位图索引方法以及智能卡
CN102736986A (zh) * 2011-03-31 2012-10-17 国际商业机器公司 一种内容可寻址存储器及其检索数据的方法
CN102760165A (zh) * 2012-06-12 2012-10-31 上海方正数字出版技术有限公司 一种使用位图索引的全文检索方法和装置
CN105550225A (zh) * 2015-12-07 2016-05-04 百度在线网络技术(北京)有限公司 索引构建方法、查询方法及装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111241088A (zh) * 2018-11-09 2020-06-05 北京京东尚科信息技术有限公司 数据写入方法、数据查询方法、装置及设备
CN113949640A (zh) * 2020-06-29 2022-01-18 大唐移动通信设备有限公司 业务数据处理方法及装置
CN115809248A (zh) * 2022-12-30 2023-03-17 联通智网科技股份有限公司 数据查询方法和装置以及存储介质
CN115809248B (zh) * 2022-12-30 2024-03-22 联通智网科技股份有限公司 数据查询方法和装置以及存储介质

Also Published As

Publication number Publication date
CN105550225A (zh) 2016-05-04
CN105550225B (zh) 2019-05-28

Similar Documents

Publication Publication Date Title
WO2017096892A1 (zh) 索引构建方法、查询方法及对应装置、设备、计算机存储介质
CN111046034B (zh) 管理内存数据及在内存中维护数据的方法和系统
US10191932B2 (en) Dependency-aware transaction batching for data replication
US8396852B2 (en) Evaluating execution plan changes after a wakeup threshold time
TWI603211B (zh) Construction of inverted index system based on Lucene, data processing method and device
US20160275150A1 (en) Lightweight table comparison
EP3238097B1 (en) Identifying join relationships based on transactional access patterns
US20150227521A1 (en) System and method for analysis and management of data distribution in a distributed database environment
EP2812815B1 (en) Web page retrieval method and device
CN107301214B (zh) 在hive中数据迁移方法、装置及终端设备
CN110688382B (zh) 数据存储查询方法、装置、计算机设备及存储介质
WO2018036549A1 (zh) 分布式数据库查询方法、装置及管理系统
US20240126817A1 (en) Graph data query
US20190197040A1 (en) Method and apparatus for processing join query
TW201319982A (zh) 產品資訊的即時去重複方法和裝置
WO2017161540A1 (zh) 数据查询的方法、数据对象的存储方法和数据系统
US9734176B2 (en) Index merge ordering
CN111723161A (zh) 一种数据处理方法、装置及设备
US10599614B1 (en) Intersection-based dynamic blocking
CN108140022B (zh) 数据查询方法和数据库系统
CN113918605A (zh) 数据查询方法、装置、设备以及计算机存储介质
EP3955256A1 (en) Non-redundant gene clustering method and system, and electronic device
CN113722600B (zh) 应用于大数据的数据查询方法、装置、设备及产品
CN110019380B (zh) 一种数据查询方法、装置、服务器及存储介质
EP3620932A1 (en) Method and system for merging data

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: 16872092

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16872092

Country of ref document: EP

Kind code of ref document: A1