WO2017072890A1 - データ管理システム、データ管理方法およびプログラム - Google Patents

データ管理システム、データ管理方法およびプログラム Download PDF

Info

Publication number
WO2017072890A1
WO2017072890A1 PCT/JP2015/080446 JP2015080446W WO2017072890A1 WO 2017072890 A1 WO2017072890 A1 WO 2017072890A1 JP 2015080446 W JP2015080446 W JP 2015080446W WO 2017072890 A1 WO2017072890 A1 WO 2017072890A1
Authority
WO
WIPO (PCT)
Prior art keywords
vector
search
case
lsh
index
Prior art date
Application number
PCT/JP2015/080446
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 株式会社東芝
Priority to JP2017547261A priority Critical patent/JP6434162B2/ja
Priority to CN201580083082.3A priority patent/CN108027816B/zh
Priority to PCT/JP2015/080446 priority patent/WO2017072890A1/ja
Publication of WO2017072890A1 publication Critical patent/WO2017072890A1/ja
Priority to US15/927,124 priority patent/US11281645B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2237—Vectors, bitmaps or matrices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2246—Trees, e.g. B+trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/221—Column-oriented storage; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2255—Hash tables
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/33—Querying
    • G06F16/3331—Query processing
    • G06F16/334—Query execution
    • G06F16/3347—Query execution using vector based model
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating

Definitions

  • Embodiments described herein relate generally to a data management system, a data management method, and a program.
  • a similar search using a multidimensional feature vector is performed as a method for performing a high-speed media search for images and music.
  • a vector neighborhood search including similarity calculation between feature vectors that is, a feature vector group close to a certain feature vector (hereinafter referred to as “query vector”) is searched for a feature vector (hereinafter referred to as “target vector”).
  • query vector a feature vector group close to a certain feature vector
  • target vector hereinafter referred to as “target vector”.
  • example vectors occupies most of the calculation amount. For this reason, it is required to reduce the calculation amount of the vector neighborhood search so that the execution time of the data search can be shortened.
  • the problem to be solved by the present invention is to provide a data management system, a data management method, and a program capable of reducing the calculation amount of vector neighborhood search and shortening the data search execution time.
  • the data management system of the embodiment includes an index construction unit and a search unit.
  • the index construction unit creates a peripheral vector similar to a case vector that is a feature vector of accumulated data, and constructs index information for specifying the case vector corresponding to the generated peripheral vector.
  • the search unit uses the index information to identify and identify the case vector corresponding to the peripheral vector that completely matches the query vector A search result based on the case vector is output.
  • FIG. 1 is a system configuration diagram showing an overview of the data management system of the first embodiment.
  • FIG. 2 is a diagram illustrating a specific example of the data table.
  • FIG. 3 is a flowchart illustrating an example of a processing procedure by the data register when the media data is a still image.
  • FIG. 4 is a flowchart illustrating an example of a processing procedure by the data register when the media data is a moving image.
  • FIG. 5 is a block diagram illustrating a configuration example of the index builder.
  • FIG. 6 is a diagram illustrating an example of the LSH immediate value table.
  • FIG. 7 is a flowchart showing an example of a processing procedure by the LSH immediate index information generator.
  • FIG. 8 is a diagram illustrating an example of the LSH neighborhood development table.
  • FIG. 1 is a system configuration diagram showing an overview of the data management system of the first embodiment.
  • FIG. 2 is a diagram illustrating a specific example of the data table.
  • FIG. 3 is a
  • FIG. 9 is a diagram illustrating an example of normalization by dividing the LSH neighborhood development table into two.
  • FIG. 10 is a diagram illustrating an example of a database composite index.
  • FIG. 11 is a flowchart illustrating an example of a processing procedure by the LSH neighborhood development index information generator.
  • FIG. 12 is a diagram for explaining the associative array and the continuous memory arrangement type array.
  • FIG. 13 is a block diagram illustrating a configuration example of a searcher.
  • FIG. 14 is a diagram illustrating an input / output relationship of the vector similarity determination unit.
  • FIG. 15 is a flowchart illustrating an example of a processing procedure performed by the vector similarity determination unit.
  • FIG. 16 is a flowchart illustrating an example of a processing procedure by the strict searcher.
  • FIG. 17 is a flowchart illustrating an example of a processing procedure by the linear LSH searcher.
  • FIG. 18 is a flowchart illustrating an example of a processing procedure by the database index LSH searcher.
  • FIG. 19 is a flowchart showing an example of a processing procedure by the database index LSH search + strict searcher.
  • FIG. 20 is a flowchart illustrating an example of a processing procedure by the database index LSH search + linear LSH searcher.
  • FIG. 21 is a block diagram illustrating a configuration example of a searcher according to the second embodiment.
  • FIG. 22 is a flowchart illustrating an example of a processing procedure by the query perturbation LSH searcher.
  • FIG. 23 is a block diagram illustrating a configuration example of an index builder according to the third embodiment.
  • FIG. 24 is a diagram illustrating an example of the PQLSH neighborhood expansion table.
  • FIG. 25 is a flowchart illustrating an example of a processing procedure performed by the PQLSH neighborhood expansion index information generator.
  • FIG. 26 is a block diagram illustrating a configuration example of a searcher according to the third embodiment.
  • FIG. 27 is a flowchart showing an example of a processing procedure by the database index PQLSH searcher.
  • FIG. 28 is a block diagram illustrating a hardware configuration example of the data management system.
  • the data management system of the embodiment is a system for efficiently managing and retrieving large-scale data.
  • Conventional systems that manage large-scale data such as those found in database management systems, generally have a data placement mechanism that optimizes disk access, etc. as a lower layer, and high-speed large-scale data based on search conditions as an upper layer
  • An index mechanism for searching is installed.
  • As an index algorithm a tree structure algorithm such as a B-tree or a general hash algorithm is mainly used.
  • Search conditions that can be used in a database are often composed of four arithmetic operations and set operations related to basic types such as real numbers, integers, character strings, and dates (hereinafter collectively referred to as “DB basic types”). Is a logical expression.
  • the similarity between vectors and bit strings that is, binary vectors
  • an index for improving the efficiency of a search condition including calculation of similarity of vectors has not been devised.
  • the conventional general database management system is capable of high-speed search of large-scale data using the search conditions configured by the DB basic type, but is a vector including similarity calculation between non-low-dimensional vectors.
  • the neighborhood search cannot be executed at high speed. Therefore, in the embodiment described below, a new data management system is proposed in which the vector neighborhood search can be performed at high speed by reducing the amount of calculation of the vector neighborhood search, and the execution time of the data search can be shortened.
  • inner product and distance as an index indicating the similarity between vectors.
  • the inner product calculation for obtaining the inner product value between the vectors and the distance calculation for obtaining the distance between the vectors are substantially the same in terms of both the meaning and the calculation amount. If the two vectors are similar, the dot product value is large, but the only difference is that the distance is small. That is, a large inner product value between vectors and a small distance between vectors mean a high degree of similarity between the vectors.
  • the degree of similarity between vectors will be described as a distance, but the distance may be replaced with an inner product. In this case, it can be considered that the inner product value increases as the distance between vectors decreases, that is, as the similarity between vectors increases.
  • LSH Locality-Sensitive Hashing
  • LSH is a technique for mapping a given vector group to a reduced vector space that takes only discrete values (see, for example, Reference 1 below).
  • This mapping by LSH has the property that the relative magnitude of the distance between vectors in the space before mapping is well preserved in the space after mapping. Therefore, instead of calculating the distance between vectors in the vector space before mapping, the calculation can be made more efficient by calculating the distance between vectors in the vector space after mapping. However, since the magnitude relationship between distances is not completely preserved, an approximate solution can be obtained.
  • Reference 1 Anshumalishrivastava and Ping Li, “Asymmetric LSH (ALSH) for Sublinear Time Maximum Inner Product Search (MIPS)”, Advances in Neural Information Processing Systems, 2014.
  • the LSH algorithm can be roughly divided into a bitwise method and a product quantization method.
  • the bitwise algorithm outputs a binary vector as a mapping result for a given vector.
  • the algorithm of the direct product quantization method outputs an integer vector (a multi-value vector composed only of integer elements) as a mapping result for a given vector. Further, in the case of the algorithm of the direct product quantization method, information corresponding to the weight for the distance (how much the distance of the vector changes with respect to the change of each dimension) is also generated for each dimension of the vector.
  • the calculation of the distance between vectors can be made efficient.
  • a bit calculation instruction such as xor or a dedicated CPU instruction such as popcount can be used for the distance calculation processing, so that the calculation amount can be greatly reduced.
  • a vector similar to the case vector that is, a vector whose distance to the case vector is a predetermined value or less
  • peripheral vector a vector whose distance to the case vector is a predetermined value or less
  • index information for specifying a case vector from the surrounding vectors is constructed, and data including the case vector and index information are stored in a database.
  • a case vector corresponding to a peripheral vector that completely matches the query vector is specified based on the index information, and a search result for the search request is output based on the specified case vector.
  • both the number of dimensions of the handled vector and the cardinality of each element value set must be small. If this condition is not satisfied, the number of surrounding vectors will explode and as a result search time cannot be shortened.
  • the LSH described above is used.
  • the element of the vector generated by LSH takes a binary value in the case of the bitwise method and a discrete value having multiple values in the case of the direct product quantization method. Depending on the LSH setting, the element value set is often used. A discrete vector (contracted vector) having a small cardinality and dimensionality is generated.
  • the case vector group and the query vector are converted into contracted vectors using LSH, and these are used to perform the above-described method described as the basic principle. You can do a search. However, since LSH is used, the search result is an approximate solution.
  • a peripheral vector whose distance to the case vector is equal to or smaller than a predetermined value is generated.
  • a peripheral vector whose distance to the query vector is equal to or smaller than a predetermined value may be generated.
  • a peripheral vector whose distance to the query vector is a predetermined value or less is generated, a case vector that completely matches the peripheral vector is specified, and a search result for the search request is output based on the specified case vector. .
  • a face image (including video) search is taken up as an application material of media search.
  • the face image search is a process of finding a part of an image / video including a face similar to the face included in the image / video given as a query from a group of media such as images / videos registered in the system in advance.
  • face image search is taken up as an application subject, but the data management system of the embodiment is, for example, music search, object image search, scene image search, text meaning search, sensor pattern search, stock price pattern search, power usage pattern. It can be applied to various media searches and sensor data searches such as search.
  • bitwise LSH is used for mapping processing, and a Hamming distance is used as the distance between binary vectors (hashes) after mapping.
  • bitwise LSH is used for mapping processing
  • a Hamming distance is used as the distance between binary vectors (hashes) after mapping.
  • the case vector and query vector to be handled are originally low-dimensional binary vectors, mapping by bitwise LSH is unnecessary, and the case vector is used as a case hash (contracted case vector) described later. It can be used as it is, and the query vector can be used as it is as a query hash (contracted query vector).
  • a peripheral vector generated based on the case vector may be used as a peripheral hash (contracted peripheral vector) described later.
  • FIG. 1 is a system configuration diagram showing an overview of the data management system of the first embodiment.
  • the data management system of this embodiment includes a data registration device 100, an index construction device 200, a search device 300, and a database 400.
  • the data registration device 100 receives a media data group 10 such as an image or video including a face from the outside, analyzes the received media data group 10 as a target, and includes a feature vector (case vector) group related to a facial feature.
  • the data table 20 is generated in the database 400.
  • the index builder 200 Upon receiving the index construction command statement 30 from the outside, the index builder 200 retrieves the data table 20 corresponding to the received index construction command statement 30 from the database 400, and in accordance with the command of the index construction command statement 30, the index of the face feature vector. Index information 40 to be used as is generated in the database 400.
  • the searcher 300 When the searcher 300 receives an extended SQL 50 (an example of a search request) including a query vector related to facial features from the outside, the searcher 300 acquires the corresponding data table 20 and index information 40 from the database 400, and the query vector included in the extended SQL 50 A search result data set 60 including similar face feature vectors is output.
  • an extended SQL 50 an example of a search request
  • the searcher 300 acquires the corresponding data table 20 and index information 40 from the database 400, and the query vector included in the extended SQL 50
  • a search result data set 60 including similar face feature vectors is output.
  • FIG. 2 is a diagram illustrating a specific example of the data table 20 that the data register 100 generates in the database 400.
  • the media data included in the media data group 10 received from the outside by the data registration device 100 is three types of files: dir / a.jpg, dir / b.jpg, and dir / a.mpg.
  • dir / a.jpg and dir / b.jpg are still image files
  • dir / a.mpg is a moving image file.
  • the data registration device 100 executes the following processing for each media data included in the media data group 10.
  • FIG. 3 is a flowchart illustrating an example of a processing procedure performed by the data registration device 100 when the media data is a still image.
  • the data registration device 100 registers the media data in the data table 20 by executing, for example, the following steps S101 to S105.
  • Step S101 The data register 100 performs face area extraction processing on the input still image. As a result, from the input still image, all image regions (face image regions) that are likely to contain a face are extracted.
  • the face area extraction process may be performed using an existing technique, and thus detailed description thereof is omitted here.
  • Step S102 The data register 100 sequentially extracts the face image areas extracted in step S101.
  • Step S103 The data register 100 performs feature generation processing on the face image area extracted in step S102 to obtain a feature vector (case vector). It should be noted that since the existing technology may be used for the feature generation process, detailed description thereof is omitted here.
  • Step S104 The data registration device 100 adds to the data table 20 a record including three pieces of information: the feature vector obtained in Step S103, the media data name given to the input still image, and the coordinates of the face image area. .
  • Step S105 The data registration device 100 determines whether all the face image areas extracted in step S101 have been extracted. If the determination result is No, the process returns to step S102 and the subsequent processing is repeated. If the determination result is Yes, the processing ends.
  • FIG. 4 is a flowchart illustrating an example of a processing procedure performed by the data registration device 100 when the media data is a moving image.
  • the data registration device 100 registers the media data in the data table 20, for example, by executing the following processes in steps S201 to S212.
  • Step S201 The data registration device 100 extracts the first frame image from the input moving image.
  • Step S202 The data registration device 100 performs a face area extraction process and a feature generation process on the first frame image extracted in step S201. As a result, all image areas (face image areas) that are likely to show a face are extracted with certainty, and feature vectors are obtained from the respective face image areas.
  • Step S203 The data registration device 100 takes out the next frame image from the input moving image.
  • Step S204 The data registration device 100 performs the same face area extraction processing and feature generation processing as those in step S202 on the frame image extracted in step S203.
  • Step S205 The data registration device 100 performs face tracking processing on the frame with the previous frame.
  • the face tracking process is a process of finding a pair of face image areas whose image and area coordinates are similar between frames and interpreting them as the same subject. Since face tracking processing may be performed using existing technology, detailed description is omitted here.
  • Step S206 The data register 100 bundles the face image areas determined as the same subject as the same group as a result of the face tracking process in step S205.
  • Step S207 The data registration device 100 determines whether there is a next frame. And if the result of determination is Yes, it will return to step S203 and will repeat the subsequent process, and if it is No, it will progress to step S208.
  • Step S208 The data registration device 100 sequentially takes out the groups generated by the above processing.
  • Step S209 The data registration device 100 includes a first appearance time that is the appearance time of the earliest frame and a second appearance time that is the appearance time of the latest frame among the frames included in the group extracted in Step S208. Get appearance time.
  • Step S210 The data register 100 acquires the third appearance time, which is the appearance time of the frame with the highest certainty among the frames included in the group extracted in step S208, the feature vector, and the coordinates of the face image area. To do.
  • Step S211 The data register 100, the first appearance time and the second appearance time acquired in step S209, the third appearance time acquired in step S210, the feature vector, the coordinates of the face image area, and the input video Is added to the data table 20 including six pieces of information including the media data name given to the data table 20.
  • Step S212 The data registration device 100 determines whether all the generated groups have been extracted. If the determination result is No, the process returns to step S208 and the subsequent processing is repeated. If the determination result is Yes, the processing ends.
  • the index information 40 generated in the database 400 by the index builder 200 is auxiliary information for speeding up vector neighborhood search for the data table 20 having feature vectors in columns.
  • the index builder 200 can generate two types of index information 40, that is, LSH immediate index information and LSH neighborhood expansion index information, according to the type of the index construction command 30 that has been input.
  • the index information 40 includes table data and a database index (B-tree etc.) which will be described later.
  • the index builder 200 constructs a plurality of pieces of index information 40 by executing a plurality of index construction instructions 30 having different hash bit length specifications for the same row storing the feature vector of the data table 20. be able to. For example, if two types of index information 40 using a hash having a short bit length and index information 40 using a hash having a long bit length are constructed, the former index is used when performing a search focusing on speed rather than accuracy. When a search is performed using the information 40 and focusing on accuracy rather than the speed, the latter index information 40 can be used so that it can be properly used according to the purpose of the search.
  • FIG. 5 is a block diagram illustrating a configuration example of the index builder 200.
  • the index builder 200 includes an index construction instruction type classifier 210, an LSH immediate index information generator 220, and an LSH neighborhood expansion index information generator 230.
  • the index construction command type classifier 210 converts the index construction command statement 30 input to the index construction device 200 to either the LSH immediate value index information generator 220 or the LSH neighborhood expansion index information generator 230 according to the type. It is a switcher that delivers to
  • the index construction command statement 30 input to the index builder 200 is, for example, a command statement configured as follows. However, some value is entered in the xxxx part. Table: xxxx, Column: xxxx, Algo: xxxx, BitLen: xxxx, HammingDist: xxxx
  • the table name specifies the table name of the data table 20 that is the target of the index information 40
  • the Column item indicates the column name in the data table 20 that is the target of the index information 40. It is specified. A feature vector needs to be stored in the column in the data table 20 indicated by the column name.
  • the algorithm name of the LSH algorithm used for generating the index information 40 is designated.
  • the algorithm name is selected from LSH algorithms implemented in the system. For example, if only the LSH algorithm named SimHash and the LSH algorithm named SpectralHash are implemented in the system, one of these algorithm names is specified. In the present embodiment, as described above, since bitwise LSH is used, an algorithm name of bitwise LSH is designated.
  • the bit length of the hash output by the LSH algorithm selected in the Algo item is specified.
  • an upper limit of a Hamming distance handled by the LSH neighborhood expansion index information generator 230 (range of a peripheral hash described later) is designated. For example, when “2” is specified in the HammingDist item, the Hamming distances handled by the LSH neighborhood development index information generator 230 are “0”, “1”, and “2”. The HammingDist item may be omitted.
  • the index construction command type classifier 210 converts the index construction command statement 30 into the LSH immediate index information generator 220 and the vicinity of the LSH. This is passed to one of the development index information generators 230. For example, if there is no HammingDist item in the index construction command statement 30 input to the index construction device 200, the index construction command type classifier 210 passes the index construction command statement 30 to the LSH immediate index information generator 220, and the HammingDist item. If there is, the index construction command statement 30 is passed to the LSH neighborhood development index information generator 230.
  • the LSH immediate value index information generator 220 When the LSH immediate value index information generator 220 receives the index construction command statement 30 from the index construction command type classifier 210, the LSH immediate value table and the database for the HashValue column of the LSH immediate data table according to the index construction command statement 30 LSH immediate index information 40A including an index is generated.
  • FIG. 6 is a diagram showing an example of the LSH immediate value table.
  • the LSH immediate value table is table data including only a HashValue column (type: blob).
  • the LSH immediate index information generator 220 sequentially extracts the feature vectors stored in the designated column for each record of the data table 20 designated by the index construction command statement 30, and uses the designated LSH algorithm. Then, a hash having the designated output bit length is generated, and the obtained record having only each hash is registered in the LSH immediate value table.
  • the hash is essentially a binary vector, but in the present embodiment, the hash is not stored as an array of Boolean values, but is stored as an integer assuming a binary number. That is, the HashValue column of the LSH immediate value table is a blob that stores an integer or an integer array (treatment when the upper limit of the number of bits of the computer architecture is exceeded). Thereby, the storage area size can be reduced.
  • the LSH immediate value table may be incorporated into the data table 20. With such a configuration, the sub-query process can be reduced once in the entire search process.
  • the LSH immediate value table In order to incorporate the LSH immediate value table into the data table 20, when the data register 100 described above generates the data table 20, it is necessary to prepare a column for storing the hash in the data table 20 in advance. Further, as described above, in order to be able to construct a plurality of index information 40 for the same row storing the feature vector of the data table 20, a plurality of types of hashes having different bit lengths in the data table 20 are used. It is necessary to reserve a plurality of columns for storing. In such a configuration, the LSH immediate index information generator 220 may store the hash generated based on the feature vector in the corresponding column of the data table 20 instead of registering it in the LSH immediate value table.
  • the LSH immediate value index information generator 220 constructs a database index for the HashValue column of the LSH immediate value table together with the generation of the LSH immediate value table as described above, and stores these in the database 400 as the LSH immediate value index information 40A.
  • FIG. 7 is a flowchart illustrating an example of a processing procedure by the LSH immediate index information generator 220.
  • the LSH immediate index information generator 220 receives the index construction command statement 30 from the index construction command type classifier 210, the LSH immediate data index information generator 220 executes, for example, the following steps S301 to S307, and includes the LSH immediate data table and the database index.
  • the immediate index information 40A is stored in the database 400.
  • Step S301 The LSH immediate value index information generator 220 generates a table (empty LSH immediate value table) having only a column of name: HashValue and type: blob in the database 400.
  • the table name format is “AAAA_BBBB_CCCC_DDDD”.
  • AAAA is the table name of the data table 20 to be processed
  • BBBB is the column name of the column to be processed
  • CCCC is the algorithm name of the LSH algorithm
  • DDDD is the bit length.
  • a table name such as aTable_feat_SimHash_64 is given to the generated table.
  • Step S302 The LSH immediate index information generator 220 sequentially extracts the feature vector of the column specified by the index construction command statement 30 from the data table 20 designated by the index construction command statement 30.
  • Step S303 The LSH immediate index information generator 220 uses the LSH algorithm specified in the index construction command statement 30 for the feature vector extracted in step S302, and outputs the output bit length designated in the index construction command statement 30. Generate a hash of.
  • Step S304 The LSH immediate index information generator 220 adds the record having the case hash obtained in step S303 as the value of the HashValue column to the LSH immediate value table.
  • Step S305 The LSH immediate index information generator 220 determines whether or not all feature vectors have been extracted from the data table 20 to be processed. If the determination result is No, the process returns to step S302 and the subsequent processing is repeated. If the determination result is Yes, the process proceeds to step S306.
  • Step S306 The LSH immediate index information generator 220 constructs a database index (such as a B-tree) for the HashValue column of the LSH immediate value table generated through the above processing and stores it in the database 400.
  • a database index such as a B-tree
  • Step S307 If there is a model parameter set of the LSH algorithm used for generating the hash (for example, a projection vector group in SimHash), the LSH immediate index information generator 220 uses the same file name as the table name (for example, aTable_feat_SimHash_64) Save to 400.
  • a model parameter set of the LSH algorithm used for generating the hash for example, a projection vector group in SimHash
  • the LSH immediate index information generator 220 uses the same file name as the table name (for example, aTable_feat_SimHash_64) Save to 400.
  • LSH neighborhood development index information generator 230 When the LSH neighborhood development index information generator 230 receives the index construction command statement 30 from the index construction command type classifier 210, the LSH neighborhood development table and the HSHValue of this LSH neighborhood development table according to this index construction command statement 30.
  • LSH neighborhood expansion index information 40B including a database and a database composite index (composite index) for the HammingDistance column is generated.
  • FIG. 8 is a diagram showing an example of the LSH neighborhood development table.
  • the LSH neighborhood development table is table data including a HashValue column (type: blob), a HammingDistance column (type: integer), and a DataRowID column (type: integer).
  • the LSH neighborhood development index information generator 230 extracts a feature vector from the data table 20 specified by the index construction command statement 30 and, for each feature vector (case vector), the LSH algorithm and bit designated by the index construction command statement 30.
  • a hash (contracted case vector) is generated according to the length. This is called a “case hash”.
  • the LSH neighborhood development index information generator 230 generates a hash (contracted peripheral vector) group within the Hamming distance designated by the index construction command statement 30 for each generated case hash.
  • the hash generated here is called a “peripheral hash”.
  • the LSH neighborhood development index information generator 230 for example, 3 of the peripheral hash, the hamming distance from the case hash of the peripheral hash, and the row ID of the record of the data table 20 to which the case vector that is the basis of the case hash belongs. Records consisting of pairs are registered in the LSH neighborhood development table.
  • a Hamming distance used as a search condition is sequentially incremented from 0 to add a search result. Therefore, a HammingDistance column is provided in the second column of the LSH neighborhood development table, and the Hamming distance from the case hash of the peripheral hash is stored in this HammingDistance column.
  • the search is performed using the upper limit of the distance in the LSH neighborhood development table as a search condition during the search. In this case, it is not necessary to provide a HammingDistance column in the LSH neighborhood development table.
  • a database index for the HashValue column of the LSH neighborhood development table may be constructed.
  • the LSH neighborhood expansion table shown in FIG. 8 includes many duplicate values as peripheral hash values stored in the HashValue column, it can be made compact by performing normalization.
  • FIG. 9 is a diagram showing an example of normalization by dividing the LSH neighborhood development table shown in FIG. 8 into two.
  • the row ID of the table in FIG. 9A is determined using the search conditions related to HashValue and HammingDistance, and the row ID DataRowID may be found using the search condition related to Table1_RowID in the table of FIG.
  • Table1_RowID which is the first column of the table in FIG. 9B, stores the row ID of the corresponding row in the table in FIG. 9A. Using this link, the table in FIG. If the table of FIG. 9B is joined (JOIN), the LSH neighborhood development table shown in FIG. 8 is obtained.
  • each of the table in FIG. 9A and the table in FIG. 9B may be implemented using an associative array.
  • the key of the associative array in FIG. 9A is a combination of HashValue and HammingDistance, and the value is one or more row IDs.
  • the key of the associative array in FIG. 9B is Table1_RowID, and the value is one or more DataRowIDs.
  • FIG. 10 is a diagram illustrating an example of a database composite index for the HashValue column and the HammingDistance column of the LSH neighborhood expansion table.
  • this database composite index has a tree structure that branches along the values of HashValue and HammingDistance, and describes the row ID of the LSH neighborhood expansion table corresponding to the leaf.
  • the search time can be shortened from 0 (N) to 0 (log (N)).
  • the LSH neighborhood expansion table can be made unnecessary by slightly changing the structure of the database composite index. Specifically, instead of storing the row ID of the LSH neighborhood development table, the value of DataRowID is stored in the leaf of the database composite index. As a result, only DataRowID can be searched, but it is not necessary to store the LSH neighborhood development table in the database 400. In this case, the LSH neighborhood development index information 40B is only the database composite index.
  • FIG. 11 is a flowchart illustrating an example of a processing procedure performed by the LSH neighborhood development index information generator 230.
  • the LSH neighborhood development index information generator 230 receives the index construction command statement 30 from the index construction command type classifier 210, the LSH neighborhood development index information generator 230 executes, for example, the following steps S401 to S410, LSH neighborhood expansion index information 40B including is stored in the database 400.
  • Step S401 The LSH neighborhood expansion index information generator 230 stores, in the database 400, a column of name: HashValue / type: blob, a column of name: HammingDistance / type: integer, and a column of name: DataRowID / type: integer. (An empty LSH neighborhood development table) is generated.
  • the table name format is “AAAA_BBBB_CCCC_DDDD”.
  • AAAA is the table name of the data table 20 to be processed
  • BBBB is the column name of the column to be processed
  • CCCC is the algorithm name of the LSH algorithm
  • DDDD is the bit length.
  • a table name such as aTable_feat_PQ_3 is given to the generated table.
  • Step S402 The LSH neighborhood development index information generator 230 sequentially extracts the feature vector of the column specified by the index construction command statement 30 from the data table 20 designated by the index construction command statement 30.
  • Step S403 The LSH neighborhood development index information generator 230 uses the LSH algorithm specified in the index construction command statement 30 for the feature vector (case vector) extracted in step S402, and designates it in the index construction command statement 30. Generate a case hash of the specified bit length.
  • Step S404 The LSH neighborhood development index information generator 230 generates all the neighboring hashes whose distance from the case hash obtained in step S403 is equal to or less than the specified distance.
  • Step S405 The LSH neighborhood development index information generator 230 sequentially extracts the peripheral hashes obtained in step S404.
  • Step S406 The LSH neighborhood development index information generator 230 generates the row of the record in the data table 20 to which the peripheral hash extracted in Step S405, the Hamming distance from the case hash of this peripheral hash, and the case vector that is the basis of the case hash belongs. A record composed of a triple of IDs is added to the LSH neighborhood development table.
  • Step S407 The LSH neighborhood development index information generator 230 determines whether or not all the peripheral hashes obtained in step S404 have been extracted. If the determination result is No, the process returns to step S405 and the subsequent processing is repeated. If the determination result is Yes, the process proceeds to step S408.
  • Step S408 The LSH neighborhood development index information generator 230 determines whether or not all feature vectors have been extracted from the data table 20 to be processed. If the determination result is No, the process returns to step S402 and the subsequent processing is repeated. If the determination result is Yes, the process proceeds to step S409.
  • Step S409 The LSH neighborhood development index information generator 230 constructs a database composite index (composite index) for the HashValue column and HammingDistance column of the LSH neighborhood development table generated through the above processing and stores it in the database 400.
  • Step S410 If there is a model parameter set of the LSH algorithm used for generating the case hash, the LSH neighborhood development index information generator 230 stores it in the database 400 with the same file name as the table name (for example, aTable_feat_PQ_3).
  • peripheral hash generation method in step S404 will be described.
  • bit string of the case hash that is the starting point of the peripheral hash is “010”, and a setting example in which the peripheral hashes within the Hamming distance 2 are enumerated will be described.
  • the peripheral hash with a Hamming distance of 0 is the same hash as the case hash. That is, if the bit string of the case hash is “010”, the peripheral hash at the hamming distance 0 is only “010” for this case hash.
  • the peripheral hash of the Hamming distance 1 is obtained by inverting only one arbitrary bit of the case hash. If the bit length of the case hash is 3, there are three types of selection methods for the bits to be inverted: only the first bit, only the second bit, and only the third bit. If the bit string of the case hash is “010”, the result of bit inversion by each selection method is “110”, “000”, and “011”. These three hashes are peripheral hashes having a Hamming distance of 1 with respect to the case hash “010”.
  • the peripheral hash at the Hamming distance 2 is obtained by inverting two arbitrary bits of the case hash. If the bit length of the case hash is 3, the selection method of the bits to be inverted is three types: first bit + second bit, first bit + third bit, and second bit + third bit. If the bit string of the case hash is “010”, the result of performing bit inversion by each selection method is “100”, “111”, and “001”. These three hashes are peripheral hashes having a Hamming distance of 2 with respect to the case hash “010”.
  • the peripheral hash at the Hamming distance 0 is “010”
  • the peripheral hashes at the Hamming distance 1 are “110”, “000”, and “011”
  • the peripheral hash at the Hamming distance 2 is “100”. ",” 111 "and” 001 ". In this way, all the peripheral hashes can be generated with low-cost processing.
  • a mechanism may be provided that restricts the bits that are allowed to be inverted based on the importance of the bit. For example, in the case of a hash generation method based on principal component analysis as in the above Reference 3, the discrimination (importance) of the bit can be calculated from the eigenvalue corresponding to each bit.
  • the peripheral hash generated by inverting the highly discriminating bits in the case hash is a peripheral hash that has lost its discrimination, so even if such a peripheral hash is added to the LSH neighborhood expansion table, the probability of hitting is low. it is conceivable that. Therefore, a restriction may be applied so that such a bit with high discrimination is not inverted. Thus, by limiting the bits that are allowed to be inverted, the storage area size of the LSH neighborhood development table can be reduced.
  • the LSH neighborhood expansion table has a search key column and a search result column, it is concise with an associative array (key-value store, std :: map, std :: unordered_map, etc. for C ++ standard library) Can be implemented.
  • a variable-length continuous memory arrangement type array of DataRowID (such as std :: vector in the C ++ standard library) is used as the value of the associative array. Since the search condition is AND of HashValue and HammingDistance, an associative array key that is unique is generated using these two values.
  • FIG. 12 is a diagram for explaining the associative array and the continuous memory arrangement type array.
  • the associative array has a data structure such as a tree or a hash as a database index, as shown in FIG. If the above keys are almost used in the domain, use a continuous memory layout type array (such as std :: vector in the C ++ standard library) instead of an associative array. May be.
  • the number of elements secured as a continuous memory arrangement type array is the total number of combinations of HashValue and HammingDistance.
  • the data structure using the continuous memory arrangement type array reduces the memory usage only when the key allocation rate is high, and further increases the processing speed.
  • the searcher 300 can perform record search under a logical condition including zero or more conditions related to vector similarity using the extended SQL 50.
  • the database user can perform a search using a logical expression in which general data matching and feature vector similarity determination are combined as conditions.
  • the vector similarity determination (vector neighborhood search) processing can be internally switched among five types according to the number of records to be searched. This switching is performed based on a preset system setting.
  • the database index LSH search which is one of these five types, is a method for realizing vector similarity determination (vector neighborhood search) using only the database index without performing vector distance calculation at the time of search for a query. . This method has the effect of greatly reducing the search time.
  • FIG. 13 is a block diagram illustrating a configuration example of the searcher 300.
  • the searcher 300 receives the extended SQL 50 as an input, executes search processing according to the extended SQL 50, and outputs a search result data set 60. As shown in FIG. And an output unit 320.
  • the search condition processing unit 310 includes a functional module that performs processing for various search conditions.
  • the vector similarity determination processing unit 330 is a functional module that performs processing for a search condition related to vector similarity that is particularly characteristic of the present embodiment.
  • functional modules that perform processing for other search conditions are collectively referred to as other search condition processing units 340.
  • the search condition processing unit 310 performs a set operation of the search result of the vector similarity determination processing unit 330 and the other search condition processing unit 340 to complete the processing of the entire search condition.
  • the search output unit 320 extracts records from the database 400 based on the processing result of the search condition processing unit 310 and outputs the records as the search result data set 60.
  • search condition processing unit 310 corresponds to the from command part (data source specifying process) and the where command part (search condition process) in SQL.
  • the search output unit 320 corresponds to a select command unit in SQL.
  • the unique process in the present embodiment is a process executed by the vector similarity determination processing unit 330 that is one of the search condition processing units 310. For this reason, the vector similarity determination processing unit 330 will be mainly described below, and description of portions where the conventional technology can be applied as they are will be omitted as appropriate.
  • the extended SQL 50 received by the searcher 300 as an input will be described.
  • the extended SQL 50 is a query language extended so that a vnn function corresponding to a condition related to vector similarity can be described in the conventional SQL.
  • the vnn function is used as a term that can be combined with a group of conditions for general DB basic type data in the where instruction, as in the following example. select * from aTable where vnn (feat_simhash_64, (10,20,30), 10) and annualIncome> 10000000
  • the specification of the vnn function is as follows.
  • Input A data set to be searched by the vnn function is input. This input is generated when the search condition processing unit 310 internally generates and calls the vnn function. If it is normal syntax, it is all records of the table specified by the from command.
  • First argument The first argument is a column name storing a case vector (a feature vector to be searched), an algorithm name of an LSH algorithm applied to the column, and an LSH algorithm applied to the column. This is a text in which the output bit length (more generalized as an optional parameter in the third embodiment described later) is connected with an underscore.
  • Second argument The second argument is a query vector.
  • Third argument The third argument is the number of upper output items (the upper number of vectors to be output).
  • Output A search result that matches the condition indicated by the argument is returned to the search condition processing unit 310 (from, where, etc.).
  • the number of upper output cases is given as the third argument corresponding to the output condition, but the upper limit of distance may be given as the third argument instead.
  • FIG. 14 is a diagram illustrating an input / output relationship of the vector similarity determination unit 330.
  • the vector similarity determination unit 330 receives the search target data set 70 as an input, performs a vector similarity determination (vector neighborhood search) process based on the search condition expressed by the vnn function, and performs a search.
  • the result 80 is returned.
  • strict search Strict Search
  • linear LSH search Linear LSH Search
  • database index LSH search DB-Indexed LSH Search
  • database index LSH Five types of search + strict search and database index LSH search + linear LSH search are prepared.
  • Strict search is a search method in which case vectors similar to query vectors are linearly searched using the original query vectors as they are.
  • the linear LSH search is a search method that linearly searches for a case vector corresponding to a case hash that completely matches the query hash, using the LSH immediate index information 40A.
  • the database index LSH search is a search method for searching a case vector corresponding to a peripheral hash that completely matches a query hash, using the LSH neighborhood development index information 40B.
  • the database index LSH search + strict search is a two-stage search method that performs a strict search after narrowing down the number of cases by the database index LSH search.
  • the database index LSH search + linear LSH search is a two-stage search method that performs a linear LSH search after narrowing down the number of cases by the database index LSH search. Searches using these five types of methods are respectively the exact search unit 331, linear LSH search unit 332, database index LSH search unit 333, database index LSH search + exact search unit 334, and database index LSH search + linear shown in FIG. This is performed by the LSH search unit 335.
  • the vector similarity determination processing unit 330 selects one of the above five search methods based on the search method setting information 90 (see FIG. 13) given in advance as a search target record. Select according to the number.
  • the search method setting information 90 has a grammar consisting of a plurality of lines as follows. The number condition is checked from the top and the matched search method is adopted. Number of conditions: Search method Number of conditions: Search method ... otherwise: Search method
  • Search methods include “Strict” (strict search), “LinearLSH” (linear LSH search), “DBIndexedLSH” (database index LSH search), “DBIndexedLSH: NNNN / Strict” (database index LSH search + strict search) and “ DBIndexedLSH: NNNN / LinearLSH ”(database index LSH search + linear LSH search) can be described. Any positive number can be described in NNNN.
  • search method setting information 90 A description example of the search method setting information 90 is shown below.
  • a strict search method is adopted if the number of example vectors to be searched is 10,000 or less
  • a linear LSH search is adopted if the number is 100000 or less
  • a database index LSH if the number is larger than that. It shows that the search + linear LSH search method is adopted.
  • FIG. 15 is a flowchart illustrating an example of a processing procedure performed by the vector similarity determination unit 330.
  • the vector similarity determination unit 330 executes, for example, the following steps S501 to S507 and outputs a search result 80.
  • Step S501 The vector similarity determination unit 330 counts the number of records (the number of case vectors to be searched) of the input search target data set 70.
  • Step S502 The vector similarity determination unit 330 refers to the search method setting information 90, and acquires a search method whose number condition matches the number of records counted in step S501. If the acquired search method is Strict, the process proceeds to step S503, if it is LinearLSH, the process proceeds to step S504. If DBIndexedLSH, the process proceeds to step S505. If DBIndexedLSH: NNNN / Strict (where NNNN is an arbitrary positive number), the process proceeds. If it is DBIndexedLSH: NNNN / LinearLSH (where NNNN is an arbitrary positive number), the process proceeds to S506.
  • Step S503 The vector similarity determination unit 330 acquires the search result 80 using the strict search unit 331, and outputs the acquired search result 80.
  • Step S504 The vector similarity determination unit 330 acquires the search result 80 using the linear LSH search unit 332, and outputs the acquired search result 80.
  • Step S505 The vector similarity determination unit 330 acquires the search result 80 using the database index LSH search unit 333, and outputs the acquired search result 80.
  • Step S506 The vector similarity determination unit 330 acquires the search result 80 using the database index LSH search + strict search unit 334, and outputs the acquired search result 80.
  • Step S507 The vector similarity determination unit 330 acquires the search result 80 using the database index LSH search + linear LSH search unit 335, and outputs the acquired search result 80.
  • the search method is switched according to the number of case vectors to be searched.
  • the search method to be switched should be extended to include various parameter settings such as bit length. It may be. For example, after narrowing down the number of case vectors to 100,000 with a linear LHS search with a short bit length (ie, processing time is small but low accuracy) such as 16 bits, a long bit length such as 4096 bits (ie, per bit) It is possible to make a plan such as ranking by linear LHS search with high processing time but high accuracy.
  • FIG. 16 is a flowchart showing an example of a processing procedure performed by the strict search unit 331.
  • the exact searcher 331 executes, for example, the following steps S601 to S608, and outputs the search result 80.
  • Step S601 The exact searcher 331 generates an empty search result list.
  • Step S602 The exact searcher 331 obtains a query vector specified as the second argument of the vnn function.
  • Step S603 The exact searcher 331 sequentially extracts records from the search target data set 70.
  • Step S604 The exact search unit 331 calculates the Euclidean distance between the case vector group and the query vector stored in the column storing the case vector specified as the first argument of the vnn function in the record extracted in Step S603. .
  • Step S605 The exact search unit 331 adds a set of the row ID of the record extracted in Step S603 and the Euclidean distance calculated in Step S604 to the search result list. However, it is inserted at a position where the elements of the search result list are arranged in ascending order of the Euclidean distance.
  • Step S606 If the number of elements included in the search result list is greater than the number of output high-order items specified as the third argument of the vnn function, the exact searcher 331 discards the element group after the output high-order number.
  • Step S607 The strict search unit 331 determines whether or not all records have been extracted from the search target data set 70. If the determination result is No, the process returns to step S603 and the subsequent processing is repeated. If the determination result is Yes, the process proceeds to step S608.
  • Step S608 The exact search unit 331 outputs a set of row IDs included in the search result list as the search result 80, and ends the process.
  • FIG. 17 is a flowchart showing an example of a processing procedure by the linear LSH search unit 332.
  • the linear LSH search unit 332 executes the processing of the following steps S701 to S709, for example, and outputs a search result 80.
  • Step S701 The linear LSH search unit 332 generates an empty search result list.
  • Step S702 The linear LSH search unit 332 acquires a query vector specified as an argument of the vnn function, an algorithm name of the LSH algorithm, and an output bit length, and generates a hash (contracted query vector) of the query vector.
  • query hash this is referred to as “query hash”.
  • Step S703 The linear LSH search unit 332 obtains the table name of the search target data set 70, the column storing the case vector specified as the argument of the vnn function, the algorithm name of the LSH algorithm, and the output bit length. An LSH immediate value table having the table name determined originally is acquired.
  • Step S704 The linear LSH search unit 332 sequentially extracts the case hashes corresponding to the respective records of the search target data set 70 using the LSH immediate value table acquired in step S703.
  • Step S705 The linear LSH search unit 332 calculates the Hamming distance between the case hash extracted in step S704 and the query hash generated in step S702.
  • Step S706 The linear LSH search unit 332 adds a combination of the row ID of the record of the search target data set 70 corresponding to the case hash extracted in Step S704 and the Hamming distance calculated in Step S705 to the search result list. However, it is inserted at a position where the elements of the search result list are arranged in ascending order of the Hamming distance.
  • Step S707 If the number of elements included in the search result list is greater than the number of output high cases specified as the third argument of the vnn function, the linear LSH search unit 332 discards the element group after the number of output high cases.
  • Step S708 The linear LSH search unit 332 determines whether all the case hashes corresponding to the respective records of the search target data set 70 have been extracted. If the determination result is No, the process returns to step S704 and the subsequent processing is repeated. If the determination result is Yes, the process proceeds to step S709.
  • Step S709 The linear LSH search unit 332 outputs a set of row IDs included in the search result list as the search result 80, and ends the process.
  • step S702 is essentially a binary vector, but is handled as a binary number and an assumed integer in accordance with the storage format in the LSH immediate value table. As a result, the storage area can be saved, and since the integers are compared with each other, the collating process is accelerated.
  • FIG. 18 is a flowchart showing an example of a processing procedure performed by the database index LSH search unit 333.
  • the database index LSH search unit 333 executes, for example, the following steps S801 to S810, and outputs the search result 80.
  • Step S801 The database index LSH searcher 333 generates an empty search result set.
  • Step S802 The database index LSH searcher 333 acquires a query vector, an algorithm name of an LSH algorithm, and an output bit length specified as arguments of the vnn function, and generates a query hash.
  • Step S803 The database index LSH searcher 333 acquires the table name of the search target data set 70, the column storing the case vector specified as the argument of the vnn function, the algorithm name of the LSH algorithm, and the output bit length. An LSH neighborhood expansion table having a table name determined based on is obtained.
  • Step S804 The database index LSH searcher 333 assigns 0 to the Hamming distance condition variable.
  • Step S805 The database index LSH searcher 333 determines that the value of the HammingDistance column matches the current value of the Hamming distance condition variable and the value of the HashValue column in Step S802 with respect to the LSH neighborhood development table acquired in Step S803. A record group that matches the generated query hash is searched, and the obtained set of row IDs is added to the search result set.
  • Step S806 The database index LSH search unit 333 removes duplicate elements from the search result set.
  • Step S807 The database index LSH search unit 333 determines whether or not the number of elements of the search result set is equal to or greater than the number of upper output items specified as the third argument of the vnn function. If the determination result is No, the process proceeds to step S808. If the determination result is Yes, the process proceeds to step S810.
  • Step S808 The database index LSH search unit 333 adds 1 to the value of the Hamming distance condition variable.
  • Step S809 The database index LSH search unit 333 determines whether the value of the Hamming distance condition variable is equal to or less than the upper limit of the distance of the LSH neighborhood development table. If the determination result is Yes, the process returns to step S805 and the subsequent processing is repeated. If the determination result is No, the process proceeds to step S810.
  • Step S810 The database index LSH search unit 333 outputs the search result set as the search result 80, and ends the process.
  • the query hash generated in step S802 is essentially a binary vector, but is handled as a binary number and an assumed integer in accordance with the storage format in the LSH neighborhood expansion table. As a result, the storage area can be saved, and since the integers are compared with each other, the collating process is accelerated. If the upper limit of the distance in the LSH neighborhood development table is a large value such as 100, the increment value in step S808 is set to a larger value such as 10, and a range is provided for the Hamming distance condition in step S805. Good. In this way, the number of iterations is reduced, and the entire search process can be speeded up.
  • FIG. 19 is a flowchart showing an example of a processing procedure by the database index LSH search + strict search unit 334.
  • the database index LSH search + strict search is a two-stage narrowing-down method in which a search is performed by the database index LSH search, and then a search is performed on the result by the strict search.
  • the database index LSH search + strict search unit 334 executes the processing of the following steps S901 to S904, for example, and outputs a search result 80.
  • Step S901 The database index LSH search + strict search unit 334 reads the NNNN part of the search method name “DBIndexedLSH: NNNN / Strict” described in the search method setting information 90. This is the output top number target in the database index LHS search.
  • Step S902 The database index LSH search + strict search unit 334 calls the database index LHS search unit 333 with the setting of the upper output number target, and obtains a search result set.
  • Step S903 The database index LSH search + strict search unit 334 calls the strict search unit 331 using the search result set acquired from the database index LHS search unit 333 as the search target data set 70, and obtains a search result list.
  • Step S904 The database index LSH search + strict search unit 334 outputs a set of row IDs included in the search result list acquired from the strict search unit 331 as the search result 80, and ends the process.
  • FIG. 20 is a flowchart showing an example of a processing procedure performed by the database index LSH search + linear LSH search unit 335.
  • the database index LSH search + linear LSH search is a two-stage narrowing method in which a search is performed by the database index LSH search, and then the search is performed by the linear LSH search.
  • the database index LSH search + linear LSH search unit 335 executes, for example, the following steps S1001 to S1004 and outputs a search result 80.
  • Step S1001 The database index LSH search + linear LSH search unit 335 reads the NNNN part of the search method name “DBIndexedLSH: NNNN / Strict” described in the search method setting information 90. This is the output top number target in the database index LHS search.
  • Step S1002 The database index LSH search + linear LSH search unit 335 calls the database index LHS search unit 333 with the setting of the upper output number target, and obtains a search result set.
  • Step S1003 The database index LSH search + linear LSH search unit 335 calls the linear LSH search unit 332 using the search result set acquired from the database index LHS search unit 333 as the search target data set 70, and obtains a search result list.
  • Step S1004 The database index LSH search + linear LSH search unit 335 outputs a set of row IDs included in the search result list acquired from the linear LSH search unit 332 as the search result 80, and ends the process.
  • exact search is the highest, followed by linear LSH search, and database index LSH search is the lowest.
  • exact search that does not use LSH, which is an approximate method, is naturally the most accurate, but even if the same LSH algorithm is used, the reason why the database index LSH search is less accurate than the linear LSH search is that the database index LSH This is because the search cannot handle a large bit length and Hamming distance.
  • the database index LSH search internally references an LSH neighborhood expansion table that expands all hashes below the Hamming distance as records. When the Hamming distance is H and the bit length is L, the record number S is expressed by the following equation (1).
  • a two-stage narrowing method having a second-stage search method that can easily control the number of outputs such as database index LSH search + exact search and database index LSH search + linear LSH search, is used.
  • it is effective to output a larger number of outputs in the first-stage database index LSH search and to accurately match the number of outputs in the request in the second-stage search.
  • the data management system of this embodiment generates the index information 40 including the LSH neighborhood expansion index information 40B by the pre-processing, and the index information 40 is retrieved during the search.
  • a vector neighborhood search is performed on the data table 20 by a method with a small amount of calculation, such as specifying a case vector corresponding to a peripheral vector that completely matches the query vector. Therefore, it is possible to reduce the calculation amount of the vector neighborhood search that occupies most of the calculation amount in the conventional similar search, and to shorten the data search execution time.
  • a peripheral vector whose distance to a query vector is equal to or smaller than a predetermined value is generated at the time of search, and a case vector that completely matches the peripheral vector is found, thereby reducing memory usage and improving the accuracy of LSH associated therewith. It is a system that realized.
  • an LSH neighborhood expansion table and a database composite index are used internally in order to realize a database index LSH search.
  • the size of these structural data increases when the hash bit length and the hamming distance upper limit are large.
  • a large bit length and a hamming distance upper limit may not be handled. If a sufficiently large bit length or hamming distance cannot be handled, there is a possibility that the search accuracy is lowered.
  • the neighboring hash groups that are hashes (binary vectors) in the vicinity of the case hash that is the hash (binary vector) of each case vector to be searched as in the first embodiment instead of listing the neighboring hash groups that are hashes (binary vectors) in the vicinity of the case hash that is the hash (binary vector) of each case vector to be searched as in the first embodiment.
  • the hash (binary vector) group in the vicinity of the hash (binary vector) of the query vector is enumerated as a peripheral hash group.
  • it is only necessary to store the hash groups enumerated for one vector so the problem of the storage capacity limit is solved and the risk of causing a decrease in search accuracy is avoided.
  • the search speed is lower than in the first embodiment.
  • the basic framework in the data management system of this embodiment is the same as that of the first embodiment.
  • the index builder 200 since the LSH neighborhood expansion index information 40B is not used at the time of search, the index builder 200 (see FIG. 5) includes only the LSH immediate index information generator 220 that generates the LSH immediate index information 40A. It becomes composition.
  • the search method in the vector similarity determination processing unit 330 of the searcher 300 is different from that of the first embodiment. In the following, the search method of this embodiment, which is a main change from the first embodiment, will be described.
  • FIG. 21 is a block diagram illustrating a configuration example of the searcher 300A according to the present embodiment.
  • the vector similarity determination processing unit 330A performs the database index LSH search unit 333, the database index LSH search + exact search unit 334, and the database index LSH search + linear LSH search unit 335 shown in FIG. Instead, a query perturbation type LSH search unit 336, a query perturbation type LSH search + exact search unit 337, and a query perturbation type LSH search + linear LSH search unit 338 are provided.
  • the search method in the previous stage of the two-stage narrowing down method is changed from the database index LSH search to the query perturbation type LSH search.
  • This is the same as the database index LSH search + exact search unit 334 and the database index LSH search + linear LSH search unit 335 of the first embodiment. Therefore, in the following, description of the query perturbation type LSH search + exact search unit 337 and the query perturbation type LSH search + linear LSH search unit 338 is omitted, and only the query perturbation type LSH search unit 336 that performs query perturbation type search is described. To do.
  • FIG. 22 is a flowchart illustrating an example of a processing procedure performed by the query perturbation LSH search unit 336.
  • the query perturbation LSH search unit 336 executes the processing of the following steps S1101 to S1112 and outputs a search result 80, for example.
  • Step S1101 The query perturbation LSH search unit 336 generates an empty search result set.
  • Step S1102 The query perturbation LSH search unit 336 acquires a query vector, an algorithm name of an LSH algorithm, and an output bit length specified as arguments of the vnn function, and generates a query hash.
  • Step S1103 The query perturbation LSH search unit 336 obtains the table name of the search target data set 70, the column storing the case vector specified as the argument of the vnn function, the algorithm name of the LSH algorithm, and the output bit length, An LSH immediate value table having a table name determined based on these is acquired.
  • Step S1104 The query perturbation LSH search unit 336 assigns 0 to the Hamming distance condition variable.
  • Step S1105 The query perturbation LSH search unit 336 generates all the neighboring hashes whose distance from the query hash generated in step S1102 matches the current location of the Hamming distance condition variable.
  • Step S1106 The query perturbation LSH search unit 336 sequentially takes out the peripheral hashes generated in step S1105.
  • Step S1107 The query perturbation LSH search unit 336 extracts all records having the same value as the peripheral hash extracted in step S1106 from the LSH immediate value table acquired in step S1103, and sets the row ID of each record as a search result set. to add.
  • Step S1108 The query perturbation LSH search unit 336 determines whether or not all the peripheral hashes generated in step S1105 have been extracted. If the determination result is No, the process returns to step S1106 and the subsequent processing is repeated. If the determination result is Yes, the process proceeds to step S1109.
  • Step S1109 The query perturbation LSH search unit 336 removes duplicate elements from the search result set.
  • Step S1110 The query perturbation LSH search unit 336 determines whether or not the number of elements of the search result set is equal to or greater than the number of upper output items specified as the third argument of the vnn function. If the determination result is No, the process proceeds to step S1111. If the determination result is Yes, the process proceeds to step S1112.
  • Step S1111 The query perturbation LSH search unit 336 adds 1 to the value of the Hamming distance condition variable.
  • Step S1112 The query perturbation LSH search unit 336 outputs the search result set as the search result 80, and ends the process.
  • a vector for the data table 20 is generated by a method with a small amount of calculation, such as generating a peripheral vector similar to a query vector and specifying a case vector that completely matches the peripheral vector. Neighbor search is performed. Therefore, similarly to the first embodiment, the calculation amount of the vector neighborhood search that occupies most of the calculation amount in the conventional similar search can be reduced, and the execution time of the data search can be shortened.
  • the direct product quantization LSH converts a given vector into an integer vector (a multi-value vector composed only of integer elements). By introducing the index method as shown in the first embodiment for this integer vector, it is possible to eliminate vector distance calculation at the time of search.
  • the case vector and the query vector to be handled are originally low-dimensional integer vectors, mapping by the direct product quantization LSH is unnecessary, and the case vector is used as it is as a case hash described later.
  • the query vector may be used as it is as the query hash. In this case, a peripheral vector generated based on the case vector may be used as a peripheral hash described later.
  • Reference Document 4 A typical algorithm of the direct product quantization LSH is described in Reference Document 4 below.
  • various algorithms including the algorithm described in Reference 4 have been proposed.
  • Reference 4 Herve Jegou, Matthijs Douze and Cordelia Schmid, “Product quantization for nearest neighbor search”, Pattern Analysis and Machine Intelligence, IEEE Transactions on 33.1 (2011): 117-128.
  • a typical procedure for hash generation by direct product quantization LSH is as follows. (1) First, a plurality of (preferably mutually exclusive) subspaces are acquired from a space to which a given case vector group belongs. (2) In each partial space, the case vector group is classified into a predetermined number of clusters. (3) For each case vector, an integer vector in which the cluster numbers of each partial space are arranged is generated. This is the vector after mapping. (4) Using a distribution of each cluster or the like, a distance model for approximately calculating the distance of the vector before mapping is generated from the difference between the vectors after mapping.
  • the distance model generated in the above step (4) differs depending on the algorithm, but in any distance model, when two integer vectors that are hashes are given, the distance in the original vector space is estimated. It has the nature that can be done. In many algorithms, when the cluster numbers are adjacent, the distribution areas of the clusters in the original vector space are also close.
  • the lattice vector quantization represented by the nearest points arranged in a lattice pattern in the original vector space without changing the number of dimensions is the simplest direct product quantization LSH algorithm.
  • the basic framework in the data management system of this embodiment is the same as that of the first embodiment.
  • the changes from the first embodiment of the present embodiment are that an integer vector is treated as a hash, and a distance that can be approximated by a distance model provided by the direct product quantization LSH is used instead of using a Hamming distance as a distance between vectors. Is to do.
  • LSH direct product quantization
  • FIG. 23 is a block diagram illustrating a configuration example of the index builder 200B of the present embodiment.
  • the index builder 200B of this embodiment includes a PQLSH immediate index information generator 240 instead of the LSH immediate index information generator 220 (see FIG. 5) in the index builder 200 of the first embodiment.
  • a PQLSH neighborhood expansion index information generator 250 is provided instead of the LSH neighborhood development index information generator 230 (see FIG. 5) in the index builder 200 of the first embodiment.
  • the PQLSH immediate value index information generator 240 receives the index construction command statement 30 from the index construction command type classifier 210, the PQLSH immediate value table and the database for the HashValue column of the PQLSH immediate value table according to the index construction command statement 30.
  • PQLSH immediate index information 40C including an index is generated.
  • the value stored in the HashValue column of the PQLSH immediate value table is not a binary vector but an integer vector generated using a direct product quantization LSH algorithm. Is the same as the LSH immediate index information 40A described in the first embodiment. Therefore, the detailed description of the PQLSH immediate index information generator 240 is omitted.
  • the PQLSH neighborhood development index information generator 250 receives the index construction command statement 30 from the index construction command type classifier 210, the PQLSH neighborhood development table 30 and the HQValue of this PQLSH neighborhood development table according to this index construction command statement 30 PQLSH neighborhood expansion index information 40D including a database composite index (composite index) for the column and the Distance column is generated.
  • FIG. 24 is a diagram showing an example of the PQLSH neighborhood development table.
  • the PQLSH neighborhood development table is table data including a HashValue column (type: blob), a Distance column (type: real), and a DataRowID column (type: integer), as shown in FIG.
  • a hash of an integer vector of length 2 taking element values ⁇ 0, 1, 2 ⁇ is used, and the distance upper limit is set to 1.0.
  • the value of the Distance column is a distance estimated by the distance model provided by the direct product quantization LSH algorithm.
  • a distance model is used in which the distance changes by 0.4 when the first element value of the hash changes by 1, and the distance changes by 1.0 when the second element value changes by 1.
  • the PQLSH neighborhood expansion index information generator 250 takes out a feature vector from the data table 20 specified by the index construction command statement 30 and, for each feature vector (case vector), the LSH algorithm and distance designated by the index construction command statement 30 Generate a case hash that is an integer vector using the model. Next, the PQLSH neighborhood expansion index information generator 250 generates, for each generated case hash, a peripheral hash group equal to or less than the distance specified by the index construction command statement 30. Then, the PQLSH neighborhood expansion index information generator 250 includes, for example, three values of the peripheral hash, the distance from the peripheral hash case hash, and the row ID of the record of the data table 20 to which the case vector that is the base of the case hash belongs. Records made up of pairs are registered in the PQLSH neighborhood expansion table.
  • the database composite index for the HashValue column and the Distance column of the PQLSH neighborhood expansion table is almost the same as the database composite index of the first embodiment shown in FIG. 10, and the branch according to the value of HammingDistance in FIG. It just turns into a branch along the value of.
  • FIG. 25 is a flowchart showing an example of a processing procedure by the PQLSH neighborhood development index information generator 250.
  • the PQLSH neighborhood development index information generator 250 executes, for example, the following steps S1201 to S1210, PQLSH neighborhood expansion index information 40D including is stored in the database 400.
  • Step S1201 The PQLSH neighborhood expansion index information generator 250 stores a name: HashValue / type: blob column, a name: Distance / type: real column, a name: DataRowID / type: integer column in the database 400. (An empty PQLSH neighborhood expansion table) is generated.
  • the table name format is “AAAA_BBBB_CCCC_DDDD”.
  • AAAA is the table name of the data table 20 to be processed
  • BBBB is the column name of the column to be processed
  • CCCC is the algorithm name of the direct product quantization LSH algorithm
  • DDDD is the name of the model (setting and analysis results related to the algorithm).
  • a table name such as aTable_feat_PQ_confA is given to the generated table.
  • Step S1202 The PQLSH neighborhood expansion index information generator 250 sequentially extracts the feature vector of the column specified by the index construction command statement 30 from the data table 20 designated by the index construction command statement 30.
  • Step S1203 The PQLSH neighborhood expansion index information generator 250 uses the direct product quantized LSH algorithm and model specified by the index construction instruction statement 30 for the feature vector (case vector) extracted in Step S1202, and uses the case hash Is generated.
  • Step S1204 The PQLSH neighborhood development index information generator 250 generates all the peripheral hashes whose distance from the case hash obtained in Step S1203 is equal to or less than the specified distance. However, the distance between the example hash serving as a starting point and each of the neighboring hashes is estimated using a model of the direct product quantization LSH algorithm.
  • Step S1205 The PQLSH neighborhood expansion index information generator 250 sequentially extracts the peripheral hashes obtained in step S1204.
  • Step S1206 The PQLSH neighborhood expansion index information generator 250 generates the row ID of the record in the data table 20 to which the peripheral hash extracted in Step S1205, the distance from the starting case hash, and the case vector that is the base of the case hash belongs. Are added to the PQLSH neighborhood expansion table.
  • Step S1207 The PQLSH neighborhood expansion index information generator 250 determines whether or not all the peripheral hashes obtained in step S1204 have been extracted. If the determination result is No, the process returns to step S1205 and the subsequent processing is repeated. If the determination result is Yes, the process proceeds to step S1208.
  • Step S1208 The PQLSH neighborhood expansion index information generator 250 determines whether or not all feature vectors have been extracted from the data table 20 to be processed. If the determination result is No, the process returns to step S1202 and the subsequent processing is repeated. If the determination result is Yes, the process proceeds to step S1209.
  • Step S1209 The PQLSH neighborhood development index information generator 250 constructs a database composite index (composite index) for the HashValue column and the Distance column of the PQLSH neighborhood development table generated through the above processing and stores it in the database 400.
  • Step S1210 The PQLSH neighborhood expansion index information generator 250 stores the model of the direct product quantization LSH algorithm used for generating the case hash in the database 400 with the same file name as the table name (for example, aTable_feat_PQ_confA).
  • the method for generating the peripheral hash in step S1204 described above uses a method similar to that in the first embodiment, but in this embodiment, not only which element of the hash is changed, but also how much the value is changed. It is necessary to decide. For this, for example, a best priority search such as Dijkstra method may be used.
  • FIG. 26 is a block diagram illustrating a configuration example of the searcher 300B of the present embodiment.
  • the vector similarity determination processing unit 330B performs the linear LSH search unit 332, database index LSH search unit 333, database index LSH search + exact search unit 334, and database index LSH search shown in FIG.
  • a linear PQLSH search unit 351, a database index PQLSH search unit 352, a database index PQLSH search + exact search unit 353, and a database index PQLSH search + linear PQLSH search unit 354 are provided.
  • the linear PQLSH search unit 351 is the same as the linear LSH search unit 332 of the first embodiment, except that the vector to be handled changes from a binary vector to an integer vector in accordance with the implementation change from the first embodiment. Further, for the database index PQLSH search + exact search unit 353 and the database index PQLSH search + linear PQLSH search unit 354, the search method in the previous stage of the two-stage narrowing down method is changed from the database index LSH search to the database index PQLSH search. This is the same as the database index LSH search + exact search unit 334 and the database index LSH search + linear LSH search unit 335 of the first embodiment.
  • linear PQLSH search unit 351 the database index PQLSH search + exact search unit 353, and the database index PQLSH search + linear PQLSH search unit 354 is omitted, and the database index PQLSH search unit 352 that performs the database index PQLSH search. Only will be described. Note that the linear LSH search can be used as it is without changing from the first embodiment.
  • FIG. 27 is a flowchart illustrating an example of a processing procedure performed by the database index PQLSH search unit 352.
  • the database index PQLSH search unit 352 executes, for example, the following steps S1301 to S1310 and outputs a search result 80.
  • Step S1301 The database index PQLSH search unit 352 generates an empty search result set.
  • Step S1302 The database index PQLSH search unit 352 acquires a query vector specified as an argument of the vnn function, an algorithm name of a direct product quantization LSH algorithm, and an optional parameter, and generates a query hash.
  • Step S1303 The database index PQLSH search unit 352 acquires the table name of the search target data set 70, the column storing the case vector specified as the argument of the vnn function, the algorithm name of the direct product quantization LSH algorithm, and optional parameters. Then, a PQLSH neighborhood expansion table having a table name determined based on these is acquired.
  • Step S1304 The database index PQLSH search unit 352 assigns 0 to the distance condition variable.
  • Step S1305 The database index PQLSH search unit 352 generates a value in the Distance column that is less than or equal to the current value of the distance condition variable and a value in the HashValue column in Step S1302 with respect to the PQLSH neighborhood expansion table acquired in Step S1303.
  • the record group that matches the query hash that has been searched is searched, and the obtained set of row IDs is added to the search result set.
  • Step S1306 The database index PQLSH search unit 352 removes duplicate elements from the search result set.
  • Step S1307 The database index PQLSH search unit 352 determines whether or not the number of elements in the search result set is equal to or greater than the number of upper output items specified as the third argument of the vnn function. If the determination result is No, the process proceeds to step S1308, and if Yes, the process proceeds to step S1310.
  • Step S1308 The database index PQLSH search unit 352 adds a certain amount of the distance condition variable.
  • Step S1309 The database index PQLSH search unit 352 determines whether or not the value of the Hamming distance condition variable is less than or equal to the upper limit of the distance in the PQLSH neighborhood expansion table. If the determination result is Yes, the process returns to step S1305 and the subsequent processing is repeated. If the determination result is No, the process proceeds to step S1310.
  • Step S1310 The database index PQLSH search unit 352 outputs the search result set as the search result 80, and ends the process.
  • the data management system generates the index information 40 including the PQLSH neighborhood expansion index information 40D by the pre-processing, and the index information 40 is retrieved during the search.
  • a vector neighborhood search is performed on the data table 20 by a method with a small amount of calculation, such as specifying a case vector corresponding to a peripheral vector that completely matches the query vector. Therefore, similarly to the first embodiment, the calculation amount of the vector neighborhood search that occupies most of the calculation amount in the conventional similar search can be reduced, and the execution time of the data search can be shortened.
  • the data management system of the above-described embodiment can be implemented by a program that operates in an execution environment using hardware as a general computer.
  • the above-described functional components (the data register 100, the index builder 200 (index builder 200B), and the searcher 300 (searcher 300A, searcher 300B)) in the data management system of this embodiment are as follows. It is realized by cooperation between hardware and software (program).
  • the database 400 is realized by an arbitrary memory resource accessible by a program.
  • FIG. 28 is a block diagram illustrating a hardware configuration example of the data management system.
  • the data management system includes a processor circuit such as a CPU (Central Processing Unit) 1001, a storage device such as a ROM (Read Only Memory) 1002 and a RAM (Random Access Memory) 1003, a display panel, and various operations.
  • a processor circuit such as a CPU (Central Processing Unit) 1001, a storage device such as a ROM (Read Only Memory) 1002 and a RAM (Random Access Memory) 1003, a display panel, and various operations.
  • a hardware configuration using a normal computer including an input / output I / F 1004 to which devices are connected, a communication I / F 1005 that performs communication by connecting to a network, a bus 1006 that connects each unit, and the like can be employed.
  • the program executed on the hardware having the above-described configuration is, for example, a CD-ROM (Compact Disk Read Only Memory), a flexible disk (FD), a CD-R in an installable or executable file. (Compact Disk Recordable), DVD (Digital Versatile Disc), etc., recorded on a computer-readable recording medium and provided as a computer program product.
  • the program executed on the hardware configured as described above may be stored on a computer connected to a network such as the Internet and provided by being downloaded via the network.
  • the program executed on the hardware having the above-described configuration may be provided or distributed via a network such as the Internet. Further, the program executed on the hardware having the above-described configuration may be provided by being incorporated in the ROM 1002 in advance.
  • the program executed on the hardware having the above-described configuration has a module configuration including each functional component of the data management system of the embodiment.
  • the CPU 1001 processor circuit
  • each unit described above is loaded onto the RAM 1003 (main memory) and generated on the RAM 1003 (main memory).
  • each functional component of the data management system of the embodiment and the database 400 may be configured to be implemented across a plurality of computers.
  • some or all of the functional components described above can be realized by using dedicated hardware such as ASIC (Application Specific Integrated Circuit) or FPGA (Field-Programmable Gate Array).

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

Abstract

実施形態のデータ管理システムは、索引構築器（２００）と、検索器（３００）と、を備える。索引構築器（２００）は、蓄積するデータの特徴ベクトルである事例ベクトルに類似する周辺ベクトルを生成するとともに、周辺ベクトルから事例ベクトルを特定するための索引情報（４０）を構築する。検索器（３００）は、任意の特徴ベクトルであるクエリベクトルを指定した検索要求に応じて、索引情報（４０）を用いて、クエリベクトルと完全一致する周辺ベクトルに対応する事例ベクトルを特定し、特定した事例ベクトルに基づく検索結果データセット（６０）を出力する。

Description

データ管理システム、データ管理方法およびプログラム
　本発明の実施形態は、データ管理システム、データ管理方法およびプログラムに関する。
　近年、情報通信技術の進展に伴って、多種多様なデータの収集や蓄積が可能となり、ビッグデータ分析やビッグメディア解析などといった大規模データを対象とする情報処理技術が注目を浴びている。こうした大規模データを取り扱うシステムでは、データ規模の加速度的な拡大に伴う計算量の肥大化がサービス低下に繋がるため、いかに計算量を削減できるかが重要な課題となっている。
　データベース検索などのデータ検索では、画像や音楽などのメディア検索を高速に行う方法として、多次元の特徴ベクトルを用いた類似検索が行われる。この類似検索では、特徴ベクトル間の類似度計算を含むベクトル近傍検索、すなわち、ある特徴ベクトル（以下、これを「クエリベクトル」という）に近い特徴ベクトル群を、検索対象となる特徴ベクトル（以下、これを「事例ベクトル」という）群の中から見つけ出す処理が計算量の多くを占めている。このため、ベクトル近傍検索の計算量を削減してデータ検索の実行時間を短縮できるようにすることが求められている。
特開２０００－３５９６５号公報 特開２００１－５２０２４号公報
　本発明が解決しようとする課題は、ベクトル近傍検索の計算量を削減してデータ検索の実行時間を短縮できるデータ管理システム、データ管理方法およびプログラムを提供することである。
　実施形態のデータ管理システムは、索引構築部と、検索部と、を備える。索引構築部は、蓄積するデータの特徴ベクトルである事例ベクトルに類似する周辺ベクトルを生成し、生成した前記周辺ベクトルに対応する前記事例ベクトルを特定するための索引情報を構築する。検索部は、任意の特徴ベクトルであるクエリベクトルを指定した検索要求に応じて、前記索引情報を用いて、前記クエリベクトルと完全一致する前記周辺ベクトルに対応する前記事例ベクトルを特定し、特定した前記事例ベクトルに基づく検索結果を出力する。
図１は、第１実施形態のデータ管理システムの概要を示すシステム構成図である。 図２は、データテーブルの具体例を示す図である。 図３は、メディアデータが静止画である場合のデータ登録器による処理手順の一例を示すフローチャートである。 図４は、メディアデータが動画である場合のデータ登録器による処理手順の一例を示すフローチャートである。 図５は、索引構築器の構成例を示すブロック図である。 図６は、ＬＳＨ即値テーブルの一例を示す図である。 図７は、ＬＳＨ即値索引情報生成器による処理手順の一例を示すフローチャートである。 図８は、ＬＳＨ近傍展開テーブルの一例を示す図である。 図９は、ＬＳＨ近傍展開テーブルを２つに分割することで正規化した例を示す図である。 図１０は、データベース複合索引の一例を示す図である。 図１１は、ＬＳＨ近傍展開索引情報生成器による処理手順の一例を示すフローチャートである。 図１２は、連想配列と連続メモリ配置型配列を説明する図である。 図１３は、検索器の構成例を示すブロック図である。 図１４は、ベクトル類似性判定部の入出力関係を示す図である。 図１５は、ベクトル類似性判定部による処理手順の一例を示すフローチャートである。 図１６は、厳密検索器による処理手順の一例を示すフローチャートである。 図１７は、線形ＬＳＨ検索器による処理手順の一例を示すフローチャートである。 図１８は、データベース索引ＬＳＨ検索器による処理手順の一例を示すフローチャートである。 図１９は、データベース索引ＬＳＨ検索＋厳密検索器による処理手順の一例を示すフローチャートである。 図２０は、データベース索引ＬＳＨ検索＋線形ＬＳＨ検索器による処理手順の一例を示すフローチャートである。 図２１は、第２実施形態の検索器の構成例を示すブロック図である。 図２２は、クエリ摂動型ＬＳＨ検索器による処理手順の一例を示すフローチャートである。 図２３は、第３実施形態の索引構築器の構成例を示すブロック図である。 図２４は、ＰＱＬＳＨ近傍展開テーブルの一例を示す図である。 図２５は、ＰＱＬＳＨ近傍展開索引情報生成器による処理手順の一例を示すフローチャートである。 図２６は、第３実施形態の検索器の構成例を示すブロック図である。 図２７は、データベース索引ＰＱＬＳＨ検索器による処理手順の一例を示すフローチャートである。 図２８は、データ管理システムのハードウェア構成例を示すブロック図である。
　以下、実施形態のデータ管理システム、データ管理方法およびプログラムを、図面を参照して詳細に説明する。
　実施形態のデータ管理システムは、大規模データを効率よく管理・検索するためのシステムである。データベース管理システムにみられるような大規模データを管理する従来のシステムは、一般的に、下位層としてディスクアクセスなどを最適化するデータ配置機構、上位層として検索条件に基づいて大規模データを高速検索するための索引機構が搭載されている。索引のアルゴリズムには、Ｂツリーなどの木構造アルゴリズムや、一般的なハッシュアルゴリズムが主に用いられている。
　データベースで利用できる検索条件は、多くの場合、実数・整数・文字列・日付などの基本型（以下、これらを総称して「ＤＢ基本型」と呼ぶ）に関する四則演算・集合演算などで構成された論理式である。ベクトルやビット列（すなわち二値ベクトル）同士の類似性については、一部の例外を除き、通常、検索条件として用いることができない。その背景には、ベクトルの類似度計算を含む検索条件を効率化する索引が考案されていないことがある。
　上述の一部の例外とは、低次元ベクトルを対象とした類似度計算である。多くの著名なデータベース管理システムでは、主に時空間データを管理する用途を想定して、２～４次元程度の低次元のベクトルの類似度計算を検索条件に含めることができるようになっている。この類似度計算の実現には、空間木（空間分割法）と呼ばれる索引手法が用いられており、これにより高速な検索が可能である。ただしベクトルが低次元でない場合は、索引サイズの肥大化によって高速化の効果が失われ、実行時間が通常の線形検索と変わらなくなることが知られている。実施形態で想定する特徴ベクトルは、例えば機械学習用途を想定した数百～数億次元の高次元ベクトルであるため、空間木による方法を用いても高速な検索は実現できない。
　しかし、高次元ベクトルの完全一致を高速照合することは可能である。この場合、２つのベクトルの各次元の要素に対する等号条件をＡＮＤで結合した条件で検索することと等価である。すなわち、この検索条件はスカラ演算のみで構成されており、ベクトルの類似度計算は含まれていないため、Ｂツリーなどの索引を利用できる。
　以上のように、従来の一般的なデータベース管理システムは、ＤＢ基本型で構成された検索条件での大規模データの高速検索が可能であるが、低次元でないベクトル間の類似度計算を含むベクトル近傍検索を高速実行することはできない。そこで、以下に示す実施形態では、ベクトル近傍検索の計算量を削減することでベクトル近傍検索の高速実行を可能とし、データ検索の実行時間を短縮できる新規なデータ管理システムを提案する。
　なお、ベクトル間の類似度を表す指標としては内積と距離がある。ベクトル間の内積値を求める内積計算とベクトル間の距離を求める距離計算は、意味としても計算量としてもほぼ同じである。２つのベクトルが類似している場合、内積値は大きくなるが、距離は小さくなるという点が異なるだけである。つまり、ベクトル間の内積値が大きいことと、ベクトル間の距離が小さいことは、ともにベクトル間の類似度が高いことを意味する。以下では、ベクトル間の類似度を距離で表すものとして説明するが、距離を内積に置き換えてもよい。この場合、ベクトル間の距離が小さいほど、つまり、ベクトル間の類似度が高いほど、内積値が大きくなるものと考えればよい。
　ベクトル近傍検索の計算量を削減する方法として、ＬＳＨ（Locality-Sensitive　Hashing）を用いることが考えられる。ＬＳＨは、与えられたベクトル群を、離散値のみを取る縮約ベクトル空間に写像する技術である（例えば、下記の参考文献１参照）。このＬＳＨによる写像は、写像前の空間におけるベクトル間の距離の相対的な大きさが、写像後の空間においてもよく保存されているという性質がある。したがって、写像前のベクトル空間でベクトル間距離を計算する代わりに、写像後のベクトル空間でベクトル間距離を計算することで、計算を効率化することができる。ただし、距離の大小関係を完全に保存するわけではないため、得られるのは近似解である。
　参考文献１：Anshumali　Shrivastava　and　Ping　Li，“Asymmetric　LSH（ALSH）　for　Sublinear　Time　Maximum　Inner　Product　Search（MIPS）”，Advances　in　Neural　Information　Processing　Systems，2014．
　ＬＳＨアルゴリズムとしては、これまでに、例えば、下記の参考文献２に示されるSimHash（Random　projection）や、下記の参考文献３に示されるSpectral　Hashingなど、様々なアルゴリズムが考案されている。
　参考文献２：Moses　S．Charikar，“Similarity　Estimation　Techniques　from　Rounding　Algorithms”，Proceedings　of　the　34th　Annual　ACM　Symposium　on　Theory　of　Computing，pp．380?388，doi：10，1145／509907，509965．
　参考文献３：Yair　Weiss，Antonio　Torralba　and　Rob　Fergus，“Spectral　Hashing”，Advances　in　neural　information　processing　systems，2009．
　ＬＳＨアルゴリズムは、大きく、ビットワイズ方式と直積量子化（Product　Quantization）方式とに二分できる。ビットワイズ方式のアルゴリズムは、与えられたベクトルに対する写像結果として二値ベクトルを出力する。一方、直積量子化方式のアルゴリズムは、与えられたベクトルに対する写像結果として整数ベクトル（整数の要素からのみ構成される多値ベクトル）を出力する。また、直積量子化方式のアルゴリズムの場合、ベクトルの各次元ごとに、距離に対する重みに相当する情報（各次元の変化に対してベクトルの距離がどれくらい変化するか）も合わせて生成される。
　上述のように、ＬＳＨによって写像されたベクトルを用いることで、ベクトル間距離の計算を効率化することができる。特に二値ベクトルの場合、距離計算処理に、xorなどのビット演算命令、あるいはpopcountなどの専用ＣＰＵ命令を用いることができるため、大幅な計算量削減が可能である。
　しかし、ＬＳＨを用いたとしても、ベクトル間距離の計算そのものを回避することはできない。従来のデータベース管理システムでは、上述のように、低次元でないベクトルの距離計算を伴う検索処理に対して有効な索引アルゴリズムが考案されていないため、線形検索を行う必要があり、計算量オーダーをサブリニアにすることができない。その結果、検索対象となる事例ベクトルの数が例えば１億など大規模な場合には、大きな検索時間を要することとなる。そこで、低次元でないベクトルの距離計算を伴う検索処理に対して有効な索引アルゴリズムを導入した新規なデータ管理システムを提案する。
　ここで、実施形態の基本原理を説明する。実施形態のデータ管理システムは、まず事前処理として、各事例ベクトルのそれぞれについて、事例ベクトルに類似するベクトル、つまり事例ベクトルに対する距離が所定値以下のベクトル（以下、これを「周辺ベクトル」と呼ぶ）群を生成するとともに、周辺ベクトルから事例ベクトルを特定するための索引情報を構築し、事例ベクトルを含むデータと索引情報とをデータベースに保存する。そして、検索時には、索引情報に基づいて、クエリベクトルと完全一致する周辺ベクトルに対応する事例ベクトルを特定し、特定した事例ベクトルに基づいて、検索要求に対する検索結果を出力する。
　事前処理で事例ベクトルに類似する周辺ベクトルを合理的に生成するには、取り扱うベクトルの次元数および各要素値集合のカーディナリティがいずれも小さい必要がある。この条件が満たされなければ、周辺ベクトル数が爆発し、結果として検索時間を短縮できない。この条件を達成するために、上述したＬＳＨを用いる。ＬＳＨにより生成されるベクトルの要素は、ビットワイズ方式の場合は二値、直積量子化方式の場合は多値を持つ離散値を取り、ＬＳＨの設定にもよるが、多くの場合、要素値集合のカーディナリティおよび次元数が小さい離散ベクトル（縮約ベクトル）が生成される。したがって、基本原理として説明した上述の方法を実行する前に、ＬＳＨを用いて事例ベクトル群およびクエリベクトルを縮約ベクトルに変換しておき、これらを用いて、基本原理として説明した上述の方法による検索を行えばよい。ただし、ＬＳＨを用いるため、検索結果は近似解となる。
　なお、事例ベクトル群やクエリベクトルが元々上記条件を満たすベクトルであるならば、ＬＳＨを用いたベクトル変換を事前に行う必要はなく、基本原理として説明した上述の方法のみを実行すればよい。
　また、基本原理として説明した上述の方法では、事例ベクトルに対する距離が所定値以下の周辺ベクトルを生成したが、クエリベクトルに対する距離が所定値以下の周辺ベクトルを生成する構成としてもよい。この場合、検索時に、クエリベクトルに対する距離が所定値以下の周辺ベクトルを生成して、周辺ベクトルと完全一致する事例ベクトルを特定し、特定した事例ベクトルに基づいて、検索要求に対する検索結果を出力する。
　以下では、ベクトル間距離の計算が検索条件に含まれるクエリを処理してメディア検索を行うデータ管理システムへの適用例について具体的に説明する。メディア検索の応用題材としては、顔画像（映像含む）検索を取り上げる。顔画像検索は、システムに予め登録された画像・映像などのメディア群の中から、クエリとして与えられた画像・映像に含まれる顔と似た顔を含む画像・映像の箇所を見つけ出す処理である。なお、ここでは応用題材として顔画像検索を取り上げるが、実施形態のデータ管理システムは、例えば、音楽検索、物体画像検索、シーン画像検索、テキスト意味検索、センサパタン検索、株価パタン検索、電力使用パタン検索など、様々なメディア検索やセンサデータ検索に応用することができる。
＜第１実施形態＞
　まず、第１実施形態のデータ管理システムについて説明する。本実施形態では、写像処理にはビットワイズＬＳＨを用いるものとし、写像後の二値ベクトル（ハッシュ）間の距離としてハミング距離を用いるものとする。ただし、上述したように、取り扱う事例ベクトルおよびクエリベクトルが元々低次元の二値ベクトルであるならば、ビットワイズＬＳＨによる写像は不要であり、後述の事例ハッシュ（縮約事例ベクトル）として事例ベクトルをそのまま用い、クエリハッシュ（縮約クエリベクトル）としてクエリベクトルをそのまま用いればよい。また、この場合、後述の周辺ハッシュ（縮約周辺ベクトル）として、事例ベクトルを元に生成される周辺ベクトルを用いればよい。
　図１は、第１実施形態のデータ管理システムの概要を示すシステム構成図である。本実施形態のデータ管理システムは、図１に示すように、データ登録器１００と、索引構築器２００と、検索器３００と、データベース４００とを備える。
　データ登録器１００は、顔を含む画像や映像などのメディアデータ群１０を外部から受け取り、受け取ったメディアデータ群１０を対象として顔に関する解析を行い、顔特徴に関する特徴ベクトル（事例ベクトル）群を含むデータテーブル２０をデータベース４００内に生成する。
　索引構築器２００は、索引構築命令文３０を外部から受け取ると、受け取った索引構築命令文３０に対応するデータテーブル２０をデータベース４００から取り出し、索引構築命令文３０の命令に従って、顔特徴ベクトルの索引として用いる索引情報４０をデータベース４００内に生成する。
　検索器３００は、顔特徴に関するクエリベクトルを含む拡張ＳＱＬ５０（検索要求の一例）を外部から受け取ると、データベース４００から該当するデータテーブル２０および索引情報４０を取得し、拡張ＳＱＬ５０に含まれるクエリベクトルと類似する顔特徴ベクトルが含まれる検索結果データセット６０を出力する。
　まず、データ登録器１００の詳細を説明する。図２は、データ登録器１００がデータベース４００内に生成するデータテーブル２０の具体例を示す図である。データ登録器１００が外部から受け取るメディアデータ群１０に含まれるメディアデータは、dir/a.jpg、dir/b.jpg、dir/a.mpgの３種類のファイルであるものとする。このうち、dir/a.jpg、dir/b.jpgは静止画ファイルであり、dir/a.mpgは動画ファイルである。
　データ登録器１００は、外部からメディアデータ群１０を受け取ると、このメディアデータ群１０に含まれるメディアデータそれぞれについて、以下に示す処理を実行する。
　図３は、メディアデータが静止画である場合のデータ登録器１００による処理手順の一例を示すフローチャートである。データ登録器１００は、メディアデータが静止画である場合、例えば以下のステップＳ１０１～ステップＳ１０５の処理を実行して、メディアデータをデータテーブル２０に登録する。
　ステップＳ１０１：データ登録器１００は、入力された静止画に対して顔領域抽出処理を行う。この結果、入力された静止画から、顔が写っている可能性の高い画像領域（顔画像領域）がすべて抽出される。なお、顔領域抽出処理は既存技術を用いればよいため、ここでは詳細な説明を省略する。
　ステップＳ１０２：データ登録器１００は、ステップＳ１０１で抽出した顔画像領域を順に取り出す。
　ステップＳ１０３：データ登録器１００は、ステップＳ１０２で取り出した顔画像領域に対して特徴生成処理を行って特徴ベクトル（事例ベクトル）を得る。なお、特徴生成処理には既存技術を用いればよいため、ここでは詳細な説明を省略する。
　ステップＳ１０４：データ登録器１００は、ステップＳ１０３で得られた特徴ベクトル、入力された静止画に与えられたメディアデータ名、顔画像領域の座標の３つの情報を含むレコードをデータテーブル２０に追加する。
　ステップＳ１０５：データ登録器１００は、ステップＳ１０１で抽出した顔画像領域をすべて取り出したか否かを判定する。そして、判定の結果がＮｏであればステップＳ１０２に戻って以降の処理を繰り返し、判定の結果がＹｅｓであれば処理を終了する。
　図４は、メディアデータが動画である場合のデータ登録器１００による処理手順の一例を示すフローチャートである。データ登録器１００は、メディアデータが動画である場合、例えば以下のステップＳ２０１～ステップＳ２１２の処理を実行して、メディアデータをデータテーブル２０に登録する。
　ステップＳ２０１：データ登録器１００は、入力された動画から先頭フレーム画像を取り出す。
　ステップＳ２０２：データ登録器１００は、ステップＳ２０１で取り出した先頭フレーム画像に対して顔領域抽出処理および特徴生成処理を行う。この結果、顔が写っている可能性の高い画像領域（顔画像領域）が確信度付ですべて抽出され、それぞれの顔画像領域から特徴ベクトルが得られる。
　ステップＳ２０３：データ登録器１００は、入力された動画から次のフレーム画像を取り出す。
　ステップＳ２０４：データ登録器１００は、ステップＳ２０３で取り出したフレーム画像に対して、ステップＳ２０２と同様の顔領域抽出処理および特徴生成処理を行う。
　ステップＳ２０５：データ登録器１００は、当該フレームについて、前フレームとの間で顔追跡処理を行う。顔追跡処理とは、フレーム間で画像と領域座標が類似する顔画像領域のペアを見つけ出し、これらを同一被写体と解釈する処理である。なお、顔追跡処理は既存技術を用いればよいため、ここでは詳細な説明を省略する。
　ステップＳ２０６：データ登録器１００は、ステップＳ２０５の顔追跡処理の結果、同一被写体と判定された顔画像領域を同一グループとして束ねる。
　ステップＳ２０７：データ登録器１００は、次のフレームがあるか否かを判定する。そして、判定の結果がＹｅｓであればステップＳ２０３に戻って以降の処理を繰り返し、ＮｏであればステップＳ２０８に進む。
　ステップＳ２０８：データ登録器１００は、以上の処理により生成されたグループを順に取り出す。
　ステップＳ２０９：データ登録器１００は、ステップＳ２０８で取り出したグループに含まれるフレームのうち、最も早く出現したフレームの出現時刻である第１出現時刻と、最も遅く出現したフレームの出現時刻である第２出現時刻とを取得する。
　ステップＳ２１０：データ登録器１００は、ステップＳ２０８で取り出したグループに含まれるフレームのうち最も確信度の高いフレームの出現時刻である第３出現時刻と、特徴ベクトルと、顔画像領域の座標とを取得する。
　ステップＳ２１１：データ登録器１００は、ステップＳ２０９で取得した第１出現時刻および第２出現時刻と、ステップＳ２１０で取得した第３出現時刻、特徴ベクトル、および顔画像領域の座標と、入力された動画に与えられたメディアデータ名との６つの情報を含むレコードをデータテーブル２０に追加する。
　ステップＳ２１２：データ登録器１００は、生成されたグループをすべて取り出したか否かを判定する。そして、判定の結果がＮｏであればステップＳ２０８に戻って以降の処理を繰り返し、判定の結果がＹｅｓであれば処理を終了する。
　次に、索引構築器２００の詳細を説明する。索引構築器２００がデータベース４００内に生成する索引情報４０は、特徴ベクトルを列に持つデータテーブル２０に対するベクトル近傍検索を高速化するための補助情報である。索引構築器２００は、入力された索引構築命令文３０のタイプに応じて、ＬＳＨ即値索引情報とＬＳＨ近傍展開索引情報との２種類の索引情報４０を生成することができる。この索引情報４０には、後述するテーブルデータとデータベース索引（Ｂツリーなど）が含まれる。
　索引構築器２００は、データテーブル２０の特徴ベクトルを格納する同一の行に対してハッシュのビット長の指定が異なる複数の索引構築命令文３０を実行することにより、複数の索引情報４０を構築することができる。例えば、ビット長が短いハッシュを用いた索引情報４０とビット長が長いハッシュを用いた索引情報４０との２種類を構築しておけば、精度より速度を重視した検索を行う場合は前者の索引情報４０を用い、速度より精度を重視した検索を行う場合は後者の索引情報４０を用いるといったように、検索時に用途に応じた使い分けができるようになる。
　図５は、索引構築器２００の構成例を示すブロック図である。索引構築器２００は、図５に示すように、索引構築命令タイプ分類器２１０と、ＬＳＨ即値索引情報生成器２２０と、ＬＳＨ近傍展開索引情報生成器２３０とを備える。
　索引構築命令タイプ分類器２１０は、索引構築器２００に入力された索引構築命令文３０を、そのタイプに応じて、ＬＳＨ即値索引情報作成器２２０とＬＳＨ近傍展開索引情報生成器２３０とのいずれかに受け渡すスイッチャである。
　索引構築器２００に入力される索引構築命令文３０は、例えば、以下のような構成の命令文である。ただしxxxx部には何らかの値が入る。
　Table:xxxx,Column:xxxx,Algo:xxxx,BitLen:xxxx,HammingDist:xxxx
　上記構成の索引構築命令文３０は、Table項目で、索引情報４０の対象となるデータテーブル２０のテーブル名が指定され、Column項目で、索引情報４０の対象となるデータテーブル２０内の列名が指定される。この列名が示すデータテーブル２０内の列には、特徴ベクトルが格納されている必要がある。
　また、Algo項目では、索引情報４０の生成に用いるＬＳＨアルゴリズムのアルゴリズム名が指定される。アルゴリズム名は、システム内に実装されているＬＳＨアルゴリズムの中から選ばれる。例えば、システム内にSimHashという名前のＬＳＨアルゴリズムとSpectralHashという名前のＬＳＨアルゴリズムのみが実装されているとすれば、これらのいずれかのアルゴリズム名が指定される。本実施形態では、上述したように、ビットワイズＬＳＨを用いるため、ビットワイズＬＳＨのアルゴリズム名が指定される。
　Bitlen項目では、Algo項目で選んだＬＳＨアルゴリズムが出力するハッシュのビット長が指定される。HammingDist項目では、ＬＳＨ近傍展開索引情報生成器２３０において扱われるハミング距離の上限（後述の周辺ハッシュの範囲）が指定される。例えばHammingDist項目で“２”が指定されている場合、ＬＳＨ近傍展開索引情報生成器２３０において扱われるハミング距離は“０”と“１”と“２”である。なお、HammingDist項目は省略してもよい。
　索引構築命令タイプ分類器２１０は、以上のように構成される索引構築命令文３０が索引構築器２００に入力されると、この索引構築命令文３０を、ＬＳＨ即値索引情報生成器２２０とＬＳＨ近傍展開索引情報生成器２３０のいずれかに渡す。例えば、索引構築命令タイプ分類器２１０は、索引構築器２００に入力された索引構築命令文３０にHammingDist項目がなければ、この索引構築命令文３０をＬＳＨ即値索引情報生成器２２０に渡し、HammingDist項目があれば、この索引構築命令文３０をＬＳＨ近傍展開索引情報生成器２３０に渡す。
　ＬＳＨ即値索引情報生成器２２０は、索引構築命令タイプ分類器２１０から索引構築命令文３０を受け取った場合に、この索引構築命令文３０に従って、ＬＳＨ即値テーブルと、このＬＳＨ即値テーブルのHashValue列に対するデータベース索引とを含むＬＳＨ即値索引情報４０Ａを生成する。
　図６は、ＬＳＨ即値テーブルの一例を示す図である。ＬＳＨ即値テーブルは、図６に示すように、HashValue列（型：blob）のみからなるテーブルデータである。ＬＳＨ即値索引情報生成器２２０は、索引構築命令文３０で指定されたデータテーブル２０の各レコードに対して、指定された列に格納される特徴ベクトルを順に取り出し、指定されたＬＳＨアルゴリズムを用いて、指定された出力ビット長のハッシュを生成し、得られた各ハッシュのみを持つレコードをＬＳＨ即値テーブルに登録する。
　なお、ハッシュは本質的には二値ベクトルであるが、本実施形態ではハッシュをブール値の配列として保存するのではなく、二進数と見立てて整数として保存する。すなわち、ＬＳＨ即値テーブルのHashValue列は、整数または整数配列（計算機アーキテクチャのビット数上限を超えた場合の処置）を格納するblobである。これにより、保存領域サイズを削減することができる。
　なお、このＬＳＨ即値テーブルをデータテーブル２０に組み込む構成としてもよい。このような構成とすることにより、検索全体の処理においてサブクエリ処理を１回減らすことができる。ＬＳＨ即値テーブルをデータテーブル２０に組み込むためには、上述のデータ登録器１００がデータテーブル２０を生成する際に、このデータテーブル２０にハッシュを格納する列を予め用意しておく必要がある。また、上述したように、データテーブル２０の特徴ベクトルを格納する同一の行に対して複数の索引情報４０を構築できるようにするためには、データテーブル２０内にビット長が異なる複数種類のハッシュを格納する複数の列を確保しておく必要がある。このような構成とした場合、ＬＳＨ即値索引情報生成器２２０は、特徴ベクトルを元に生成したハッシュをＬＳＨ即値テーブルに登録する代わりに、データテーブル２０の該当する列に格納すればよい。
　ＬＳＨ即値索引情報生成器２２０は、以上のようなＬＳＨ即値テーブルの生成と合せて、ＬＳＨ即値テーブルのHashValue列に対するデータベース索引を構築し、これらをＬＳＨ即値索引情報４０Ａとしてデータベース４００内に保存する。
　図７は、ＬＳＨ即値索引情報生成器２２０による処理手順の一例を示すフローチャートである。ＬＳＨ即値索引情報生成器２２０は、索引構築命令タイプ分類器２１０から索引構築命令文３０を受け取ると、例えば以下のステップＳ３０１～ステップＳ３０７の処理を実行し、ＬＳＨ即値テーブルとデータベース索引とを含むＬＳＨ即値索引情報４０Ａをデータベース４００に保存する。
　ステップＳ３０１：ＬＳＨ即値索引情報生成器２２０は、データベース４００内に、名前：HashValue・型：blobの列のみを持つテーブル（空のＬＳＨ即値テーブル）を生成する。なお、テーブル名の形式は「AAAA_BBBB_CCCC_DDDD」とする。ただし、AAAAは処理対象のデータテーブル２０のテーブル名、BBBBは処理対象の列の列名、CCCCはＬＳＨアルゴリズムのアルゴリズム名、DDDDはビット長とする。例えば、aTable_feat_SimHash_64といったテーブル名が生成したテーブルに与えられる。
　ステップＳ３０２：ＬＳＨ即値索引情報生成器２２０は、索引構築命令文３０で指定されたデータテーブル２０から、索引構築命令文３０で指定された列の特徴ベクトルを順に取り出す。
　ステップＳ３０３：ＬＳＨ即値索引情報生成器２２０は、ステップＳ３０２で取り出した特徴ベクトルに対して、索引構築命令文３０で指定されたＬＳＨアルゴリズムを用いて、索引構築命令文３０で指定された出力ビット長のハッシュを生成する。
　ステップＳ３０４：ＬＳＨ即値索引情報生成器２２０は、HashValue列の値としてステップＳ３０３で得られた事例ハッシュを持つレコードを、ＬＳＨ即値テーブルに追加する。
　ステップＳ３０５：ＬＳＨ即値索引情報生成器２２０は、処理対象のデータテーブル２０から特徴ベクトルをすべて取り出したか否かを判定する。そして、判定の結果がＮｏであればステップＳ３０２に戻って以降の処理を繰り返し、ＹｅｓであればステップＳ３０６に進む。
　ステップＳ３０６：ＬＳＨ即値索引情報生成器２２０は、以上の処理を経て生成されたＬＳＨ即値テーブルのHashValue列に対するデータベース索引（Ｂツリーなど）を構築し、データベース４００に保存する。
　ステップＳ３０７：ＬＳＨ即値索引情報生成器２２０は、ハッシュの生成に用いたＬＳＨアルゴリズムのモデルパラメタセットなど（例えばSimHashにおける射影ベクトル群など）があれば、テーブル名と同じファイル名（例えばaTable_feat_SimHash_64）でデータベース４００に保存する。
　ＬＳＨ近傍展開索引情報生成器２３０は、索引構築命令タイプ分類器２１０から索引構築命令文３０を受け取った場合に、この索引構築命令文３０に従って、ＬＳＨ近傍展開テーブルと、このＬＳＨ近傍展開テーブルのHashValue列およびHammingDistance列に対するデータベース複合索引（コンポジットインデックス）とを含むＬＳＨ近傍展開索引情報４０Ｂを生成する。
　図８は、ＬＳＨ近傍展開テーブルの一例を示す図である。ＬＳＨ近傍展開テーブルは、図８に示すように、HashValue列（型：blob）、HammingDistance列（型：integer）およびDataRowID列（型：integer）からなるテーブルデータである。ＬＳＨ近傍展開索引情報生成器２３０は、索引構築命令文３０で指定されたデータテーブル２０から特徴ベクトルを取り出し、各特徴ベクトル（事例ベクトル）について、索引構築命令文３０で指定されたＬＳＨアルゴリズムおよびビット長に従ってハッシュ（縮約事例ベクトル）を生成する。これを「事例ハッシュ」と呼ぶ。次に、ＬＳＨ近傍展開索引情報生成器２３０は、生成した各事例ハッシュについて、索引構築命令文３０で指定されたハミング距離以内のハッシュ（縮約周辺ベクトル）群を生成する。ここで生成されるハッシュを「周辺ハッシュ」と呼ぶ。そして、ＬＳＨ近傍展開索引情報生成器２３０は、例えば、周辺ハッシュと、周辺ハッシュの事例ハッシュからのハミング距離と、事例ハッシュの元になる事例ベクトルが属するデータテーブル２０のレコードの行ＩＤとの３つ組からなるレコードを、ＬＳＨ近傍展開テーブルに登録する。
　なお、本実施形態では、後述のデータベース索引ＬＳＨ検索処理において、検索条件として用いるハミング距離を０から順次インクリメントして検索結果を追加する処理を行う。このため、ＬＳＨ近傍展開テーブルの第２列にHammingDistance列を設け、周辺ハッシュの事例ハッシュからのハミング距離をこのHammingDistance列に格納している。しかし、検索時にＬＳＨ近傍展開テーブルの距離上限を検索条件として用いて検索を行う構成とすることも可能である。この場合、ＬＳＨ近傍展開テーブルにHammingDistance列を設ける必要はない。このような構成とした場合は、後述のデータベース索引ＬＳＨ検索処理において、出力する検索結果データセットの件数をハミング距離を利用して制御することはできなくなるが、ＬＳＨ近傍展開テーブルのサイズを小さくできる効果がある。また、このような構成とした場合は、ＬＳＨ近傍展開テーブルのHashValue列およびHammingDistance列に対するデータベース複合索引を構築する代わりに、ＬＳＨ近傍展開テーブルのHashValue列に対するデータベース索引を構築すればよい。
　また、図８に示したＬＳＨ近傍展開テーブルには、HashValue列に格納される周辺ハッシュの値として重複した値が多く含まれているため、正規化を行うことでコンパクト化することができる。
　図９は、図８に示したＬＳＨ近傍展開テーブルを２つに分割することで正規化した例を示す図である。ＬＳＨ近傍展開テーブルを図９のような構成とした場合、後述のデータベース索引ＬＳＨ検索処理において、HashValueとHammingDistanceに関する検索条件を用いて図９（ａ）のテーブルの行ＩＤを確定し、当該行ＩＤを元に生成した図９（ｂ）のテーブルのTable1_RowIDに関する検索条件を用いてDataRowIDを見つければよい。なお、図９（ｂ）のテーブルの第１列であるTable1_RowIDが図９（ａ）のテーブルの対応する行の行ＩＤを格納しており、このリンクを用いて図９（ａ）のテーブルと図９（ｂ）のテーブルとを結合（JOIN）すれば、図８に示したＬＳＨ近傍展開テーブルになる。
　また、図９（ａ）のテーブルと図９（ｂ）のテーブルのそれぞれを、連想配列を用いて実装してもよい。連想配列として実装する場合、図９（ａ）の連想配列のキーはHashValueとHammingDistanceを組み合わせたものであり、値は１つ以上の行ＩＤである。また、図９（ｂ）の連想配列のキーはTable1_RowIDであり、値は１つ以上のDataRowIDである。
　図１０は、ＬＳＨ近傍展開テーブルのHashValue列およびHammingDistance列に対するデータベース複合索引の一例を示す図である。このデータベース複合索引は、図１０に示すように、HashValueおよびHammingDistanceの値に沿って分岐する木構造となっており、葉に該当するＬＳＨ近傍展開テーブルの行ＩＤが記載されている。このデータベース複合索引を用いることで、検索時間を０（Ｎ）から０（ｌｏｇ（Ｎ））に短縮させることができる。
　なお、データベース複合索引の構成を少し変更することで、ＬＳＨ近傍展開テーブルを不要とすることもできる。具体的には、データベース複合索引の葉に、ＬＳＨ近傍展開テーブルの行ＩＤを格納する代わりにDataRowIDの値を格納する構成とする。これにより、DataRowIDしか検索できなくなるが、ＬＳＨ近傍展開テーブルをデータベース４００に保存しておく必要がなくなる。この場合、ＬＳＨ近傍展開索引情報４０Ｂはデータベース複合索引のみとなる。
　図１１は、ＬＳＨ近傍展開索引情報生成器２３０による処理手順の一例を示すフローチャートである。ＬＳＨ近傍展開索引情報生成器２３０は、索引構築命令タイプ分類器２１０から索引構築命令文３０を受け取ると、例えば以下のステップＳ４０１～ステップＳ４１０の処理を実行し、ＬＳＨ近傍展開テーブルとデータベース複合索引とを含むＬＳＨ近傍展開索引情報４０Ｂをデータベース４００に保存する。
　ステップＳ４０１：ＬＳＨ近傍展開索引情報生成器２３０は、データベース４００内に、名前：HashValue・型：blobの列と、名前：HammingDistance・型：integerの列と、名前：DataRowID・型：integerの列とを持つテーブル（空のＬＳＨ近傍展開テーブル）を生成する。なお、テーブル名の形式は「AAAA_BBBB_CCCC_DDDD」とする。ただし、AAAAは処理対象のデータテーブル２０のテーブル名、BBBBは処理対象の列の列名、CCCCはＬＳＨアルゴリズムのアルゴリズム名、DDDDはビット長とする。例えば、aTable_feat_PQ_3といったテーブル名が生成したテーブルに与えられる。
　ステップＳ４０２：ＬＳＨ近傍展開索引情報生成器２３０は、索引構築命令文３０で指定されたデータテーブル２０から、索引構築命令文３０で指定された列の特徴ベクトルを順に取り出す。
　ステップＳ４０３：ＬＳＨ近傍展開索引情報生成器２３０は、ステップＳ４０２で取り出した特徴ベクトル（事例ベクトル）に対して、索引構築命令文３０で指定されたＬＳＨアルゴリズムを用いて、索引構築命令文３０で指定されたビット長の事例ハッシュを生成する。
　ステップＳ４０４：ＬＳＨ近傍展開索引情報生成器２３０は、ステップＳ４０３で得られた事例ハッシュからの距離が指定距離以下の周辺ハッシュをすべて生成する。
　ステップＳ４０５：ＬＳＨ近傍展開索引情報生成器２３０は、ステップＳ４０４で得られた周辺ハッシュを順に取り出す。
　ステップＳ４０６：ＬＳＨ近傍展開索引情報生成器２３０は、ステップＳ４０５で取り出した周辺ハッシュ、この周辺ハッシュの事例ハッシュからのハミング距離、事例ハッシュの元になる事例ベクトルが属するデータテーブル２０内のレコードの行ＩＤの３つ組からなるレコードを、ＬＳＨ近傍展開テーブルに追加する。
　ステップＳ４０７：ＬＳＨ近傍展開索引情報生成器２３０は、ステップＳ４０４で得られた周辺ハッシュをすべて取り出したか否かを判定する。そして、判定の結果がＮｏであればステップＳ４０５に戻って以降の処理を繰り返し、ＹｅｓであればステップＳ４０８に進む。
　ステップＳ４０８：ＬＳＨ近傍展開索引情報生成器２３０は、処理対象のデータテーブル２０から特徴ベクトルをすべて取り出したか否かを判定する。そして、判定の結果がＮｏであればステップＳ４０２に戻って以降の処理を繰り返し、ＹｅｓであればステップＳ４０９に進む。
　ステップＳ４０９：ＬＳＨ近傍展開索引情報生成器２３０は、以上の処理を経て生成されたＬＳＨ近傍展開テーブルのHashValue列およびHammingDistance列に対するデータベース複合索引（コンポジットインデックス）を構築し、データベース４００に保存する。
　ステップＳ４１０：ＬＳＨ近傍展開索引情報生成器２３０は、事例ハッシュの生成に用いたＬＳＨアルゴリズムのモデルパラメタセットなどがあれば、テーブル名と同じファイル名（例えばaTable_feat_PQ_3）でデータベース４００に保存する。
　ここで、上記ステップＳ４０４における周辺ハッシュの生成方法の具体例について説明する。以下では、周辺ハッシュの起点となる事例ハッシュのビット列が“０１０”であるものとし、ハミング距離２以内の周辺ハッシュを列挙するという設定例で説明する。
　まず、ハミング距離０の周辺ハッシュは、事例ハッシュと同じハッシュである。すなわち、事例ハッシュのビット列が“０１０”であれば、この事例ハッシュに対してハミング距離０の周辺ハッシュは“０１０”のみである。
　次に、ハミング距離１の周辺ハッシュは、事例ハッシュの任意のビットを１つだけ反転させたものである。事例ハッシュのビット長が３であれば、反転させるビットの選択方法は、第１ビットのみ、第２ビットのみ、第３ビットのみの３種類である。事例ハッシュのビット列が“０１０”であれば、各選択方法でビット反転を行った結果は“１１０”、“０００”および“０１１”である。これら３つのハッシュが、事例ハッシュ“０１０”に対してハミング距離が１の周辺ハッシュである。
　次に、ハミング距離２の周辺ハッシュは、事例ハッシュの任意のビットを２つ反転させたものである。事例ハッシュのビット長が３であれば、反転させるビットの選択方法は、第１ビット＋第２ビット、第１ビット＋第３ビット、第２ビット＋第３ビットの３種類である。事例ハッシュのビット列が“０１０”であれば、各選択方法でビット反転を行った結果は“１００”、“１１１”および“００１”である。これら３つのハッシュが、事例ハッシュ“０１０”に対してハミング距離が２の周辺ハッシュである。
　以上をまとめると、事例ハッシュ“０１０”に対するハミング距離０の周辺ハッシュは“０１０”、ハミング距離１の周辺ハッシュは“１１０”、“０００”および“０１１”、ハミング距離２の周辺ハッシュは“１００”、“１１１”および“００１”である。このように、低コストな処理で周辺ハッシュをすべて生成することができる。
　なお、以上の方法により事例ハッシュに対する周辺ハッシュを生成する際、ビットの重要度などを元に、反転を許可するビットを制限する仕組みを備えてもよい。例えば、上記参考文献３のように主成分分析をベースとしたハッシュ生成法の場合、各ビットに対応する固有値から当該ビットの弁別性（重要度）を割り出すことができる。事例ハッシュにおける弁別性の高いビットを反転して生成した周辺ハッシュは、弁別性が失われた周辺ハッシュとなるため、このような周辺ハッシュをＬＳＨ近傍展開テーブルに追加してもヒットする確率が低いと考えられる。したがって、このような弁別性の高いビットは反転させないように制限を加えるようにしてもよい。このように、反転を許可するビットを制限することにより、ＬＳＨ近傍展開テーブルの記憶領域サイズを小さくすることができる。
　ＬＳＨ近傍展開テーブルは、検索キーとなる列と検索結果となる列が決まっているため、連想配列（キーバリューストア、C++標準ライブラリであればstd::mapやstd::unordered_mapなど）で簡潔に実装することができる。
　すなわち、検索結果はDataRowIDであるため、連想配列の値としてDataRowIDの可変長の連続メモリ配置型配列（C++標準ライブラリであればstd::vectorなど）を用いる。検索条件はHashValueとHammingDistanceのANDであるため、これら２つの値を用いてユニークになる連想配列のキーを生成する。図８に例示したＬＳＨ近傍展開テーブルの場合、HashValue列は二進数表記で“０００”～“１１１”の値を取り、HammingDistanceは“０”～“１”の値を取るので、キー値を以下の算出式で決定するなどが考えられる。
　キー値＝HashValue列の値×２＋HammingDistance列の値
　図１２は、連想配列と連続メモリ配置型配列を説明する図である。連想配列は、キーから値へ対応付ける方法として、図１２（ａ）に示すように、データベース索引のように木やハッシュなどのデータ構造を内部に持つ。上記のキーが定義域においてほぼ充当されているならば、連想配列の代わりに、図１２（ｂ）に示すような連続メモリ配置型配列（C++標準ライブラリであればstd::vectorなど）を用いてもよい。連続メモリ配置型配列として確保する要素数は、HashValueとHammingDistanceの全組合せ数とする。連続メモリ配置型配列を用いたデータ構造は、連想配列を用いたデータ構造と比べ、キーの充当率が高い場合に限りメモリ使用量が低減され、さらに処理速度が高速化される。
　次に、検索器３００の詳細を説明する。この検索器３００の機能概要および特徴は以下の通りである。この検索器３００では、拡張ＳＱＬ５０を用いて、ベクトル類似性に関する０個以上の条件を含む論理条件でのレコード検索ができる。これにより、データベース利用者は、一般的なデータ照合と特徴ベクトル類似性判定とを条件として結び付けた論理式での検索が行えるようになる。
　また、ベクトル類似性判定（ベクトル近傍検索）の処理は、検索対象のレコード数に応じて、５種類の方式を内部的に切り替えることができる。この切り替えは事前に設定されたシステム設定に基づいて行われる。５種類の方式には速度、精度、件数制御の有無について長短がある。これら５種類の方式の１つであるデータベース索引ＬＳＨ検索は、クエリに対して、検索時にベクトル距離計算を行わずデータベース索引のみを用いてベクトル類似性判定（ベクトル近傍検索）を実現する方式である。この方式は、検索時間を大幅に削減する効果を持つ。
　図１３は、検索器３００の構成例を示すブロック図である。検索器３００は、拡張ＳＱＬ５０を入力として受け取り、拡張ＳＱＬ５０に従った検索処理を実行して検索結果データセット６０を出力するものであり、図１３に示すように、検索条件処理部３１０と、検索出力部３２０とを備える。検索条件処理部３１０は、内部に様々な検索条件に対する処理を行う機能モジュールを持つ。このうち、特に本実施形態に特徴的なベクトル類似性に関する検索条件に対する処理を行う機能モジュールがベクトル類似性判定処理部３３０である。また、それ以外の検索条件に対する処理を行う機能モジュールを、他の検索条件処理部３４０と総称する。検索条件処理部３１０は、これらベクトル類似性判定処理部３３０の検索結果と他の検索条件処理部３４０との集合演算を行い、検索条件全体の処理を完成させる。検索出力部３２０は、検索条件処理部３１０の処理の結果に基づいてデータベース４００からレコードを取り出し、検索結果データセット６０として出力する。
　なお、検索器３００による検索処理の大半は従来のＳＱＬの検索処理と同様であり、検索条件処理部３１０がＳＱＬにおけるfrom命令部（データソースの特定処理）およびwhere命令部（検索条件処理）にあたり、検索出力部３２０がＳＱＬにおけるselect命令部にあたる。本実施形態における固有の処理は、検索条件処理部３１０の中の１つであるベクトル類似性判定処理部３３０が実行する処理である。このため、以下ではベクトル類似性判定処理部３３０を中心に説明し、従来技術をそのまま適用できる部分については適宜説明を省略する。
　まず、検索器３００が入力として受け取る拡張ＳＱＬ５０について説明する。拡張ＳＱＬ５０は、従来のＳＱＬに、ベクトル類似性に関する条件にあたるvnn関数を記述できるよう拡張した問合せ言語である。vnn関数は、以下の例のように、where命令内で一般的なＤＢ基本型データへの条件群と組合せ可能な項として用いる。
　select　*　from　aTable　where　vnn(feat_simhash_64,(10,20,30),10)　and　annualIncome　>　10000000
　vnn関数の仕様は以下の通りである。
　入力：vnn関数が検索対象とするデータセットを入力とする。この入力は、検索条件処理部３１０が内部的に生成してvnn関数を呼び出す際に渡す。通常の構文であれば、from命令で指定されたテーブルの全レコード群である。
　第１引数：第１引数は、事例ベクトル（検索対象とする特徴ベクトル）を格納する列名と、その列に適用されているＬＳＨアルゴリズムのアルゴリズム名と、その列に適用されているＬＳＨアルゴリズムの出力ビット長（後述の第３実施形態ではより一般化してオプションパラメタとしている）とをアンダースコアで結んだテキストである。
　第２引数：第２引数は、クエリベクトルである。
　第３引数：第３引数は、出力上位件数（出力対象とするベクトルの上位件数）である。ただし、クエリベクトルとの距離の小さいベクトルを上位とみなすものとする。
　出力：検索条件処理部３１０（from，whereなどの処理）に対して、引数で示された条件に合致する検索結果を返す。
　なお、ここでは出力条件にあたる第３引数として出力上位件数を与えるものとしているが、これに代えて距離上限を第３引数として与えるようにしてもよい。
　図１４は、ベクトル類似性判定部３３０の入出力関係を示す図である。ベクトル類似性判定部３３０は、図１４に示すように、検索対象データセット７０を入力として受け取り、vnn関数で表現された検索条件に基づくベクトル類似性判定（ベクトル近傍検索）処理を行って、検索結果８０を返す。本実施形態では、ベクトル類似性判定部３３０による検索方式として、厳密検索（Strict　Search）と、線形ＬＳＨ検索（Linear　LSH　Search）と、データベース索引ＬＳＨ検索（DB-Indexed　LSH　Search）と、データベース索引ＬＳＨ検索＋厳密検索と、データベース索引ＬＳＨ検索＋線形ＬＳＨ検索との５種類が用意されている。
　厳密検索は、元のクエリベクトルをそのまま用いて、クエリベクトルに類似する事例ベクトルを線形検索する検索方式である。線形ＬＳＨ検索は、ＬＳＨ即値索引情報４０Ａを用いて、クエリハッシュに完全一致する事例ハッシュに対応する事例ベクトルを線形検索する検索方式である。データベース索引ＬＳＨ検索は、ＬＳＨ近傍展開索引情報４０Ｂを用いて、クエリハッシュに完全一致する周辺ハッシュに対応する事例ベクトルを検索する検索方式である。データベース索引ＬＳＨ検索＋厳密検索は、データベース索引ＬＳＨ検索により件数を絞り込んだ後に厳密検索を行う２段階絞込方式の検索方式である。データベース索引ＬＳＨ検索＋線形ＬＳＨ検索は、データベース索引ＬＳＨ検索により件数を絞り込んだ後に線形ＬＳＨ検索を行う２段階絞込方式の検索方式である。これら５種類の方式による検索は、それぞれ、図１３に示した厳密検索器３３１、線形ＬＳＨ検索器３３２、データベース索引ＬＳＨ検索器３３３、データベース索引ＬＳＨ検索＋厳密検索器３３４およびデータベース索引ＬＳＨ検索＋線形ＬＳＨ検索器３３５により行われる。
　また、本実施形態では、ベクトル類似性判定処理部３３０が、事前に与えられた検索方式設定情報９０（図１３参照）に基づいて、上記の５種類の検索方式のいずれかを検索対象のレコード数に応じて選択するものとする。検索方式設定情報９０は、以下のような複数行からなる文法となっている。件数条件が上から照合され、マッチした検索方式が採用される。
　件数条件：検索方式
　件数条件：検索方式
・・・
　otherwise：検索方式
　件数条件には、“<=NNNN”（ただしNNNNは任意の正数）または“otherwise”を記述することができる。“<=NNNN”は検索対象となる事例ベクトルの数がNNNN件以下の場合にマッチする。“otherwise”はあらゆる件数にマッチする。“otherwise”は検索方式設定情報９０内に必ず１行含まれている必要がある。
　検索方式には、“Strict”（厳密検索）、“LinearLSH”（線形ＬＳＨ検索）、“DBIndexedLSH”（データベース索引ＬＳＨ検索）、“DBIndexedLSH:NNNN/Strict”（データベース索引ＬＳＨ検索＋厳密検索）および“DBIndexedLSH:NNNN/LinearLSH”（データベース索引ＬＳＨ検索＋線形ＬＳＨ検索）の５種類を記述することができる。NNNNには任意の正数を記述することができる。
　検索方式設定情報９０の記述例を以下に示す。以下に例示する検索方式設定情報９０は、検索対象となる事例ベクトルの数が１００００件以下なら厳密検索方式が採用され、１０００００件以下なら線形ＬＳＨ検索が採用され、それより多い件数ならデータベース索引ＬＳＨ検索＋線形ＬＳＨ検索方式が採用されることを示している。
　<=10000：Strict
　<=100000：LinearLSH
　Otherwise：DBIndexedLSH:100000/LinearLSH
　図１５は、ベクトル類似性判定部３３０による処理手順の一例を示すフローチャートである。ベクトル類似性判定部３３０は、検索対象データセット７０を入力として受け取ると、例えば以下のステップＳ５０１～ステップＳ５０７の処理を実行して、検索結果８０を出力する。
　ステップＳ５０１：ベクトル類似性判定部３３０は、入力された検索対象データセット７０のレコード件数（検索対象となる事例ベクトルの数）をカウントする。
　ステップＳ５０２：ベクトル類似性判定部３３０は、検索方式設定情報９０を参照し、件数条件がステップＳ５０１でカウントしたレコード件数とマッチする検索方式を取得する。取得した検索方式がStrictであればステップＳ５０３に進み、LinearLSHであればステップＳ５０４に進み、DBIndexedLSHであればステップＳ５０５に進み、DBIndexedLSH:NNNN/Strict（ただしNNNNは任意の正数）であればステップＳ５０６に進み、DBIndexedLSH:NNNN/LinearLSH（ただしNNNNは任意の正数）であればステップＳ５０７に進む。
　ステップＳ５０３：ベクトル類似性判定部３３０は、厳密検索器３３１を用いて検索結果８０を取得し、取得した検索結果８０を出力する。
　ステップＳ５０４：ベクトル類似性判定部３３０は、線形ＬＳＨ検索器３３２を用いて検索結果８０を取得し、取得した検索結果８０を出力する。
　ステップＳ５０５：ベクトル類似性判定部３３０は、データベース索引ＬＳＨ検索器３３３を用いて検索結果８０を取得し、取得した検索結果８０を出力する。
　ステップＳ５０６：ベクトル類似性判定部３３０は、データベース索引ＬＳＨ検索＋厳密検索器３３４を用いて検索結果８０を取得し、取得した検索結果８０を出力する。
　ステップＳ５０７：ベクトル類似性判定部３３０は、データベース索引ＬＳＨ検索＋線形ＬＳＨ検索器３３５を用いて検索結果８０を取得し、取得した検索結果８０を出力する。
　なお、以上の例では検索対象となる事例ベクトルの数に応じて検索方式を切り替えるようにしているが、切り替えるべき検索方式の指定として、ビット長など様々なパラメタ設定も含ませるといった拡張を行うようにしてもよい。例えば１６ビットなど短いビット長（すなわち１件当たりの処理時間は小さいが低精度）の線形ＬＨＳ検索で事例ベクトルの数を１０００００件に絞り込んだ後、４０９６ビットなど長いビット長（すなわち１件当たりの処理時間は大きいが高精度）の線形ＬＨＳ検索で順位付けするなどのプランを作ることができる。その場合の検索方式設定情報９０の記述例を以下に示す（@以降にパラメタ設定が列挙される）。
　<=100000：LinearLSH@4096
　otherwise：LinearLSH@16:100000/LinearLSH@4096
　以下では、それぞれの検索方式による検索処理の具体例を説明する。
　図１６は、厳密検索器３３１による処理手順の一例を示すフローチャートである。厳密検索器３３１は、例えば以下のステップＳ６０１～ステップＳ６０８の処理を実行して、検索結果８０を出力する。
　ステップＳ６０１：厳密検索器３３１は、空の検索結果リストを生成する。
　ステップＳ６０２：厳密検索器３３１は、vnn関数の第２引数として指定されたクエリベクトルを得る。
　ステップＳ６０３：厳密検索器３３１は、検索対象データセット７０からレコードを順に取り出す。
　ステップＳ６０４：厳密検索器３３１は、ステップＳ６０３で取り出したレコードにおいてvnn関数の第１引数として指定された事例ベクトルを格納する列に格納されている事例ベクトル群とクエリベクトルとのユークリッド距離を算出する。
　ステップＳ６０５：厳密検索器３３１は、ステップＳ６０３で取り出したレコードの行ＩＤとステップＳ６０４で算出したユークリッド距離との組を検索結果リストに追加する。ただし、検索結果リストの要素がユークリッド距離昇順で並ぶような位置に挿入する。
　ステップＳ６０６：厳密検索器３３１は、検索結果リストに含まれる要素数がvnn関数の第３引数として指定された出力上位件数よりも多い場合、出力上位件数以降の要素群を破棄する。
　ステップＳ６０７：厳密検索器３３１は、検索対象データセット７０からレコードをすべて取り出したか否かを判定する。そして、判定の結果がＮｏであればステップＳ６０３に戻って以降の処理を繰り返し、ＹｅｓであればステップＳ６０８に進む。
　ステップＳ６０８：厳密検索器３３１は、検索結果リストに含まれる行ＩＤの集合を検索結果８０として出力し、処理を終了する。
　図１７は、線形ＬＳＨ検索器３３２による処理手順の一例を示すフローチャートである。線形ＬＳＨ検索器３３２は、例えば以下のステップＳ７０１～ステップＳ７０９の処理を実行して、検索結果８０を出力する。
　ステップＳ７０１：線形ＬＳＨ検索器３３２は、空の検索結果リストを生成する。
　ステップＳ７０２：線形ＬＳＨ検索器３３２は、vnn関数の引数として指定されたクエリベクトル、ＬＳＨアルゴリズムのアルゴリズム名および出力ビット長を取得して、クエリベクトルのハッシュ（縮約クエリベクトル）を生成する。以下、これを「クエリハッシュ」と呼ぶ。
　ステップＳ７０３：線形ＬＳＨ検索器３３２は、検索対象データセット７０のテーブル名、vnn関数の引数として指定された事例ベクトルを格納する列、ＬＳＨアルゴリズムのアルゴリズム名および出力ビット長を取得して、これらを元に決定されるテーブル名を持つＬＳＨ即値テーブルを取得する。
　ステップＳ７０４：線形ＬＳＨ検索器３３２は、ステップＳ７０３で取得したＬＳＨ即値テーブルを用いて、検索対象データセット７０の各レコードに対応する事例ハッシュを順に取り出す。
　ステップＳ７０５：線形ＬＳＨ検索器３３２は、ステップＳ７０４で取り出した事例ハッシュとステップＳ７０２で生成したクエリハッシュとのハミング距離を算出する。
　ステップＳ７０６：線形ＬＳＨ検索器３３２は、ステップＳ７０４で取り出した事例ハッシュに対応する検索対象データセット７０のレコードの行ＩＤとステップＳ７０５で算出したハミング距離との組を検索結果リストに追加する。ただし、検索結果リストの要素がハミング距離昇順で並ぶような位置に挿入する。
　ステップＳ７０７：線形ＬＳＨ検索器３３２は、検索結果リストに含まれる要素数がvnn関数の第３引数として指定された出力上位件数よりも多い場合、出力上位件数以降の要素群を破棄する。
　ステップＳ７０８：線形ＬＳＨ検索器３３２は、検索対象データセット７０の各レコードに対応する事例ハッシュをすべて取り出したか否かを判定する。そして、判定の結果がＮｏであればステップＳ７０４に戻って以降の処理を繰り返し、ＹｅｓであればステップＳ７０９に進む。
　ステップＳ７０９：線形ＬＳＨ検索器３３２は、検索結果リストに含まれる行ＩＤの集合を検索結果８０として出力し、処理を終了する。
　なお、上記のステップＳ７０２において生成するクエリハッシュは本質的には二値ベクトルであるが、ＬＳＨ即値テーブルでの保存形式に合わせて、二進数と見立て整数として扱う。これにより、記憶領域を節約できるほか、整数同士の比較となるため照合処理が高速になる。
　図１８は、データベース索引ＬＳＨ検索器３３３による処理手順の一例を示すフローチャートである。データベース索引ＬＳＨ検索器３３３は、例えば以下のステップＳ８０１～ステップＳ８１０の処理を実行して、検索結果８０を出力する。
　ステップＳ８０１：データベース索引ＬＳＨ検索器３３３は、空の検索結果セットを生成する。
　ステップＳ８０２：データベース索引ＬＳＨ検索器３３３は、vnn関数の引数として指定されたクエリベクトル、ＬＳＨアルゴリズムのアルゴリズム名および出力ビット長を取得して、クエリハッシュを生成する。
　ステップＳ８０３：データベース索引ＬＳＨ検索器３３３は、検索対象データセット７０のテーブル名、vnn関数の引数として指定された事例ベクトルを格納する列、ＬＳＨアルゴリズムのアルゴリズム名および出力ビット長を取得して、これらを元に決定されるテーブル名を持つＬＳＨ近傍展開テーブルを取得する。
　ステップＳ８０４：データベース索引ＬＳＨ検索器３３３は、ハミング距離条件変数に０を割り当てる。
　ステップＳ８０５：データベース索引ＬＳＨ検索器３３３は、ステップＳ８０３で取得したＬＳＨ近傍展開テーブルに対して、HammingDistance列の値がハミング距離条件変数の現在値と一致し、かつ、HashValue列の値がステップＳ８０２で生成したクエリハッシュと一致するレコード群を検索し、得られた行ＩＤのセットを検索結果セットに追加する。
　ステップＳ８０６：データベース索引ＬＳＨ検索器３３３は、検索結果セットから重複要素を除去する。
　ステップＳ８０７：データベース索引ＬＳＨ検索器３３３は、検索結果セットの要素数がvnn関数の第３引数として指定された出力上位件数以上となっているか否かを判定する。そして、判定の結果がＮｏであればステップＳ８０８に進み、ＹｅｓであればステップＳ８１０に進む。
　ステップＳ８０８：データベース索引ＬＳＨ検索器３３３は、ハミング距離条件変数の値を１追加する。
　ステップＳ８０９：データベース索引ＬＳＨ検索器３３３は、ハミング距離条件変数の値がＬＳＨ近傍展開テーブルの距離上限以下か否かを判定する。そして、判定の結果がＹｅｓであればステップＳ８０５に戻って以降の処理を繰り返し、ＮｏであればステップＳ８１０に進む。
　ステップＳ８１０：データベース索引ＬＳＨ検索器３３３は、検索結果セットを検索結果８０として出力し、処理を終了する。
　なお、上記のステップＳ８０２において生成するクエリハッシュは本質的には二値ベクトルであるが、ＬＳＨ近傍展開テーブルでの保存形式に合わせて、二進数と見立て整数として扱う。これにより、記憶領域を節約できるほか、整数同士の比較となるため照合処理が高速になる。また、ＬＳＨ近傍展開テーブルの距離上限が１００などの大きな値の場合は、上記のステップＳ８０８での増分値を１０など大きめの値とし、ステップＳ８０５でのハミング距離条件に範囲を設けるようにしてもよい。こうすれば反復回数が減るため、検索処理全体を高速化できる。
　図１９は、データベース索引ＬＳＨ検索＋厳密検索器３３４による処理手順の一例を示すフローチャートである。データベース索引ＬＳＨ検索＋厳密検索は、データベース索引ＬＳＨ検索により検索を行った後、その結果について厳密検索による検索を行う２段階絞込方式である。データベース索引ＬＳＨ検索＋厳密検索器３３４は、例えば以下のステップＳ９０１～ステップＳ９０４の処理を実行して、検索結果８０を出力する。
　ステップＳ９０１：データベース索引ＬＳＨ検索＋厳密検索器３３４は、検索方式設定情報９０に記載された検索方式名「DBIndexedLSH:NNNN/Strict」のNNNN部を読み取る。これが、データベース索引ＬＨＳ検索における出力上位件数目標である。
　ステップＳ９０２：データベース索引ＬＳＨ検索＋厳密検索器３３４は、出力上位件数目標の設定でデータベース索引ＬＨＳ検索器３３３を呼び出し、検索結果セットを得る。
　ステップＳ９０３：データベース索引ＬＳＨ検索＋厳密検索器３３４は、データベース索引ＬＨＳ検索器３３３から取得した検索結果セットを検索対象データセット７０として厳密検索器３３１を呼び出し、検索結果リストを得る。
　ステップＳ９０４：データベース索引ＬＳＨ検索＋厳密検索器３３４は、厳密検索器３３１から取得した検索結果リストに含まれる行ＩＤの集合を検索結果８０として出力し、処理を終了する。
　図２０は、データベース索引ＬＳＨ検索＋線形ＬＳＨ検索器３３５による処理手順の一例を示すフローチャートである。データベース索引ＬＳＨ検索＋線形ＬＳＨ検索は、データベース索引ＬＳＨ検索により検索を行った後、その結果について線形ＬＳＨ検索による検索を行う２段階絞込方式である。データベース索引ＬＳＨ検索＋線形ＬＳＨ検索器３３５は、例えば以下のステップＳ１００１～ステップＳ１００４の処理を実行して、検索結果８０を出力する。
　ステップＳ１００１：データベース索引ＬＳＨ検索＋線形ＬＳＨ検索器３３５は、検索方式設定情報９０に記載された検索方式名「DBIndexedLSH:NNNN/Strict」のNNNN部を読み取る。これが、データベース索引ＬＨＳ検索における出力上位件数目標である。
　ステップＳ１００２：データベース索引ＬＳＨ検索＋線形ＬＳＨ検索器３３５は、出力上位件数目標の設定でデータベース索引ＬＨＳ検索器３３３を呼び出し、検索結果セットを得る。
　ステップＳ１００３：データベース索引ＬＳＨ検索＋線形ＬＳＨ検索器３３５は、データベース索引ＬＨＳ検索器３３３から取得した検索結果セットを検索対象データセット７０として線形ＬＳＨ検索器３３２を呼び出し、検索結果リストを得る。
　ステップＳ１００４：データベース索引ＬＳＨ検索＋線形ＬＳＨ検索器３３５は、線形ＬＳＨ検索器３３２から取得した検索結果リストに含まれる行ＩＤの集合を検索結果８０として出力し、処理を終了する。
　ここで、上述した５種類の検索方式の選択基準について説明する。データ件数をＮ、特徴ベクトルの次元数をＤとするとき、厳密検索、線形ＬＳＨ検索、データベース索引ＬＳＨ検索の３つ検索方式の計算コスト（積算相当回数）は以下となる。
　厳密検索：Ｎ×Ｄ
　線形ＬＳＨ検索：Ｎ（ＬＳＨアルゴリズムの出力ビット長を６４以下とした場合）
　データベース索引ＬＳＨ検索：α（データベース索引コスト）
　ここで、αはＮよりはるかに小さいため、上記３つの検索方式の中ではデータベース索引ＬＳＨ検索が最も低コストである。
　精度については、厳密検索が最も高く、次に線形ＬＳＨ検索が高く、データベース索引ＬＳＨ検索が最も低い。近似的手法であるＬＳＨを用いない厳密検索が最も高精度なのは当然だが、仮に同じＬＳＨアルゴリズムを用いていても、線形ＬＳＨ検索よりもデータベース索引ＬＳＨ検索のほうが精度が低くなる理由は、データベース索引ＬＳＨ検索では大きなビット長、ハミング距離を扱えないためである。データベース索引ＬＳＨ検索は、ハミング距離以下のすべてのハッシュをレコードとして展開するＬＳＨ近傍展開テーブルを内部参照する。ハミング距離をＨ、ビット長をＬとするとき、レコード数Ｓは下記式（１）で表される。
Figure JPOXMLDOC01-appb-M000001
　この式（１）から分かるように、大きなハミング距離、ビット長のＬＳＨを扱うと、レコード数が爆発するという問題がある。このため、小さなハミング距離、ビット長のＬＳＨを扱うことになるが、その場合、距離分解能が低下し、実際に出力する件数を要求された出力件数に正確に合わせることが困難となる。この問題は、線形ＬＳＨ検索、データベース索引ＬＳＨ検索など、ＬＳＨを用いるいずれの検索手法でも起こりえるが、特に小さなハミング距離、ビット長のＬＳＨしか扱えないデータベース索引ＬＳＨ検索において顕著である。この欠点を解決するには、データベース索引ＬＳＨ検索＋厳密検索や、データベース索引ＬＳＨ検索＋線形ＬＳＨ検索のように、出力件数を制御しやすい検索方式を２段階目に持つ２段階絞込方式を用いるようにし、１段階目のデータベース索引ＬＳＨ検索では多めの出力件数で出力し、２段階目の検索で出力件数を要求に正確に合わせるようにすることが有効である。
　以上のことから、検索速度を許容範囲内に収めつつなるべく高い精度を得るためには、検索対象データセット７０の件数が小規模の場合は厳密検索、検索対象データセット７０の件数が中規模の場合は線形ＬＳＨ検索、検索対象データセット７０の件数が大規模の場合は、データベース索引ＬＳＨ検索＋厳密検索、あるいはデータベース索引ＬＳＨ検索＋線形ＬＳＨ検索を用いることが有効である。
　以上、具体的な例を挙げながら詳細に説明したように、本実施形態のデータ管理システムでは、事前処理によってＬＳＨ近傍展開索引情報４０Ｂを含む索引情報４０を生成し、検索時にはこの索引情報４０を用いて、クエリベクトルに完全一致する周辺ベクトルに対応する事例ベクトルを特定するといった計算量の少ない方法でデータテーブル２０に対するベクトル近傍検索を行うようにしている。したがって、従来の類似検索において計算量の多くを占めていたベクトル近傍検索の計算量を削減して、データ検索の実行時間を短縮することができる。
＜第２実施形態＞
　次に、第２実施形態のデータ管理システムについて説明する。本実施形態は、検索時にクエリベクトルに対する距離が所定値以下の周辺ベクトルを生成し、周辺ベクトルと完全一致する事例ベクトルを見つける構成とすることで、メモリ使用量の削減およびそれに伴うＬＳＨの精度向上を実現したシステムである。
　上述した第１実施形態では、データベース索引ＬＳＨ検索を実現するために、内部でＬＳＨ近傍展開テーブルやデータベース複合索引を用いている。これらの構造データは、上述したように、ハッシュのビット長およびハミング距離上限が大きいとサイズが肥大化する。しかし、データベース４００の記憶領域として用いるディスクなどの記憶容量には限界があるため、大きなビット長およびハミング距離上限は扱えない場合がある。そして、十分に大きなビット長やハミング距離が扱えない場合、検索精度の低下を起こす可能性がある。
　本実施形態では、第１実施形態のように検索対象となる各事例ベクトルのハッシュ（二値ベクトル）である事例ハッシュの近傍にあるハッシュ（二値ベクトル）である周辺ハッシュ群を列挙する代わりに、クエリベクトルのハッシュ（二値ベクトル）の近傍にあるハッシュ（二値ベクトル）群を周辺ハッシュ群として列挙する方式を取る。この方式の場合、１つのベクトルに対して列挙したハッシュ群を記憶するだけでよいため、記憶容量の限界という問題は解消され、検索精度の低下を起こすリスクが回避される。ただし、第１実施形態と比較してクエリが複雑となるため、第１実施形態よりも検索速度は低下する。
　本実施形態のデータ管理システムにおける基本的な枠組みは第１実施形態と同様である。ただし、本実施形態では、検索時にＬＳＨ近傍展開索引情報４０Ｂを用いないため、索引構築器２００（図５参照）は、ＬＳＨ即値索引情報４０Ａを生成するＬＳＨ即値索引情報生成器２２０のみを備えた構成となる。また、検索時にクエリハッシュを起点とした周辺ハッシュを生成するため、検索器３００のベクトル類似性判定処理部３３０における検索方式が第１実施形態とは異なる。以下では、第１実施形態からの主な変更点となる本実施形態の検索方式について説明する。
　図２１は、本実施形態の検索器３００Ａの構成例を示すブロック図である。第１実施形態との違いは、ベクトル類似性判定処理部３３０Ａが、図１３に示したデータベース索引ＬＳＨ検索器３３３、データベース索引ＬＳＨ検索＋厳密検索器３３４およびデータベース索引ＬＳＨ検索＋線形ＬＳＨ検索器３３５に代えて、クエリ摂動型ＬＳＨ検索器３３６、クエリ摂動型ＬＳＨ検索＋厳密検索器３３７およびクエリ摂動型ＬＳＨ検索＋線形ＬＳＨ検索器３３８を備える点である。
　クエリ摂動型ＬＳＨ検索＋厳密検索器３３７およびクエリ摂動型ＬＳＨ検索＋線形ＬＳＨ検索器３３８については、２段階絞込方式の前段の検索方式がデータベース索引ＬＳＨ検索からクエリ摂動型ＬＳＨ検索に代わる他は第１実施形態のデータベース索引ＬＳＨ検索＋厳密検索器３３４およびデータベース索引ＬＳＨ検索＋線形ＬＳＨ検索器３３５と同様である。このため、以下では、クエリ摂動型ＬＳＨ検索＋厳密検索器３３７およびクエリ摂動型ＬＳＨ検索＋線形ＬＳＨ検索器３３８の説明は省略し、クエリ摂動型検索を行うクエリ摂動型ＬＳＨ検索器３３６についてのみ説明する。
　図２２は、クエリ摂動型ＬＳＨ検索器３３６による処理手順の一例を示すフローチャートである。クエリ摂動型ＬＳＨ検索器３３６は、例えば以下のステップＳ１１０１～ステップＳ１１１２の処理を実行して、検索結果８０を出力する。
　ステップＳ１１０１：クエリ摂動型ＬＳＨ検索器３３６は、空の検索結果セットを生成する。
　ステップＳ１１０２：クエリ摂動型ＬＳＨ検索器３３６は、vnn関数の引数として指定されたクエリベクトル、ＬＳＨアルゴリズムのアルゴリズム名および出力ビット長を取得して、クエリハッシュを生成する。
　ステップＳ１１０３：クエリ摂動型ＬＳＨ検索器３３６は、検索対象データセット７０のテーブル名、vnn関数の引数として指定された事例ベクトルを格納する列、ＬＳＨアルゴリズムのアルゴリズム名および出力ビット長を取得して、これらを元に決定されるテーブル名を持つＬＳＨ即値テーブルを取得する。
　ステップＳ１１０４：クエリ摂動型ＬＳＨ検索器３３６は、ハミング距離条件変数に０を割り当てる。
　ステップＳ１１０５：クエリ摂動型ＬＳＨ検索器３３６は、ステップＳ１１０２で生成したクエリハッシュからの距離がハミング距離条件変数の現在地と一致する周辺ハッシュをすべて生成する。
　ステップＳ１１０６：クエリ摂動型ＬＳＨ検索器３３６は、ステップＳ１１０５で生成した周辺ハッシュを順に取り出す。
　ステップＳ１１０７：クエリ摂動型ＬＳＨ検索器３３６は、ステップＳ１１０３で取得したＬＳＨ即値テーブルから、ステップＳ１１０６で取り出した周辺ハッシュと同じ値を持つレコード群をすべて取り出し、各レコードの行ＩＤを検索結果セットに追加する。
　ステップＳ１１０８：クエリ摂動型ＬＳＨ検索器３３６は、ステップＳ１１０５で生成した周辺ハッシュをすべて取り出したか否かを判定する。そして、判定の結果がＮｏであればステップＳ１１０６に戻って以降の処理を繰り返し、判定の結果がＹｅｓであればステップＳ１１０９に進む。
　ステップＳ１１０９：クエリ摂動型ＬＳＨ検索器３３６は、検索結果セットから重複要素を除去する。
　ステップＳ１１１０：クエリ摂動型ＬＳＨ検索器３３６は、検索結果セットの要素数がvnn関数の第３引数として指定された出力上位件数以上となっているか否かを判定する。そして、判定の結果がＮｏであればステップＳ１１１１に進み、ＹｅｓであればステップＳ１１１２に進む。
　ステップＳ１１１１：クエリ摂動型ＬＳＨ検索器３３６は、ハミング距離条件変数の値を１追加する。
　ステップＳ１１１２：クエリ摂動型ＬＳＨ検索器３３６は、検索結果セットを検索結果８０として出力し、処理を終了する。
　以上説明したように、本実施形態のデータ管理システムでは、クエリベクトルに類似する周辺ベクトルを生成し、この周辺ベクトルに完全一致する事例ベクトルを特定するといった計算量の少ない方法でデータテーブル２０に対するベクトル近傍検索を行うようにしている。したがって、第１実施形態と同様に、従来の類似検索において計算量の多くを占めていたベクトル近傍検索の計算量を削減して、データ検索の実行時間を短縮することができる。
　また、本実施形態では、第１実施形態と比較して記憶容量に対する制約が緩和されることで、比較的大きなビット長およびハミング距離上限を扱うことが可能になるため、ビット長およびハミング距離上限の制限に伴って検索精度の低下を起こすといったリスクが回避される。
＜第３実施形態＞
　次に、第３実施形態のデータ管理システムについて説明する。本実施形態は、ベクトルの写像に用いるＬＳＨの方式が第１実施形態とは異なる。すなわち、第１実施形態では写像処理にビットワイズＬＳＨを用いていたが、本実施形態では、写像処理に直積量子化ＬＳＨを用いる。
　直積量子化ＬＳＨは、与えられたベクトルを整数ベクトル（整数の要素からのみ構成される多値ベクトル）に変換する。この整数ベクトルに対して第１実施形態で示したような索引手法を導入することで、検索時におけるベクトル距離計算を排除することができる。なお、第１実施形態と同様に、取り扱う事例ベクトルおよびクエリベクトルが元々低次元の整数ベクトルであるならば、直積量子化ＬＳＨによる写像は不要であり、後述の事例ハッシュとして事例ベクトルをそのまま用い、クエリハッシュとしてクエリベクトルをそのまま用いればよい。また、この場合、後述の周辺ハッシュとして、事例ベクトルを元に生成される周辺ベクトルを用いればよい。
　直積量子化ＬＳＨの代表的なアルゴリズムは、下記の参考文献４に記載されている。直積量子化ＬＳＨとしては、この参考文献４に記載のアルゴリズムを含め、様々なアルゴリズムが提案されている。
　参考文献４：Herve　Jegou，Matthijs　Douze　and　Cordelia　Schmid，“Product　quantization　for　nearest　neighbor　search”，Pattern　Analysis　and　Machine　Intelligence，IEEE　Transactions　on　33.1（2011）：117-128．
　直積量子化ＬＳＨによるハッシュ生成の代表的な手順は以下の通りである。
（１）まず、与えられた事例ベクトル群が属する空間から、（好ましくは互いに排他的な）部分空間を複数取得する。
（２）各部分空間において、事例ベクトル群を予め定めた数のクラスタに分類する。
（３）各事例ベクトルについて、各部分空間のクラスタ番号を並べた整数ベクトルを生成する。これが写像後のベクトルである。
（４）各クラスタの分布などを用いて、写像後のベクトル間の差異から、写像前のベクトルの距離を近似的に算出するための距離モデルを生成する。
　上記の手順（４）で生成される距離モデルはアルゴリズムによって異なるが、いずれの距離モデルであっても、ハッシュである２つの整数ベクトルが与えられたときに、元のベクトル空間での距離を概算できる性質を持つ。また多くのアルゴリズムでは、クラスタ番号が隣接する場合、元のベクトル空間におけるクラスタの分布領域も近接している。次元数は変えず、元のベクトル空間において格子状に並んだ最近傍の点で代表させる格子ベクトル量子化は、最も単純な直積量子化ＬＳＨアルゴリズムである。
　本実施形態のデータ管理システムにおける基本的な枠組みは第１実施形態と同様である。本実施形態の第１実施形態からの変更点は、整数ベクトルをハッシュとして扱うこと、および、ベクトル間距離としてハミング距離を用いる代わりに直積量子化ＬＳＨが提供する距離モデルによって概算できる距離を用いるようにすることである。以下では、これらの変更点について説明する。
　図２３は、本実施形態の索引構築器２００Ｂの構成例を示すブロック図である。本実施形態の索引構築器２００Ｂは、図２３に示すように、第１実施形態の索引構築器２００におけるＬＳＨ即値索引情報生成器２２０（図５参照）に代えてＰＱＬＳＨ即値索引情報生成器２４０を備えるとともに、第１実施形態の索引構築器２００におけるＬＳＨ近傍展開索引情報生成器２３０（図５参照）に代えてＰＱＬＳＨ近傍展開索引情報生成器２５０を備える。
　ＰＱＬＳＨ即値索引情報生成器２４０は、索引構築命令タイプ分類器２１０から索引構築命令文３０を受け取った場合に、この索引構築命令文３０に従って、ＰＱＬＳＨ即値テーブルと、このＰＱＬＳＨ即値テーブルのHashValue列に対するデータベース索引とを含むＰＱＬＳＨ即値索引情報４０Ｃを生成する。ＰＱＬＳＨ即値索引情報生成器２４０が生成するＰＱＬＳＨ即値索引情報４０Ｃは、ＰＱＬＳＨ即値テーブルのHashValue列に格納される値が二値ベクトルではなく直積量子化ＬＳＨアルゴリズムを用いて生成された整数ベクトルとなる点を除き、第１実施形態で説明したＬＳＨ即値索引情報４０Ａと同様である。このため、ＰＱＬＳＨ即値索引情報生成器２４０については詳細な説明を省略する。
　ＰＱＬＳＨ近傍展開索引情報生成器２５０は、索引構築命令タイプ分類器２１０から索引構築命令文３０を受け取った場合に、この索引構築命令文３０に従って、ＰＱＬＳＨ近傍展開テーブルと、このＰＱＬＳＨ近傍展開テーブルのHashValue列およびDistance列に対するデータベース複合索引（コンポジットインデックス）とを含むＰＱＬＳＨ近傍展開索引情報４０Ｄを生成する。
　図２４は、ＰＱＬＳＨ近傍展開テーブルの一例を示す図である。ＰＱＬＳＨ近傍展開テーブルは、図２４に示すように、HashValue列（型：blob）、Distance列（型：real）およびDataRowID列（型：integer）からなるテーブルデータである。この図２４に示す例では、要素値｛0,1,2｝を取る長さ２の整数ベクトルのハッシュを用い、距離上限を１．０とした。Distance列の値は、直積量子化ＬＳＨアルゴリズムの提供する距離モデルによって概算される距離である。本例では、ハッシュの第１要素値が１変化すると距離が０．４、第２要素値が１変化すると距離が１．０変化するという距離モデルを用いるものとした。
　ＰＱＬＳＨ近傍展開索引情報生成器２５０は、索引構築命令文３０で指定されたデータテーブル２０から特徴ベクトルを取り出し、各特徴ベクトル（事例ベクトル）について、索引構築命令文３０で指定されたＬＳＨアルゴリズムおよび距離モデルを用いて整数ベクトルである事例ハッシュを生成する。次に、ＰＱＬＳＨ近傍展開索引情報生成器２５０は、生成した各事例ハッシュについて、索引構築命令文３０で指定された距離以下の周辺ハッシュ群を生成する。そして、ＰＱＬＳＨ近傍展開索引情報生成器２５０は、例えば、周辺ハッシュと、周辺ハッシュの事例ハッシュからの距離と、事例ハッシュの元になる事例ベクトルが属するデータテーブル２０のレコードの行ＩＤとの３つ組からなるレコードを、ＰＱＬＳＨ近傍展開テーブルに登録する。
　なお、ＰＱＬＳＨ近傍展開テーブルのHashValue列およびDistance列に対するデータベース複合索引は、図１０に示した第１実施形態のデータベース複合索引とほとんど同じであり、図１０のHammingDistanceの値に沿った分岐が、Distanceの値に沿った分岐に変わるだけである。
　図２５は、ＰＱＬＳＨ近傍展開索引情報生成器２５０による処理手順の一例を示すフローチャートである。ＰＱＬＳＨ近傍展開索引情報生成器２５０は、索引構築命令タイプ分類器２１０から索引構築命令文３０を受け取ると、例えば以下のステップＳ１２０１～ステップＳ１２１０の処理を実行し、ＰＱＬＳＨ近傍展開テーブルとデータベース複合索引とを含むＰＱＬＳＨ近傍展開索引情報４０Ｄをデータベース４００に保存する。
　ステップＳ１２０１：ＰＱＬＳＨ近傍展開索引情報生成器２５０は、データベース４００内に、名前：HashValue・型：blobの列と、名前：Distance・型：realの列と、名前：DataRowID・型：integerの列とを持つテーブル（空のＰＱＬＳＨ近傍展開テーブル）を生成する。なお、テーブル名の形式は「AAAA_BBBB_CCCC_DDDD」とする。ただし、AAAAは処理対象のデータテーブル２０のテーブル名、BBBBは処理対象の列の列名、CCCCは直積量子化ＬＳＨアルゴリズムのアルゴリズム名、DDDDはモデル（アルゴリズムに関する設定や分析結果）名とする。例えば、aTable_feat_PQ_confAといったテーブル名が生成したテーブルに与えられる。
　ステップＳ１２０２：ＰＱＬＳＨ近傍展開索引情報生成器２５０は、索引構築命令文３０で指定されたデータテーブル２０から、索引構築命令文３０で指定された列の特徴ベクトルを順に取り出す。
　ステップＳ１２０３：ＰＱＬＳＨ近傍展開索引情報生成器２５０は、ステップＳ１２０２で取り出した特徴ベクトル（事例ベクトル）に対して、索引構築命令文３０で指定された直積量子化ＬＳＨアルゴリズムおよびモデルを用いて、事例ハッシュを生成する。
　ステップＳ１２０４：ＰＱＬＳＨ近傍展開索引情報生成器２５０は、ステップＳ１２０３で得られた事例ハッシュからの距離が指定距離以下の周辺ハッシュをすべて生成する。ただし、起点となる事例ハッシュと各周辺ハッシュとの距離は、直積量子化ＬＳＨアルゴリズムのモデルを用いて概算する。
　ステップＳ１２０５：ＰＱＬＳＨ近傍展開索引情報生成器２５０は、ステップＳ１２０４で得られた周辺ハッシュを順に取り出す。
　ステップＳ１２０６：ＰＱＬＳＨ近傍展開索引情報生成器２５０は、ステップＳ１２０５で取り出した周辺ハッシュ、起点となった事例ハッシュからの距離、事例ハッシュの元になる事例ベクトルが属するデータテーブル２０内のレコードの行ＩＤの３つ組からなるレコードを、ＰＱＬＳＨ近傍展開テーブルに追加する。
　ステップＳ１２０７：ＰＱＬＳＨ近傍展開索引情報生成器２５０は、ステップＳ１２０４で得られた周辺ハッシュをすべて取り出したか否かを判定する。そして、判定の結果がＮｏであればステップＳ１２０５に戻って以降の処理を繰り返し、ＹｅｓであればステップＳ１２０８に進む。
　ステップＳ１２０８：ＰＱＬＳＨ近傍展開索引情報生成器２５０は、処理対象のデータテーブル２０から特徴ベクトルをすべて取り出したか否かを判定する。そして、判定の結果がＮｏであればステップＳ１２０２に戻って以降の処理を繰り返し、ＹｅｓであればステップＳ１２０９に進む。
　ステップＳ１２０９：ＰＱＬＳＨ近傍展開索引情報生成器２５０は、以上の処理を経て生成されたＰＱＬＳＨ近傍展開テーブルのHashValue列およびDistance列に対するデータベース複合索引（コンポジットインデックス）を構築し、データベース４００に保存する。
　ステップＳ１２１０：ＰＱＬＳＨ近傍展開索引情報生成器２５０は、事例ハッシュの生成に用いた直積量子化ＬＳＨアルゴリズムのモデルを、テーブル名と同じファイル名（例えばaTable_feat_PQ_confA）でデータベース４００に保存する。
　なお、上記のステップＳ１２０４で周辺ハッシュを生成する方法は第１実施形態と似た方法を用いるが、本実施形態では、ハッシュのどの要素を変更するかだけでなく、どれだけ値を変更するかも決定する必要がある。これには、例えばダイクストラ法などの最良優先探索などを用いればよい。
　図２６は、本実施形態の検索器３００Ｂの構成例を示すブロック図である。第１実施形態との違いは、ベクトル類似性判定処理部３３０Ｂが、図１３に示した線形ＬＳＨ検索器３３２、データベース索引ＬＳＨ検索器３３３、データベース索引ＬＳＨ検索＋厳密検索器３３４およびデータベース索引ＬＳＨ検索＋線形ＬＳＨ検索器３３５に代えて、線形ＰＱＬＳＨ検索器３５１、データベース索引ＰＱＬＳＨ検索器３５２、データベース索引ＰＱＬＳＨ検索＋厳密検索器３５３およびデータベース索引ＰＱＬＳＨ検索＋線形ＰＱＬＳＨ検索器３５４を備える点である。
　線形ＰＱＬＳＨ検索器３５１は、扱うベクトルが第１実施形態からの実装変更に伴って二値ベクトルから整数ベクトルに変わる他は、第１実施形態の線形ＬＳＨ検索器３３２と同様である。また、データベース索引ＰＱＬＳＨ検索＋厳密検索器３５３およびデータベース索引ＰＱＬＳＨ検索＋線形ＰＱＬＳＨ検索器３５４については、２段階絞込方式の前段の検索方式がデータベース索引ＬＳＨ検索からデータベース索引ＰＱＬＳＨ検索に代わる他は、第１実施形態のデータベース索引ＬＳＨ検索＋厳密検索器３３４およびデータベース索引ＬＳＨ検索＋線形ＬＳＨ検索器３３５と同様である。このため、以下では、線形ＰＱＬＳＨ検索器３５１、データベース索引ＰＱＬＳＨ検索＋厳密検索器３５３およびデータベース索引ＰＱＬＳＨ検索＋線形ＰＱＬＳＨ検索器３５４の説明は省略し、データベース索引ＰＱＬＳＨ検索を行うデータベース索引ＰＱＬＳＨ検索器３５２についてのみ説明する。なお、線形ＬＳＨ検索については、第１実施形態から変更せずにそのまま用いることも可能である。
　図２７は、データベース索引ＰＱＬＳＨ検索器３５２による処理手順の一例を示すフローチャートである。データベース索引ＰＱＬＳＨ検索器３５２は、例えば以下のステップＳ１３０１～ステップＳ１３１０の処理を実行して、検索結果８０を出力する。
　ステップＳ１３０１：データベース索引ＰＱＬＳＨ検索器３５２は、空の検索結果セットを生成する。
　ステップＳ１３０２：データベース索引ＰＱＬＳＨ検索器３５２は、vnn関数の引数として指定されたクエリベクトル、直積量子化ＬＳＨアルゴリズムのアルゴリズム名およびオプションパラメタを取得して、クエリハッシュを生成する。
　ステップＳ１３０３：データベース索引ＰＱＬＳＨ検索器３５２は、検索対象データセット７０のテーブル名、vnn関数の引数として指定された事例ベクトルを格納する列、直積量子化ＬＳＨアルゴリズムのアルゴリズム名およびオプションパラメタを取得して、これらを元に決定されるテーブル名を持つＰＱＬＳＨ近傍展開テーブルを取得する。
　ステップＳ１３０４：データベース索引ＰＱＬＳＨ検索器３５２は、距離条件変数に０を割り当てる。
　ステップＳ１３０５：データベース索引ＰＱＬＳＨ検索器３５２は、ステップＳ１３０３で取得したＰＱＬＳＨ近傍展開テーブルに対して、Distance列の値が距離条件変数の現在値以下であり、かつ、HashValue列の値がステップＳ１３０２で生成したクエリハッシュと一致するレコード群を検索し、得られた行ＩＤのセットを検索結果セットに追加する。
　ステップＳ１３０６：データベース索引ＰＱＬＳＨ検索器３５２は、検索結果セットから重複要素を除去する。
　ステップＳ１３０７：データベース索引ＰＱＬＳＨ検索器３５２は、検索結果セットの要素数がvnn関数の第３引数として指定された出力上位件数以上となっているか否かを判定する。そして、判定の結果がＮｏであればステップＳ１３０８に進み、ＹｅｓであればステップＳ１３１０に進む。
　ステップＳ１３０８：データベース索引ＰＱＬＳＨ検索器３５２は、距離条件変数を一定量追加する。
　ステップＳ１３０９：データベース索引ＰＱＬＳＨ検索器３５２は、ハミング距離条件変数の値がＰＱＬＳＨ近傍展開テーブルの距離上限以下か否かを判定する。そして、判定の結果がＹｅｓであればステップＳ１３０５に戻って以降の処理を繰り返し、ＮｏであればステップＳ１３１０に進む。
　ステップＳ１３１０：データベース索引ＰＱＬＳＨ検索器３５２は、検索結果セットを検索結果８０として出力し、処理を終了する。
　以上、具体的な例を挙げながら詳細に説明したように、本実施形態のデータ管理システムでは、事前処理によってＰＱＬＳＨ近傍展開索引情報４０Ｄを含む索引情報４０を生成し、検索時にはこの索引情報４０を用いて、クエリベクトルに完全一致する周辺ベクトルに対応する事例ベクトルを特定するといった計算量の少ない方法でデータテーブル２０に対するベクトル近傍検索を行うようにしている。したがって、第１実施形態と同様に、従来の類似検索において計算量の多くを占めていたベクトル近傍検索の計算量を削減して、データ検索の実行時間を短縮することができる。
＜補足説明＞
　上述した実施形態のデータ管理システムは、一例として、一般的なコンピュータとしてのハードウェアを用いた実行環境で動作するプログラムによる実装が可能である。この場合、本実施形態のデータ管理システムにおける上述の各機能的な構成要素（データ登録器１００、索引構築器２００（索引構築器２００Ｂ）、検索器３００（検索器３００Ａ、検索器３００Ｂ））は、ハードウェアとソフトウェア（プログラム）との協働により実現される。また、データベース４００は、プログラムによってアクセス可能な任意のメモリ資源によって実現される。
　図２８は、データ管理システムのハードウェア構成例を示すブロック図である。データ管理システムは、例えば図２８に示すように、ＣＰＵ（Central　Processing　Unit）１００１などのプロセッサ回路、ＲＯＭ（Read　Only　Memory）１００２やＲＡＭ（Random　Access　Memory）１００３などの記憶装置、表示パネルや各種操作デバイスが接続される入出力Ｉ／Ｆ１００４、ネットワークに接続して通信を行う通信Ｉ／Ｆ１００５、各部を接続するバス１００６などを備えた、通常のコンピュータを利用したハードウェア構成とすることができる。
　また、上述した構成のハードウェア上で実行されるプログラムは、例えば、インストール可能な形式または実行可能な形式のファイルでＣＤ－ＲＯＭ（Compact　Disk　Read　Only　Memory）、フレキシブルディスク（ＦＤ）、ＣＤ－Ｒ（Compact　Disk　Recordable）、ＤＶＤ（Digital　Versatile　Disc）などのコンピュータで読み取り可能な記録媒体に記録されてコンピュータプログラムプロダクトとして提供される。また、上述した構成のハードウェア上で実行されるプログラムを、インターネットなどのネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上述した構成のハードウェア上で実行されるプログラムをインターネットなどのネットワーク経由で提供または配布するように構成してもよい。また、上述した構成のハードウェア上で実行されるプログラムを、ＲＯＭ１００２などに予め組み込んで提供するように構成してもよい。
　上述した構成のハードウェア上で実行されるプログラムは、実施形態のデータ管理システムの各機能的な構成要素を含むモジュール構成となっており、例えば、ＣＰＵ１００１（プロセッサ回路）が上記記録媒体からプログラムを読み出して実行することにより、上述した各部がＲＡＭ１００３（主記憶）上にロードされ、ＲＡＭ１００３（主記憶）上に生成されるようになっている。なお、実施形態のデータ管理システムの各機能的な構成要素やデータベース４００は、複数のコンピュータに跨って実現される構成であってもよい。また、上述の機能的な構成要素の一部または全部を、ＡＳＩＣ（Application　Specific　Integrated　Circuit）やＦＰＧＡ（Field-Programmable　Gate　Array）などの専用のハードウェアを用いて実現することも可能である。
　以上、本発明の実施形態を説明したが、ここで説明した実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。ここで説明した新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。ここで説明した実施形態やその変形は、発明の範囲や要旨に含まれるとともに、請求の範囲に記載された発明とその均等の範囲に含まれる。

Claims (19)

  1. 　蓄積するデータの特徴ベクトルである事例ベクトルに類似する周辺ベクトルを生成し、生成した前記周辺ベクトルに対応する前記事例ベクトルを特定するための索引情報を構築する索引構築部と、
    　任意の特徴ベクトルであるクエリベクトルを指定した検索要求に応じて、前記索引情報を用いて、前記クエリベクトルと完全一致する前記周辺ベクトルに対応する前記事例ベクトルを特定し、特定した前記事例ベクトルに基づく検索結果を出力する検索部と、を備えるデータ管理システム。
  2. 　前記索引構築部は、少なくとも、前記周辺ベクトルを格納する第１列と、該周辺ベクトルに対応する前記事例ベクトルに関する情報を格納する第２列とを列要素に持つテーブルと、該テーブルにおける前記第１列に対する索引とを含む前記索引情報を構築し、
    　前記検索部は、前記索引を用いて、前記クエリベクトルと完全一致する前記周辺ベクトルに対応する前記テーブルのレコードを求め、求めたレコードの前記第２列に格納された情報に基づいて前記事例ベクトルを特定する、請求項１に記載のデータ管理システム。
  3. 　前記テーブルのデータ構造として、前記第１列に格納される前記周辺ベクトルをキーとし、前記第２列に格納される情報を値とする連想配列または連続メモリ配置型配列を用いる、請求項２に記載のデータ管理システム。
  4. 　前記索引構築部は、前記第１列および前記第２列に加えてさらに、前記周辺ベクトルの前記事例ベクトルに対する類似度を格納する第３列を列要素に持つ前記テーブルと、該テーブルにおける前記第１列および前記第３列に対する複合索引とを含む前記索引情報を構築し、
    　前記検索部は、前記複合索引を用いて、前記クエリベクトルと完全一致する前記周辺ベクトルであって、前記類似度が条件を満たす前記周辺ベクトルに対応する前記テーブルのレコードを求め、求めたレコードの前記第２列に格納された情報に基づいて前記事例ベクトルを特定する、請求項２に記載のデータ管理システム。
  5. 　前記テーブルのデータ構造として、前記第１列に格納される前記周辺ベクトルおよび前記第３列に格納される前記類似度をキーとし、前記第２列に格納される情報を値とする連想配列または連続メモリ配置型配列を用いる、請求項４に記載のデータ管理システム。
  6. 　前記索引構築部は、前記周辺ベクトルを格納する第１列と、該周辺ベクトルの前記事例ベクトルに対する類似度を格納する第２列とを列要素に持つ第１テーブルと、該第１テーブルのレコードの行ＩＤを格納する第１列と、該レコードの前記周辺ベクトルに対応する前記事例ベクトルに関する情報を格納する第２列とを列要素に持つ第２テーブルと、前記第１テーブルにおける前記第１列および前記第２列に対する複合索引とを含む前記索引情報を構築し、
    　前記検索部は、前記複合索引を用いて、前記クエリベクトルと完全一致する前記周辺ベクトルであって、前記類似度が条件を満たす前記周辺ベクトルに対応する前記第１テーブルのレコードの行ＩＤを求め、求めた行ＩＤが格納された前記第２テーブルのレコードの第２列に格納された情報に基づいて前記事例ベクトルを特定する、請求項１に記載のデータ管理システム。
  7. 　前記索引構築部は、前記クエリベクトルと完全一致する前記周辺ベクトルの値に従って、前記周辺ベクトルに対応する前記事例ベクトルに関する情報を探索する索引を前記索引情報として構築し、
    　前記検索部は、前記索引を用いて、前記クエリベクトルと完全一致する前記周辺ベクトルに対応する前記事例ベクトルを特定する、請求項１に記載のデータ管理システム。
  8. 　前記索引構築部は、前記クエリベクトルと完全一致する前記周辺ベクトルの値と該周辺ベクトルの前記事例ベクトルに対する類似度の条件とに従って、前記周辺ベクトルに対応する前記事例ベクトルに関する情報を探索する複合索引を前記索引情報として構築し、
    　前記検索部は、前記複合索引を用いて、前記クエリベクトルと完全一致する前記周辺ベクトルであって、前記類似度が条件を満たす前記周辺ベクトルに対応する前記事例ベクトルを特定する、請求項１に記載のデータ管理システム。
  9. 　前記検索部は、前記検索要求が出力件数の指定を含む場合に、前記事例ベクトルに対する前記周辺ベクトルの類似度の条件を厳しい方から段階的に変化させながら、前記クエリベクトルと完全一致する前記周辺ベクトルに対応する前記事例ベクトルを特定する処理を、特定した前記事例ベクトルの総数が指定された前記出力件数以上になるまで繰り返し、特定した前記事例ベクトルの総数が指定された前記出力件数以上になると前記処理を停止して、特定した前記事例ベクトルに基づく前記出力件数に近い件数の検索結果を出力する、請求項１乃至８のいずれか一項に記載のデータ管理システム。
  10. 　前記索引構築部は、前記事例ベクトルを縮約ベクトル空間に写像した縮約事例ベクトルに類似する縮約周辺ベクトルを生成し、生成した前記縮約周辺ベクトルに対応する前記事例ベクトルを特定するための前記索引情報を構築し、
    　前記検索部は、前記クエリベクトルを前記索引構築部と共通の縮約ベクトル空間に写像した縮約クエリベクトルと完全一致する前記縮約周辺ベクトルに対応する前記事例ベクトルを特定する、請求項１乃至９のいずれか一項に記載のデータ管理システム。
  11. 　前記事例ベクトルから前記縮約事例ベクトルへの写像、および、前記クエリベクトルから前記縮約クエリベクトルへの写像に、ＬＳＨ（Locality-Sensitive　Hashing）技術を用いる、請求項１０に記載のデータ管理システム。
  12. 　前記ＬＳＨ技術として、前記事例ベクトルを各次元が二値のみを取る二値ベクトルである前記縮約事例ベクトルに変換するとともに、前記クエリベクトルを各次元が二値のみを取る二値ベクトルである前記縮約クエリベクトルに変換するビットワイズＬＳＨを用いる、請求項１１に記載のデータ管理システム。
  13. 　前記索引構築部は、二値ベクトルである前記縮約周辺ベクトルを生成し、生成した前記縮約周辺ベクトルを二進数と見立てて整数として格納した前記索引情報を構築し、
    　前記検索部は、二値ベクトルである前記縮約クエリベクトルを、二進数と見立てて整数として用いて前記縮約クエリベクトルと完全一致する前記縮約周辺ベクトルに対応する前記事例ベクトルを特定する、請求項１２に記載のデータ管理システム。
  14. 　前記ＬＳＨ技術として、前記事例ベクトルを整数ベクトルである前記縮約事例ベクトルに変換するとともに、前記クエリベクトルを整数ベクトルである前記縮約クエリベクトルに変換する直積量子化ＬＳＨを用いる、請求項１１に記載のデータ管理システム。
  15. 　前記検索部は、前記索引情報を用いた検索方式と、元の特徴ベクトルまたは縮約ベクトル空間に写像された特徴ベクトルを用いて線形検索する検索方式と、を含む複数の検索方式のうち、前記データテーブルのレコード数に応じて選択された検索方式により前記事例ベクトルの検索を行う、請求項１乃至１４のいずれか一項に記載のデータ管理システム。
  16. 　前記検索部は、前記索引情報を用いた検索方式と、元の特徴ベクトルまたは縮約ベクトル空間に写像された特徴ベクトルを用いて線形検索する検索方式と、を含む複数の検索方式のうちの任意の検索方式を多段階で組み合わせて、前記事例ベクトルの検索を行う、請求項１乃至１５のいずれか一項に記載のデータ管理システム。
  17. 　蓄積するデータの特徴ベクトルである事例ベクトルを含むデータテーブルを保持する保持部と、
    　任意の特徴ベクトルであるクエリベクトルを指定した検索要求に応じて、前記クエリベクトルに類似する周辺ベクトルを生成し、生成した前記周辺ベクトルと完全一致する前記事例ベクトルを特定して、特定した前記事例ベクトルに基づく検索結果を出力する検索部と、を備えるデータ管理システム。
  18. 　データ管理システムにおいて実行されるデータ管理方法であって、
    　蓄積するデータの特徴ベクトルである事例ベクトルに類似する周辺ベクトルを生成し、生成した前記周辺ベクトルに対応する前記事例ベクトルを特定するための索引情報を構築するステップと、
    　任意の特徴ベクトルであるクエリベクトルを指定した検索要求に応じて、前記索引情報を用いて、前記クエリベクトルと完全一致する前記周辺ベクトルに対応する前記事例ベクトルを特定し、特定した前記事例ベクトルに基づく検索結果を出力するステップと、を含むデータ管理方法。
  19. 　コンピュータに、
    　蓄積するデータの特徴ベクトルである事例ベクトルに類似する周辺ベクトルを生成し、生成した前記周辺ベクトルに対応する前記事例ベクトルを特定するための索引情報を構築する機能と、
    　任意の特徴ベクトルであるクエリベクトルを指定した検索要求に応じて、前記索引情報を用いて、前記クエリベクトルと完全一致する前記周辺ベクトルに対応する前記事例ベクトルを特定し、特定した前記事例ベクトルに基づく検索結果を出力する機能と、を実現させるためのプログラム。
PCT/JP2015/080446 2015-10-28 2015-10-28 データ管理システム、データ管理方法およびプログラム WO2017072890A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2017547261A JP6434162B2 (ja) 2015-10-28 2015-10-28 データ管理システム、データ管理方法およびプログラム
CN201580083082.3A CN108027816B (zh) 2015-10-28 2015-10-28 数据管理系统、数据管理方法及记录介质
PCT/JP2015/080446 WO2017072890A1 (ja) 2015-10-28 2015-10-28 データ管理システム、データ管理方法およびプログラム
US15/927,124 US11281645B2 (en) 2015-10-28 2018-03-21 Data management system, data management method, and computer program product

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/080446 WO2017072890A1 (ja) 2015-10-28 2015-10-28 データ管理システム、データ管理方法およびプログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/927,124 Continuation US11281645B2 (en) 2015-10-28 2018-03-21 Data management system, data management method, and computer program product

Publications (1)

Publication Number Publication Date
WO2017072890A1 true WO2017072890A1 (ja) 2017-05-04

Family

ID=58629969

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/080446 WO2017072890A1 (ja) 2015-10-28 2015-10-28 データ管理システム、データ管理方法およびプログラム

Country Status (4)

Country Link
US (1) US11281645B2 (ja)
JP (1) JP6434162B2 (ja)
CN (1) CN108027816B (ja)
WO (1) WO2017072890A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019216137A1 (ja) * 2018-05-08 2019-11-14 日本電信電話株式会社 安全性評価装置、安全性評価方法、およびプログラム
CN109446436B (zh) * 2018-09-19 2020-07-03 西安电子科技大学 基于lsh的面向多维数据的安全范围查询方法及系统
US11604777B1 (en) * 2020-09-28 2023-03-14 Amazon Technologies, Inc. Indexing service for petabyte-scale datasets
US11810596B2 (en) * 2021-08-16 2023-11-07 Hong Kong Applied Science and Technology Research Institute Company Limited Apparatus and method for speech-emotion recognition with quantified emotional states

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013129580A1 (ja) * 2012-02-28 2013-09-06 公立大学法人大阪府立大学 近似最近傍探索装置、近似最近傍探索方法およびそのプログラム

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9622055D0 (en) * 1996-10-23 1996-12-18 Univ Strathclyde Vector quantisation
JP2000035965A (ja) 1998-07-17 2000-02-02 Nippon Telegr & Teleph Corp <Ntt> 類似特徴量の検索方法及び装置及び類似特徴量の検索プログラムを格納した記憶媒体
JP2001052024A (ja) 1999-08-13 2001-02-23 Nippon Telegr & Teleph Corp <Ntt> 類似特徴量の検索方法及び装置及び類似特徴量の検索プログラムを格納した記憶媒体
CN101631247B (zh) * 2002-04-18 2011-07-27 株式会社东芝 运动图像编码/解码方法和装置
JP4220449B2 (ja) * 2004-09-16 2009-02-04 株式会社東芝 インデキシング装置、インデキシング方法およびインデキシングプログラム
US8199973B2 (en) 2006-08-31 2012-06-12 Osaka Prefecture University Public Corporation Image recognition method, image recognition device, and image recognition program
CN101290619A (zh) * 2007-04-20 2008-10-22 西北民族大学 基于内容的藏文网站唐卡图像搜索引擎智能机器人搜索方法
CN101404032B (zh) * 2008-11-11 2011-09-28 清华大学 一种基于内容的视频检索方法及系统
CN101458695A (zh) * 2008-12-18 2009-06-17 西交利物浦大学 基于关键词和内容特征的混合图片索引构建和查询方法及其应用
CN101833511B (zh) * 2010-03-29 2012-06-06 瑞斯康达科技发展股份有限公司 数据管理方法、装置和系统
JP2013246522A (ja) * 2012-05-23 2013-12-09 Hitachi Ltd 構造化文書検索装置及びプログラム
US9141676B2 (en) * 2013-12-02 2015-09-22 Rakuten Usa, Inc. Systems and methods of modeling object networks
CN103839242A (zh) * 2014-01-15 2014-06-04 中国科学院电子学研究所 一种基于高维索引的图像快速超分辨率增强方法
US9734176B2 (en) * 2014-06-12 2017-08-15 International Business Machines Corporation Index merge ordering

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013129580A1 (ja) * 2012-02-28 2013-09-06 公立大学法人大阪府立大学 近似最近傍探索装置、近似最近傍探索方法およびそのプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BABENKO, ARTEM ET AL.: "The Inverted Multi-Index", 2012 IEEE CONFERENCE ON COMPUTER VISION AND PATTERN RECOGNITION, 21 June 2012 (2012-06-21), pages 3069 - 3076, XP032232437 *

Also Published As

Publication number Publication date
US11281645B2 (en) 2022-03-22
CN108027816B (zh) 2021-10-26
CN108027816A (zh) 2018-05-11
JPWO2017072890A1 (ja) 2018-05-17
US20180210907A1 (en) 2018-07-26
JP6434162B2 (ja) 2018-12-05

Similar Documents

Publication Publication Date Title
US11354365B1 (en) Using aggregate compatibility indices to identify query results for queries having qualitative search terms
US20180276250A1 (en) Distributed Image Search
CN107391554B (zh) 高效分布式局部敏感哈希方法
WO2013129580A1 (ja) 近似最近傍探索装置、近似最近傍探索方法およびそのプログラム
US11748351B2 (en) Class specific query processing
JP6434162B2 (ja) データ管理システム、データ管理方法およびプログラム
JP5355483B2 (ja) 略語完全語復元装置とその方法と、プログラム
JP2013242675A (ja) 分散情報制御装置、分散情報検索方法、データ分散配置方法、及びプログラム
Markonis et al. The parallel distributed image search engine (paradise)
JP2000035965A (ja) 類似特徴量の検索方法及び装置及び類似特徴量の検索プログラムを格納した記憶媒体
KR102062139B1 (ko) 지능형 자료구조 기반의 데이터 처리 방법 및 그를 위한 장치
CN110019096A (zh) 索引文件的生成方法及装置
KR101592670B1 (ko) 인덱스를 이용하는 데이터 검색 장치 및 이를 이용하는 방법
Papadakis et al. A hyper-box approach using relational databases for large scale machine learning
JP6065001B2 (ja) データ検索装置、データ検索方法およびデータ検索用プログラム
JP2019159362A (ja) 探索プログラムおよび探索方法
JP2001052024A (ja) 類似特徴量の検索方法及び装置及び類似特徴量の検索プログラムを格納した記憶媒体
WO2014061305A1 (ja) エントリ挿入装置、方法、及びプログラム
Siedlaczek Efficiency and Scalability of Large Search Architectures
JP6631139B2 (ja) 検索制御プログラム、検索制御方法および検索サーバ装置
Yalamanchili et al. Performance enhanced multiset similarity joins
Kalandar Mohideen A Graph-Based Indexing Technique for Efficient Searching in Large Scale Textual Documents
JP2020038610A (ja) 検索処理プログラム、検索処理方法及び情報処理装置
JP5575074B2 (ja) 文書分類装置及び方法及びプログラム及びコンピュータ読取可能な記録媒体

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017547261

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15907254

Country of ref document: EP

Kind code of ref document: A1