Search device, search method, and program

Abstract

To provide a search device, search method, and program for efficiently searching for a character string.SOLUTION: A search device 100 includes a database 110 that stores variable-length registered character strings 112 and a data tree 111 composed of a plurality of nodes 200. A node 200 includes a serial character string indicating at least a partial character string of the registered character strings 112, and branch information related to a transition destination below the node 200. The search device 100 includes a search unit 130 configured to search for a registered character string 112 including a search character string based on the serial character string and the branch information on the node 200. When there is a registered character string 112 with a terminating end matching the terminating end of the character string indicated by the serial character string, the serial character string holds an entity of the registered character string 112. When there is no registered character string 112 with a terminating end matching the terminating end of the character string indicated by the serial character string, the serial character string shares reference to the registered character string 112 at the transition destination indicated by the branch information on the node 200.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a search device, a search method, and a program. [Background technology]

[0002] With the recent development and global spread of IT (Information Technology), computer data processing has become the most important factor that determines a company's competitiveness. In particular, with the promotion of IoT (Internet of Things) and the spread of 5G, the amount of data generated worldwide is expected to increase explosively. For this reason, a dramatic improvement in data processing technology is desired.

[0003] Known data processing technologies, for example, technologies related to data search, include Patent Document 1 and Non-Patent Documents 1 to 4. Patent Document 1 describes an information search method using a Patricia-Tree. Non-Patent Document 1 describes an efficient index creation method using a Trie (Prefix-Tree). Non-Patent Document 2 describes a large-scale data search method using a VAST tree with SIMD instructions (Single Instruction / Multiple Data). Non-Patent Document 3 describes a method for optimizing the height of a Trie. Non-Patent Document 4 describes a method for speeding up processing of a tree-based index structure using SIMD instructions. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2001-357070 [Non-patent literature]

[0005] [Non-Patent Document 1] Matthias Boehm, Benjamin Schlegel, Peter Benjamin Volk, Ulrike Fischer, Dirk Habich, Wolfgang Lehner, "Efficient In-Memory Indexing with Generalized Prefix Trees", Datenbanksysteme fur Business, Technologie und Web (BTW), pp. 227-246, March 2011, [Retrieved December 18, 2023], Internet<URL:https: / / dl.gi.de / bitstreams / 4acd192a-e10b-4fa5-bb29-af8907b0a1ae / download> [Non-patent document 2] Ken Yamamuro, Makoto Onitsuka, Azuma Hidaka, Masashi Yamamuro, "VAST Tree: Accelerating Large-Scale Data Searches with SIMD Instructions Using Tree-Structured Index Compression," IPSJ Transactions on Database, Vol. 8, No. 2, pp. 30-42, June 2015, [Retrieved December 18, 2023], Internet<URL:https: / / db-event.jpn.org / deim2011 / proceedings / pdf / e2-1.pdf> [Non-patent document 3] Robert Binna, Eva Zangerle, Martin Pichl, Gunther Specht, Viktor Leis, "HOT: A Height Optimized Trie Index for Main-Memory Database Systems", SIGMOD '18: Proceedings of the 2018 International Conference on Management of Data, May 2018, pp. 521-534, [Retrieved December 18, 2023], Internet<URL:https: / / 15721.courses.cs.cmu.edu / spring2020 / papers / 07-oltpindexes2 / p521-binna.pdf> [Non-patent document 4] Steffen Zeuch, Frank Huber, Johann-Christoph Freytag, "Adapting Tree Structures for Processing with SIMD Instructions", 17th International Conference on Extending Database Technology (EDBT), pp.97-108, March 2014, [Retrieved December 18, 2023], Internet<URL:https: / / openproceedings.org / 2014 / conf / edbt / ZeuchFH14.pdf> Summary of the Invention [Problem to be solved by the invention]

[0006] However, the above-mentioned related techniques do not take into consideration searching for variable-length character strings, and therefore may not be able to perform searches efficiently.

[0007] The present invention has been made in view of the above circumstances, and has an object to provide a search device, a search method, and a program that are capable of efficiently searching for character strings. [Means for solving the problem]

[0008] A search device according to the present invention comprises: a storage unit that stores variable-length registered character strings and a data tree made up of a plurality of nodes, each of which includes serialized character string information indicating at least a portion of the registered character strings and branch information related to a lower-level transition destination of the node; and a search unit that searches for registered character strings that include a search string based on the serialized character string information and the branch information of the node, wherein the serialized character string information holds the entity of the registered character string if there is a registered character string whose end-points match the string indicated by the serialized character string information; and when there is no registered character string whose end-points match the string indicated by the serial character string information, the serialized character string information shares reference with the registered character string of the transition destination indicated by the branch information of the node.

[0009] A search method according to the present invention stores variable-length registered character strings and a data tree made up of a plurality of nodes, each of which includes serialized character string information indicating at least a portion of the registered character strings and branch information related to a transition destination below the node, and searches for registered character strings that include a search string based on the serialized character string information and the branch information of the node, and if a registered character string exists whose ends match the string indicated by the serialized character string information, the serialized character string information holds the entity of the registered character string, and if no registered character string exists whose ends match the string indicated by the serial character string information, the serialized character string information shares reference with the registered character string at the transition destination indicated by the branch information of the node.

[0010] A program according to the present invention is a program for causing a computer to execute a process that stores variable-length registered character strings and a data tree composed of a plurality of nodes, each of which includes serialized character string information indicating at least a portion of the registered character strings and branch information related to a transition destination below the node, and searches for registered character strings that include a search string based on the serialized character string information and the branch information of the node, and if a registered character string exists whose end points match the string indicated by the serialized character string information, the serialized character string information holds the entity of the registered character string, and if no registered character string exists whose end points match the string indicated by the serial character string information, the serialized character string information makes shared reference to the registered character string at the transition destination indicated by the branch information of the node. [Effects of the Invention]

[0011] According to the present invention, it is possible to provide a search device, a search method, and a program that are capable of efficiently searching for character strings. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 2 is a diagram illustrating an example of the configuration of a data tree according to the first embodiment. [Figure 2] FIG. 2 is a diagram showing a specific example of a data tree according to the first embodiment. [Figure 3] FIG. 1 is a configuration diagram showing a search device according to a first embodiment. [Figure 4A] 10 is a flowchart showing an example of operation of an exact match search process according to the first embodiment. [Figure 4B] 10 is a flowchart showing an example of operation of an exact match search process according to the first embodiment. [Figure 5] FIG. 10 is a diagram for explaining a specific example of the exact match search process according to the first embodiment. [Figure 6A] 10 is a flowchart showing an example of the operation of a serialized character string comparison process according to the first embodiment. [Figure 6B] 10 is a flowchart showing an example of the operation of a serialized character string comparison process according to the first embodiment. [Figure 7] 10 is a flowchart showing an example of operation of a branch byte string comparison process according to the first embodiment. [Figure 8] FIG. 10 is a diagram illustrating an example of operation of a difference position index acquisition process according to the first embodiment. [Figure 9] FIG. 10 is a diagram illustrating an example of operation of a match position index acquisition process according to the first embodiment. [Figure 10A] FIG. 10 is a diagram illustrating an example of the operation of a search section index acquisition process according to the first embodiment. [Figure 10B] FIG. 10 is a diagram illustrating an example of the operation of a search section index acquisition process according to the first embodiment. [Figure 11] FIG. 10 is a diagram illustrating an example of the operation of a byte most significant bit aggregation process according to the first embodiment. [Figure 12] FIG. 3 is a diagram illustrating an example of a memory arrangement of node data according to the first embodiment. [Figure 13A] 10 is a flowchart showing an example of operation of prefix match search processing according to the second embodiment. [Figure 13B] 10 is a flowchart showing an example of operation of prefix match search processing according to the second embodiment. [Figure 14] FIG. 10 is a diagram illustrating a specific example of prefix match search processing according to the second embodiment. [Figure 15A] 10 is a flowchart showing an example of operation of a repetitive acquisition process according to the second embodiment. [Figure 15B] 10 is a flowchart showing an example of operation of a repetitive acquisition process according to the second embodiment. [Figure 16] FIG. 10 is a diagram for explaining a specific example of the iterative acquisition process according to the second embodiment. [Figure 17] FIG. 10 is a configuration diagram showing a search device according to a third embodiment. [Figure 18A] 11 is a flowchart showing an operation example of a registration process according to the third embodiment. [Figure 18B] 11 is a flowchart showing an operation example of a registration process according to the third embodiment. [Figure 19] FIG. 11 is a diagram for explaining a specific example of the registration process according to the third embodiment. [Figure 20] FIG. 11 is a diagram for explaining a specific example of the registration process according to the third embodiment. [Figure 21] FIG. 11 is a diagram for explaining a specific example of the registration process according to the third embodiment. [Figure 22] FIG. 11 is a diagram for explaining a specific example of the registration process according to the third embodiment. [Figure 23] FIG. 11 is a diagram for explaining a specific example of the registration process according to the third embodiment. [Figure 24] FIG. 11 is a diagram for explaining a specific example of the registration process according to the third embodiment. [Figure 25] FIG. 11 is a diagram for explaining a specific example of the registration process according to the third embodiment. [Figure 26] FIG. 13 is a diagram showing a table of example data conversion rules according to the fourth embodiment. [Figure 27] FIG. 13 is a diagram showing a comparison result of unsigned integer values ​​according to the fourth embodiment. [Figure 28] FIG. 13 is a diagram showing a comparison result of signed integer values ​​according to the fourth embodiment. [Figure 29] FIG. 13 is a diagram illustrating an example of a format of a floating-point value according to the fourth embodiment. [Figure 30] 13A and 13B are diagrams illustrating examples of data in two endian formats according to the fourth embodiment. [Figure 31] FIG. 13 is a diagram showing an example of the configuration of a multi-key according to the fifth embodiment. [Figure 32] FIG. 10 is a diagram for explaining the number of comparisons for a general multi-key. [Figure 33] FIG. 13 is a diagram for explaining the number of times multi-key comparisons are made in the fifth embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, embodiments of the present invention will be described with reference to the drawings. However, the present invention is not limited to the following embodiments. Furthermore, for clarity of explanation, the following description and drawings have been omitted and simplified as appropriate. In each drawing, the same elements are given the same reference numerals, and duplicate explanations are omitted as necessary.

[0014] (Review of related technologies) To aid in understanding the embodiments, data processing in a computer will be described. There are various types of data that can be handled in a computer, but the basic data is a string of characters that concatenates numeric data such as fixed-point (Int) or floating-point (Float) and character codes. Data such as images and audio can be considered a hybrid of these two types, and can be thought of as a numeric string of concatenated numeric data.

[0015] Among these, the size of numeric data is comprised of fixed sizes such as 8 bits, 16 bits, 32 bits, and 64 bits. Meanwhile, the processing size of modern computers is increasingly moving towards 64 bits. For this reason, numeric data that is 64 bits (8 bytes) or less can be processed using the instructions (Instruction Set) of the CPU (Central Processing Unit), and logical operations (And, Or, Not, etc.) and arithmetic operations (Add, Sub, Mul, Div, etc.) can be completed for a single piece of data with a single instruction. For this reason, numeric data can be said to be a data format that is easy for computers to handle.

[0016] In contrast, character strings, such as names, company names, product names, addresses, and descriptions, can range from as little as one byte to as many as several thousand bytes, and these pieces of data of different lengths must be handled as a single string of data. As character strings are variable in size and often exceed 64 bits (8 bytes), their manipulation cannot be completed with a single instruction by the CPU, but rather requires a combination of multiple instructions depending on the length and size. For this reason, character string data can be said to be a data format that requires more effort to process than numeric data.

[0017] However, because strings are made up of combinations of characters that humans can directly recognize and can be freely constructed by linking alphabets, numbers, and even kanji and hiragana characters, they are used more widely than numeric data to represent a variety of data, such as product codes, various classification codes, product names, and address notations. As mentioned above, strings are used for data with a variety of meanings, and their range of applications is broad. Therefore, in database systems, they are treated as one of the most basic data types (often commonly referred to as VarChar).

[0018] When dealing with character strings on a computer system, basic operations require the ability to register, delete, and search for character string data. Unlike single data such as numerical data, character strings are a series of data made up of multiple characters connected together and are treated as a single piece of data. For this reason, there are several types of searches for character strings, which can be broadly divided into five types: exact match search, prefix search, range search (larger / smaller search), suffix search, and infix search.

[0019] As the name suggests, an exact match search searches for an exact match between the search key and the target data. A prefix match search searches for a match between the beginning of the target data and the search key. In this case, anything after the search key in the target string is acceptable.

[0020] Range search (size search) searches for matches within a range when strings are sorted in dictionary order by specifying the start and end positions of the string. The start and end positions can be searched using either an exact match or a prefix match. Also, the search key can be specified as either the start or end position.

[0021] A suffix search is the opposite of a prefix search, and searches for a string that matches the search key at the end of the target data. In this case, the part of the target string before the search key can be anything. An intermediate match search searches for a string that matches the search key anywhere in the target data.

[0022] The inventors have studied technologies related to data search in order to efficiently search for character strings. Due to the recent trend toward Big Data, the amount of data handled by computers has become extremely large. However, simply storing data in the order in which it was entered and sequentially checking the stored data from the beginning results in a significant amount of time and cost required for searching data. For this reason, various techniques for efficiently handling large amounts of data have been proposed. In particular, "technology for registering large amounts of data in a computer and quickly searching for specific data from within that data" is an important function for handling data, and various processing methods have been proposed as related technologies, such as Patent Document 1 and Non-Patent Documents 1 to 4.

[0023] Patricia-Tree is a type of widely known binary tree search, and is described, for example, in Patent Document 1. When searching for data using Patricia-Tree, transitions are made from the top of the tree to nodes corresponding to 0 and 1 in the binary tree depending on whether the bit at the comparison position is 0 or 1, and when a leaf is finally reached, a comparison is made between the search key and the search data. This effectively limits the comparison of the entire search key to just one time, enabling efficient searches.

[0024] Meanwhile, Trie is also a widely known tree structure. Trie is the original concept behind Patricia-Tree, and various processing methods based on Trie have been proposed. Non-Patent Document 1, 4.1, discloses a method called "Bypass Jumper Array," which reduces the number of tree transitions by starting the search position of Trie from the middle according to the length of the leading zero part. Non-Patent Document 2 also discloses a method using a tree structure called VAST (Vector Advanced Structure), which performs lossy compression on target data in the tree. Non-Patent Document 3 also discloses a processing method that can improve search efficiency by optimizing the tree height by varying the length of the bits (span bits) used for key branching, thereby ensuring the number of branches in the Trie tree and reducing the tree height. Furthermore, Non-Patent Document 4 also discloses a processing method using Seg-Tree, which is based on B-Tree, and Seg-Trie, which is based on Trie, as an efficiency improvement method using SIMD instructions.

[0025] These related technologies can operate efficiently on small-sized numeric data by utilizing bit-wise or byte-wise transitions in any processing method. However, they may not be able to efficiently process searches for large data such as character strings, which have large data lengths ranging from 1 to 1000 bytes or more and involve large changes in size.

[0026] Therefore, in the embodiment, an efficient search process for variable-length character strings including binary data is enabled.

[0027] (Outline of the embodiment) Next, an outline of an embodiment will be described. In the embodiment, a search device is provided that performs an exact match search, a prefix match search, or a range search for variable-length character strings, for example.

[0028] The search device uses a multi-node tree structure to register and search for variable-length character strings. Nodes that make up the multi-node tree structure store a set of serial character strings that are partial matches for a variable-length character string, a set of branches containing the next byte that follow, and transition destination information in the event of a match. For example, if a registered character string with a matching end exists, the serial character string of a node may retain the actual string; if not, it may share and reference one of the registered character strings below the node. This allows variable-length character strings to be appropriately stored in or referenced from nodes, enabling efficient character string searches.

[0029] Furthermore, in a node of the multi-node tree structure, if the serial character string portion matches part of the search character string and the next byte matches one of the branches, the search device may repeat the transition to the next node corresponding to the branch.

[0030] In addition, when comparing a serial string of a node with a part of a search string, the search device can use SIMD instructions for parts where the number of bytes to be compared is equal to or greater than the SIMD size (256 bits, 128 bits), and use a combination of general instructions according to the size (64 bits, 32 bits, 16 bits, 8 bits) for parts less than the SIMD size, thereby making it possible to determine whether a long string is identical with a small number of comparisons.

[0031] Furthermore, the search device may perform the detection of the position of an equivalent branch that matches a character in the search string from the set of branches of the node by a calculation process including parallel comparison using SIMD instructions and bit manipulation of the result, without using loops or conditional branches that disrupt the CPU's pipeline processing. Furthermore, if the number of branches is greater than the number of bytes that can be processed by a single SIMD operation, the detection may be performed by dividing the process into range identification using SIMD and equivalence detection using SIMD within the identified range, thereby performing equivalence detection for more branches than the number of bytes that can be processed by a single SIMD operation. In this case, for the first range identification using SIMD, the node may have a super index that extracts branches at positions that are multiples of the number of SIMD bytes from the branches.

[0032] Furthermore, in the data structure of a node, by storing transition destination information corresponding to the branches after a set of branches in the node (for example, a byte sequence of 1 to 256), it is possible to prevent memory reference violations when the number of branches is less than the basic SIMD size of 128 bits or 256 bits, reduce memory capacity, and increase the probability of a cache hit for the next transition destination information to be accessed.

[0033] Furthermore, when registering and storing data including variable-length character strings, the search device may store data converted according to specific conversion rules. For example, the data may be converted and stored so that signed / unsigned fixed-point numbers (8 bits, 16 bits, 32 bits, 64 bits) and floating-point numbers (32 bits, 64 bits) can be processed using the same logic as character strings. Furthermore, the search device may process composite keys that combine character strings, fixed-point numbers, and floating-point numbers in any order, including data converted in this way, using the same logic as character strings, without regard for key boundaries.

[0034] For example, a numeric value can be as large as 64 bits, and even when expanded into Seg-Trie as shown in Non-Patent Document 4, it only becomes 8 bytes, whereas a character string such as a product name can be 20 to 100 bytes, and an address or description can be 100 to 1000 characters or more. When an object is variable length and consists of such a large number of bytes, the related technology cannot process it efficiently.

[0035] In this embodiment, unlike the related technology Seg-Trie, each node has a pair of serial strings and parallel branches. By having a pair of serial strings and parallel branches, it is possible to efficiently represent a sequence of multiple characters corresponding to a fixed word such as "Kabushiki Kaisha" or "Corporation" using serial strings. Furthermore, by using serial strings, it is possible to represent strings of different lengths within a single tree. Furthermore, for numeric keys, by performing conversion according to the type, it is possible to incorporate numeric data into part of the key, and this extension makes it possible to handle composite keys that combine strings and numeric data using the same processing method.

[0036] In the embodiment, unlike searches using tree structures based on related technologies such as VAST and B-Tree, instead of narrowing down the target section by comparing magnitudes, the tree is descended by detecting matching positions through a search for identical values ​​(branches). SIMD is used to detect these identical values, and the comparison results are converted into an index using bit mask conversion and bit scan instructions. This makes it possible to detect a search failure at that point if there is no branch with the identical value. Furthermore, in the embodiment, the number of branch bytes does not have to be a fixed size, but may be a different size between 1 and 256 for each node. Furthermore, in the embodiment, instead of preparing all data in advance and creating a fixed index structure before performing a search, an index structure that allows for search may be generated while dynamically adding data.

[0037] (Embodiment 1) Next, a description will be given of embodiment 1. In this embodiment, an example of performing an exact match search using a multi-node tree structure will be described.

[0038] <Data tree configuration example> 1 shows an example of the configuration of a data tree 111 according to this embodiment. The data tree 111 has a multi-node tree structure, and includes a plurality of nodes (node ​​information) 200 linked in a tree shape, and a character string (character string information) 300 referenced by the node 200. The character string 300 is a character string (registered character string) registered in the data tree 111, and is a character string that is a search target during a search. The character string 300 is a character string of a variable length ranging from 1 byte to several thousand bytes or more. The character string has a terminator (0x00) at the end.

[0039] 1, a node 200 includes a branch size 201, an alloc size 202, an entity flag 203, a branch position 204, a serial string 205, a branch byte string 206, and transition destination information 207. In this embodiment, one node 200 is configured by a pair of the serial string 205 (vertical direction) and the branch byte string 206 (horizontal direction).

[0040] Branch size 201 and alloc size 202 are management information for node 200. Branch size 201 is the number of branch bytes (branch characters) stored in branch byte string 206. Branch size 201 is also the number of branches that branch off from node 200 (connected to nodes subordinate to (below) node 200). Note that branches that branch off (transition) from node 200 are a mixture of either node 200 or character string 300 (leaf).

[0041] The alloc size 202 indicates the number of allocated branches. The alloc size 202 indicates the size allocated for storing branches by the node 200. For example, the alloc size 202 can be 4, 8, 16, 32, . . . , 256.

[0042] The entity flag 203, branch position 204, and serialized string 205 constitute header information for the node 200. The entity flag 203 is a flag that indicates whether the serialized string 205 held by the node 200 references (holds) an entity. The entity flag 203 is set to ON when there is a string 300 that ends exactly at the end of the serialized string 205, that is, when the end of the serialized string 205 and the end of the string 300 referenced by the serial string 205 match. The entity flag 203 is set to OFF when the end of the serialized string 205 and the end of the string 300 referenced by the serial string 205 do not match.

[0043] The branch position 204 indicates the offset position from the beginning of the string of the branch byte (branch character) held by the node 200. In other words, the branch position 204 indicates the position of the byte in the string to be searched that is to be matched with the branch byte.

[0044] The serial string 205 (serial string information) indicates the string of registered strings 300 that the node 200 references (holds). The serial string 205 points to the string 300 and indicates the same string portion (one type) in the tree using the portion of this string up to the branch position 204. Furthermore, if the entity flag 203 is ON, that is, if the end of the serial string 205 matches the end of the string 300, the serial string 205 holds the entity of the registered string 300 (entity retention). Entity retention means that the serial string independently points to the string 300 stored in the storage unit (database). In other words, if the entity flag 203 is ON, this indicates that the string pointed to by the serial string exists independently as a registered string. On the other hand, if the entity flag 203 is OFF, the serial string 205 references (shared reference) any of the strings 300 located below the node 200. A shared reference means that the serial character string 205 shares and references one of the character strings 300 at the transition destination indicated by the transition destination information 207 of the node 200 in question.

[0045] The branch byte sequence 206 includes branch bytes (branch characters) of branches branching from the node 200. The branch byte sequence 206 is also a set of branch characters including multiple branch characters. The branch byte indicates the value of one byte of the character following the serial string 205, and serves as a key for determining the branch destination (many types) at the branch position 204. The element size of the branch byte is one byte, and the value ranges from 0 to 255, resulting in 256 types. Therefore, the branch byte sequence 206 is a variable-length array that stores from 1 to 256 branch bytes. The branch byte sequence 206 stores these branch bytes in ascending order of unsigned integers.

[0046] The branch byte sequence 206 and the transition destination information 207 are also branch information relating to the transition destinations below the node 200. The transition destination information 207 is information indicating the transition destination (branch destination) corresponding to each branch byte in the branch byte sequence 206. The transition destination information 207 indicates whether the transition destination is a node / leaf (character string) and its location (address).

[0047] <Example of a data tree> Fig. 2 shows a specific example of data tree 111 according to this embodiment. In the example of Fig. 2, character strings 300-1 to 300-5 are registered in data tree 111 that includes nodes 200-1 to 200-2.

[0048] Character strings 300-1 to 300-5 have "DG" as the 0th and 1st characters in common. Therefore, the serial character string 205 of the first node 200-1 is "DG". And, since there is an actual character string 300-1 that contains "DG", the entity flag 203 of node 200-1 is ON.

[0049] Branch position 204 of node 200-1 points to 2, which is the next value after "DG," and from character strings 300-2 to 300-5, the unique value at that position is three characters (bytes): "H," "K," and "L." Therefore, branch byte string 206 of node 200-1 stores these three characters (bytes) as branch bytes, and branch size 201 is set to 3.

[0050] Transition destination information 207 of node 200-1 stores transition destinations corresponding to "H", "K", and "L" in branch byte sequence 206. Based on character strings 300-2 and 300-3, there is only one corresponding character string below each of "H" and "K", so transition destination information 207 of node 200-1 points to leaves (respective character strings 300-2 and 300-3) as the transition destinations of "H" and "K". On the other hand, based on character strings 300-4 and 300-5, there are multiple character strings below "L", so transition destination information 207 of node 200-1 points to node 200-2 as the transition destination of "L".

[0051] Character strings 300-4 to 300-5 share the third character "E" after "L." Therefore, in node 200-2, serial string 205 is "E." In this case, because there is no entity of a character string ending in "E," serial string 205 in node 200-2 shares a reference to one of lower leaf character strings 300-4 to 300-5, and entity flag 203 in node 200-2 is OFF. In this example, serial string 205 in node 200-2 points to character string 300-5. Branch position 204 in node 200-2 points to 4, which is after "E," and from character strings 300-4 to 300-5, the unique value at that position is two characters (bytes), "A" and "B." Therefore, branch byte string 206 in node 200-2 stores these two characters (bytes) as branch bytes, and branch size 201 is set to 2.

[0052] Transition destination information 207 of node 200-2 stores transition destinations corresponding to "A" and "B" in branch byte sequence 206. Since character strings 300-4 and 300-5 indicate that there is only one corresponding character string below each of "A" and "B," transition destination information 207 of node 200-2 indicates leaves (respective character strings 300-4 and 300-5) as the transition destinations of "A" and "B."

[0053] The alloc size 202 of the nodes 200-1 and 200-2 is set to 4, which is the minimum allocation size, because the branch sizes 201 of the two nodes are both 4 or less.

[0054] <Configuration of search device> FIG. 3 shows an example of the configuration of a search device 100 according to this embodiment. The search device 100 searches for character strings in a data tree 111 and registered character strings 112. The search device 100 may perform any of an exact match search, a prefix search, and a range search (larger and smaller search). Here, an example of an exact match search will be described as an example. Note that a suffix search can be performed by searching characters from the rear end in the same manner as for a prefix match. In this case, only the multi-node data tree 111 may be created for a suffix match, and the character strings 300 of the registered character strings 112, for example, character strings 300-1 to 300-5, may be shared.

[0055] 3, the search device 100 includes a database 110, an input unit 120, a search unit 130, and an output unit 140. However, other configurations may be used as long as they are capable of performing the operations according to this embodiment described below.

[0056] The database 110 is a storage unit that stores data to be searched by the search device 100. The database 110 stores, as search targets, a data tree 111 with the above-described multi-node tree structure and registered character strings 112. The registered character strings 112 store registered character strings 300.

[0057] The input unit 120 inputs information necessary for processing by the search device 100. For example, the input unit 120 may be an input device such as a keyboard that allows a user to input. For example, a search string to be searched (an input string that serves as a search key) is input by the user to the input unit 120. The input unit 120 also serves as an acquisition unit that acquires the search string to be searched from the data tree 111.

[0058] The search unit 130 executes a search process to search the data tree 111 for the search string input to the input unit 120. For example, the search unit 130 performs an exact match search, searching the data tree 111 and the registered strings 112 for a string that exactly matches the search string. The exact match search is an example of a process to search for a string that is exactly the same as the search string.

[0059] For example, the search unit 130 includes a search control unit 131, a string comparison unit 132, and a branch comparison unit 133. The search control unit 131 selects nodes 200 in the data tree 111 in order from the root, and controls the search process based on the comparison result between the information of the selected node 200 and the search string. The search control unit 131 determines the search results and controls node transitions based on the result of the serial string comparison by the string comparison unit 132 and the result of the branch byte string comparison by the branch comparison unit 133. The search control unit 131 also functions as a selection unit (first selection unit) that selects the branch node indicated by the selected node 200 as the transition destination node (the node to be compared next) depending on the result of the serial string comparison and the result of the branch byte string comparison. Whether the serialized string 205 contains a string entity can be determined by the ON / OFF state of the entity flag 203, so the search control unit 131 may determine the search results, etc., based on the result of the serial string comparison and the entity flag 203.

[0060] The string comparison unit (first string comparison unit) 132 performs a serial string comparison process that compares the serialized string 205 of the selected node 200 with the search string. When a leaf string is selected, the string comparison unit 132 compares the leaf string with the search string. In the serial string comparison process, two strings are compared using SIMD instructions and general instructions. Note that the SIMD instruction is an example of an instruction that performs comparison processing in predetermined data units that can be processed in parallel, and other instructions may be used in combination as long as they can be processed in a similar manner. The same applies to the branch byte string comparison process described below.

[0061] The branch comparator (first branch comparator) 133 performs a branch byte string comparison process that compares the branch byte in the branch byte string 206 of the selected node 200 with the character at the branch position 204 of the search string. Through the branch byte string comparison process, the branch comparator 133 identifies a branch byte (branch character) from the branch byte string 206 that matches the character at the branch position 204 of the search string. In the branch byte string comparison process, the branch byte string 206 is compared with the corresponding character in the search string using an SIMD instruction and a general instruction.

[0062] The output unit 140 outputs the processing results of the search device 100, etc. For example, the output unit 140 may be a display device such as a liquid crystal display. The output unit 140 may display the results of the search processing by the search unit 130. For example, the output unit 140 may display whether the search was successful or unsuccessful, a character string that matched the search character string, etc. The output unit 140 may display the tree structure of the data tree 111 stored in the database 110 and the registered character strings 112.

[0063] <Example of exact match search processing> 4A and 4B show an example of the operation of the exact match search process in the search device 100 according to this embodiment. In an exact match search, if the search is successful, only one character string is always found to match (S132, S151).

[0064] 4A and 4B, the search control unit 131 determines whether or not data is unregistered, i.e., whether or not the data is in an initial state (S101). When an input character string (search character string) is input to the input unit 120, the search control unit 131 refers to the database 110 and determines whether or not the data (character string) is registered in the data tree 111 of the database 110. If it is determined in S101 that the data is unregistered, the search control unit 131 treats the search result as a search failure and terminates the process (S120).

[0065] If it is determined in S101 that the data is registered, the search control unit 131 sets 0 to the byte check position and sets the root node of the data tree 111 as the current node (S102). As a result, either the node 200 or the leaf (character string 300) is set as the current node.

[0066] Next, the search control unit 131 determines whether the current node is a character string or not, that is, whether a leaf has been reached or not (S103). The search control unit 131 determines whether the current node is node 200 or character string 300.

[0067] If it is determined in S103 that the current node is a character string, the character string comparison unit 132 performs a serial character comparison (S130). In this case, the serial character string comparison compares the leaf character string that is the current node with the character string from the byte check position to the end of the input character string to check whether they are identical.

[0068] Next, the search control unit 131 determines whether there is a difference between the two compared character strings or whether the two character strings are different in size as a result of the serial character string comparison (S131). If it is determined in S131 that there is a difference between the two compared character strings or that the two character strings are different in size, the search control unit 131 determines the search result as a search failure and ends the process (S133).

[0069] In S131, if it is determined that the two compared character strings match and that the two character strings are the same, the search control unit 131 determines the search result as a successful search (the input character string and the leaf character string are the same) and ends the process (S132).

[0070] If it is determined in S103 that the current node is not a character string, that is, that it is a node, the search control unit 131 sets the result of "min (branch position of current node, input character string length + 1) - byte check position" as the comparison size (S104). That is, the search control unit 131 sets the comparison size to the smaller of the branch position 204 of node 200, which is the current node, and the length of the input character string plus one byte of terminator, minus the byte check position. Here, by adding 1 to the input character string length to include the terminator in the comparison range, if the input character string is shorter than the branch position of the current node, the setting is made so that a difference is detected at the terminator position of the input character string at the longest.

[0071] Next, the string comparison unit 132 performs a serial string comparison (S105). In this case, the serial string comparison compares the serial string 205 of the node 200, which is the current node, with a string of the comparison size from the byte check position in the input string to check whether they are identical.

[0072] Next, the search control unit 131 determines whether or not there is a difference between the two compared character strings as a result of the serial character string comparison (S106). If it is determined in S106 that there is a difference between the two compared character strings, the search control unit 131 treats the search result as a search failure and ends the process (S140).

[0073] If it is determined in S106 that the two compared character strings match, the search control unit 131 sets the branch position 204 of the node 200, which is the current node, in the byte check position (S107).

[0074] Next, the search control unit 131 determines whether the byte check position is equal to or greater than the input character string length, i.e., whether the input character check is complete (S108). If it is determined in S108 that the byte check position is equal to or greater than the input character string length, the search control unit 131 determines whether the serial character string 205 of the current node 200 is an entity (entity flag is ON) and whether the input character string and the serial character string 205 are the same size (S150).

[0075] In S150, if it is determined that the serial string 205 of the node 200, which is the current node, is an entity (the entity flag is ON) and that the size of the input string and the serial string 205 are the same, the search control unit 131 determines the search result as a successful search (the input string and the serial string 205 of the current node are the same) and terminates the processing (S151).

[0076] In S150, if it is determined that the serial string 205 of the current node 200 is not an entity (the entity flag is OFF) or that the size of the input string and the serial string 205 are different, the search control unit 131 treats the search result as a search failure and terminates the process (S152).

[0077] If it is determined in S108 that the byte check position is smaller than the input character string length, the branch comparison unit 133 performs a branch byte string comparison (S109). In this case, the branch byte string comparison compares the branch byte string 206 of the node 200, which is the current node, with the input character string [byte check position], and checks whether the branch byte string 206 of the current node has the same value as the input character string [byte check position]. Note that the byte (character) at the byte check position in the input character string may be referred to as the "input character string [byte check position]".

[0078] Next, the search control unit 131 determines whether or not the branch byte sequence 206 of the current node 200 has the same value as the result of the branch byte sequence comparison (S110). If it is determined in S110 that the branch byte sequence 206 of the current node 200 does not have the same value, the search control unit 131 treats the search result as a search failure and ends the process (S160).

[0079] If it is determined in S110 that the branch byte sequence 206 of the current node 200 has the same value, the search control unit 131 adds 1 to the byte check position and sets the transition destination information 207 corresponding to the matching branch byte in the current node (S111). After that, the processes from S103 onwards are repeated.

[0080] <Example of exact match search processing> A specific example of the exact match search process of Figures 4A and 4B will be described using Figure 5. In the example of Figure 5, character strings 300-1 to 300-8 are registered in a data tree 111 including nodes 200-1 to 200-4. In this example, the operation when searching for an input character string "DGHKPS" (6 characters) in an exact match search from the data tree 111 of Figure 5 will be described. Note that the notation of node 200 shown in Figure 5 is the same in each figure showing the following specific examples.

[0081] (1) First loop The search control unit 131 first checks the data registration in the data tree 111 (S101), and since the data is registered as shown in Fig. 5, it proceeds to initialization. In initialization, the search control unit 131 sets 0 to the byte check position and sets the root node as the current node (S102). In this case, the current node will point to the top node 200-1.

[0082] Next, in the first loop, the search control unit 131 checks whether the node 200-1, which is the current node, is a character string (leaf) (S103), and as it is not a character string, continues the loop processing.

[0083] Next, the search control unit 131 calculates the comparison size (S104). In this case, the comparison size is calculated by subtracting the byte check position, 0, from the smaller value of 1, which is the branch position 204 of the current node, node 200-1, (=1), or the string length of the input string "DGHKPS" + 1 = 7, resulting in 1.

[0084] Next, the string comparison unit 132 performs a serial string comparison (S105). In this case, the serial string comparison uses the string "DBXPN" pointed to by the serialized string 205 of node 200-1, which is the current node, and the input string "DGHKPS", and checks whether the strings from the 0th byte, which is the byte check position, to the comparison size of 1 byte are the same. As a result of the serial string comparison, the 0th byte of both the two strings is "D", and there is no difference in the strings (S106), so the search control unit 131 continues the loop processing.

[0085] Next, the search control unit 131 sets the byte check position to 1, which is the branch position 204 of the node 200-1, which is the current node (S107).

[0086] Next, the search control unit 131 checks whether the byte check position, 1, is equal to or greater than the input character string length, 6, i.e., whether the input character check is complete (S108), and continues the loop processing because the byte check position does not exceed the input character string length.

[0087] Next, the branch comparison unit 133 performs a branch byte string comparison (S109). In this case, the branch byte string comparison checks whether or not the branch byte string 206 = ("B", "G", "R") of the current node, node 200-1, contains the same value as the character "G" at byte check position = 1 in the input character string "DGHKPS". As a result of the branch byte string comparison, the first index of the branch byte string 206 of node 200-1 contains the same value (S110), so the search control unit 131 continues the loop processing.

[0088] Next, the search control unit 131 adds 1 to the byte check position, 1, to make it 2, and sets the transition destination information 207 corresponding to the first index="G" of the matching branch byte sequence 206 in the current node (S111). In this case, the current node points to the second highest node 200-2.

[0089] (2) Second loop Similarly, in the second loop, since the current node 200-2 is not a character string (leaf) (S103), the search control unit 131 calculates the comparison size (S104). In this case, the comparison size is calculated by subtracting the byte check position 2 from the smaller value of the branch position 204 of the current node 200-2 (=2) or the character string length of the input character string "DGHKPS" + 1 = 7, resulting in 0.

[0090] Next, the string comparison unit 132 performs a serial string comparison (S105). In this case, the serial string comparison compares the string "DG" indicated by the serial string 205 of the current node, node 200-2, with the input string "DGHKPS," and checks whether the strings from the second byte, which is the byte check position, to the comparison size of 0 bytes are identical. As a result of the serial string comparison, no difference is detected because the comparison size is 0 (S106), and the search control unit 131 continues the loop processing.

[0091] Next, the search control unit 131 sets the byte check position to 2, which is the branch position 204 of the node 200-2, which is the current node (S107).

[0092] Next, the search control unit 131 checks whether the byte check position, 2, is equal to or greater than the input character string length, 6, i.e., whether the input character check is complete (S108), and continues the loop processing since the input character check is not complete.

[0093] Next, the branch comparison unit 133 performs a branch byte string comparison (S109). In this case, the branch byte string comparison checks whether or not the branch byte string 206 = ("H", "K", "L") of the current node, node 200-2, contains the same value as the character "H" at byte check position = 2 in the input character string "DGHKPS". As a result of the branch byte string comparison, the branch byte string 206 of node 200-2 contains the same value at index 0 (S110), so the search control unit 131 continues the loop processing.

[0094] Next, the search control unit 131 adds 1 to the byte check position, 2, to make it 3, and sets the transition destination information 207 corresponding to the 0th index="H" of the matching branch byte sequence 206 in the current node (S111). In this case, the current node points to the third highest-order node on the left, 200-3.

[0095] (3) Third Loop Similarly, in the third loop, since the current node 200-3 is not a character string (leaf) (S103), the search control unit 131 calculates the comparison size (S104). In this case, the comparison size is calculated by subtracting the byte check position 3 from the smaller value of 5, which is the branch position 204 of the current node 200-3 (=5) or the character string length of the input character string "DGHKPS" + 1 = 7, resulting in 2.

[0096] Next, the string comparison unit 132 performs a serial string comparison (S105). In this case, the serial string comparison compares the string "DGHKP" indicated by the serial string 205 of the current node, node 200-3, with the input string "DGHKPS", and checks whether the strings of 2 bytes, which is the comparison size from the third byte, which is the byte check position, are identical. As a result of the serial string comparison, the strings of 2 bytes, which is the comparison size from the third byte, of the two strings are both "KP", which is identical (S106), so the search control unit 131 continues the loop processing.

[0097] Next, the search control unit 131 sets the byte check position to 5, which is the branch position 204 of the node 200-3, which is the current node (S107).

[0098] Next, the search control unit 131 checks whether the byte check position, 5, is equal to or greater than the input character string length, 6, i.e., whether the input character check is complete (S108), and continues the loop processing since the input character check is not complete.

[0099] Next, the branch comparison unit 133 performs a branch byte string comparison (S109). In this case, the branch byte string comparison checks whether or not the branch byte string 206=("S") of the current node, node 200-3, contains the same value as the character "S" at byte check position=5 in the input character string "DGHKPS". As a result of the branch byte string comparison, the branch byte string 206 of node 200-3 contains the same value at index 0 (S110), so the search control unit 131 continues the loop processing.

[0100] Next, the search control unit 131 adds 1 to the byte check position 5 to make it 6, and sets the transition destination information 207 corresponding to index 0=“S” of the matching branch byte sequence 206 to the current node (S111). In this case, the current node points to “DGHKPS”, which is the character string 300-4 (leaf).

[0101] (4) 4th (end) loop In the fourth loop, the search control unit 131 exits the loop and moves to the final determination because the current node, character string 300-4, is a character string and a leaf has been reached (S103).

[0102] In the final determination, first, the string comparison unit 132 performs a serial character comparison (S130). In this case, the serial character comparison compares the leaf character string "DGHKPS" with the input character string "DGHKPS" to check whether the character strings from the sixth byte of the byte check position to the end of the input character string are the same.

[0103] As a result of the serial string comparison, the input string has already reached its end, so no difference is detected. Since there are no differences between the leaf string and the input string and the string sizes are the same (S131), it is determined to be an exact match, and the search control unit 131 proceeds to return the results. In returning the results, the search control unit 131 returns search success (identical leaf strings) as the final result and ends the process (S132).

[0104] <Example of serial string comparison processing> Figures 6A and 6B show an example of the operation of the serial string comparison process according to this embodiment. Figures 6A and 6B are examples of the operation of the serial string comparison process of S105 and S130 in Figure 4. In the serial string comparison process, the serial string and the input string, or the leaf string and the input string, are compared to obtain indexes of the positions where the two strings differ.

[0105] 6A and 6B, the character string comparison unit 132 initializes the offset to 0 (S201). In this example, the unit of the offset is bytes.

[0106] Next, the string comparison unit 132 determines whether the value obtained by adding 16 to the offset is equal to or less than the comparison size (S202). If it is determined in S202 that the value obtained by adding 16 to the offset is equal to or less than the comparison size, the string comparison unit 132 specifies the offset position and acquires a difference position index (S220). In acquiring the difference position index, a SIMD instruction is used to compare the serial string with the input string, or the leaf string with the input string, and acquire the index position where there is a difference. In other words, if the size of the strings to be compared is equal to or greater than the SIMD size, a SIMD instruction is used to compare 16 bytes of strings at once.

[0107] Next, the character string comparison unit 132 determines whether or not a difference is found between the two character strings as a result of obtaining the difference position index (S221). If it is determined in S221 that the two character strings are the same, the character string comparison unit 132 adds 16 to the offset (S222) and repeats the processes from S202 onwards.

[0108] If it is determined in S221 that a difference is found between the two character strings, the character string comparison unit 132 adds the difference position index obtained in S220 to the offset, sets the obtained value as the difference position (S223), returns the set difference position, and ends the processing (S224).

[0109] If it is determined in S202 that the value obtained by adding 16 to the offset is greater than the comparison size, the string comparison unit 132 determines whether the value obtained by adding 8 to the offset is equal to or less than the comparison size (S203). That is, if the size of the strings to be compared is smaller than the SIMD size, the strings are compared in S203 and thereafter using a normal instruction according to the size of the strings to be compared. If it is determined in S203 that the value obtained by adding 8 to the offset is equal to or less than the comparison size, the string comparison unit 132 performs an xor (exclusive or) comparison of the offset position using a uint64_t type (unsigned 64-bit integer type) (S204).

[0110] Next, the string comparison unit 132 determines whether the result of the xor comparison of the two strings is a value other than 0 (S205). If it is determined in S205 that the result of the xor comparison of the two strings is 0, that is, that the two strings are the same, the string comparison unit 132 adds 8 to the offset (S206).

[0111] If it is determined in S203 that the value obtained by adding 8 to the offset is greater than the comparison size, or after adding 8 to the offset via S206, the string comparison unit 132 determines whether the value obtained by adding 4 to the offset is less than or equal to the comparison size (S207).

[0112] If it is determined in S207 that the value obtained by adding 4 to the offset is equal to or smaller than the comparison size, the string comparison unit 132 performs an xor comparison of the offset position in uint32_t type (unsigned 32-bit integer type) (S208).

[0113] Next, the string comparison unit 132 determines whether the result of the xor comparison of the two strings is a value other than 0 (S209). If it is determined in S209 that the result of the xor comparison of the two strings is 0, that is, that the two strings are the same, the string comparison unit 132 adds 4 to the offset (S210).

[0114] If it is determined in S207 that the value obtained by adding 4 to the offset is greater than the comparison size, or after adding 4 to the offset via S210, the string comparison unit 132 determines whether the value obtained by adding 2 to the offset is less than or equal to the comparison size (S211).

[0115] If it is determined in S211 that the value obtained by adding 2 to the offset is equal to or smaller than the comparison size, the string comparison unit 132 performs an xor comparison of the offset position in uint16_t type (unsigned 16-bit integer type) (S212).

[0116] Next, the character string comparison unit 132 determines whether the xor comparison result of the two character strings is other than 0 (S213). If the xor comparison result of the two character strings is other than 0 in S205, S209, and S213, that is, if it is determined that there is a difference between the two character strings, the character string comparison unit 132 obtains the position of the first ON bit from the comparison result (S230). Specifically, _BitScanForward(comparison result) is executed to obtain the position of the first ON bit from the xor comparison result.

[0117] Next, the string comparison unit 132 adds the value converted into the byte position by shifting the first ON bit position to the offset (byte position) by 3 bits to the right, sets the obtained value to the difference position (S231), returns the set difference position, and ends the processing (S232).

[0118] In S213, if the result of the xor comparison of the two character strings is 0, that is, if it is determined that the two character strings are the same, the character string comparison unit 132 adds 2 to the offset (S214).

[0119] If it is determined in S211 that the value obtained by adding 2 to the offset is greater than the comparison size, or after adding 2 to the offset via S214, the string comparison unit 132 determines whether the offset is smaller than the comparison size (S215).

[0120] If it is determined in S215 that the offset is smaller than the comparison size, the character string comparison unit 132 compares the offset position in uint8_t type (unsigned 8-bit integer type) (S216).

[0121] Next, the character string comparison unit 132 determines whether there is a difference in the comparison result of the two character strings (S217). If it is determined in S217 that there is a difference in the comparison result of the two character strings, the character string comparison unit 132 sets an offset to the difference position (S240), returns the set difference position, and ends the processing (S241). On the other hand, if it is determined in S215 that the offset is equal to or greater than the comparison size, or if it is determined in S217 that there is no difference in the comparison result of the two character strings, the character string comparison unit 132 returns that there is no difference, and ends the processing (S218).

[0122] <Example of branch byte sequence comparison processing> Fig. 7 shows an example of the operation of the branch byte string comparison process according to this embodiment. Fig. 7 shows an example of the operation of the branch byte string comparison process of S109 in Fig. 4. In the branch byte string comparison process, the branch byte string 206 of node 200 is compared with a comparison byte, and the index of the position in branch byte string 206 that matches the comparison byte is obtained.

[0123] 7, the branch comparison unit 133 determines whether the branch size 201 (number of branches) of the node 200 is 16 or less (S301). If it is determined in S301 that the branch size 201 is 16 or less, the branch comparison unit 133 specifies a branch byte string and acquires a match position index (S302). In acquiring the match position index, an SIMD instruction is used to acquire an index indicating the position of a character that matches the comparison byte from the branch byte string 206.

[0124] Next, as a result of obtaining the matching position index, the branch comparison unit 133 determines whether or not a matching position matching the comparison byte has been found in the branch byte sequence 206 (S303). If it is determined in S303 that a matching position matching the comparison byte has not been found in the branch byte sequence 206, the branch comparison unit 133 returns no match and ends the process (S306).

[0125] If it is determined in S303 that a matching position that matches the comparison byte has been found in the branch byte sequence 206, the branch comparison unit 133 sets an index indicating the matching position to the matching position (S304), returns the set matching position, and terminates the processing (S305).

[0126] If it is determined in S301 that the branch size 201 is greater than 16, the branch comparison unit 133 first specifies a branch byte sequence and acquires a search section index (S307). Because the branch byte sequence is arranged in ascending order of unsigned integers, as shown in FIG. 1, the search section index acquisition involves extracting bytes at positions that are integer multiples of the SIMD size (16 bytes) and determining where the comparison byte is located within the extracted byte group, thereby identifying the 16-byte search section (comparison position) to be used in the next match determination. Because the branch byte is 1 byte, the number of types is at most 256, and the maximum length is also 256 bytes. Therefore, 256 ÷ 16 = 16, and this search section identification operation uses a 16-byte SIMD, allowing the desired search section to be narrowed down with a single process.

[0127] Next, the branch comparison unit 133 determines whether or not the search section has been found in the branch byte sequence 206 as a result of obtaining the search section index (S308). If it is determined in S308 that the search section has not been found in the branch byte sequence 206, the branch comparison unit 133 returns no match and ends the process (S306).

[0128] If it is determined in S308 that the search section is found in the branch byte sequence 206, the branch comparison unit 133 specifies the search section and acquires a matching position index (S309). In acquiring the matching position index, as in S302, an SIMD instruction is used to acquire an index indicating a matching position that matches the comparison byte in the search section of the branch byte sequence 206.

[0129] Next, the branch comparison unit 133 determines whether or not a matching position that matches the comparison byte has been found within the search section of the branch byte sequence 206 as a result of obtaining the matching position index (S310). If it is determined in S310 that a matching position that matches the comparison byte has not been found within the search section of the branch byte sequence 206, the branch comparison unit 133 returns no match and ends the process (S306).

[0130] If it is determined in S310 that a matching position that matches the comparison byte has been found within the search section of the branch byte sequence 206, the branch comparison unit 133 adds an index indicating the matching position to the start position of the search section and sets the value as the matching position as an index within the entire branch byte (S311), returns the set matching position, and terminates the processing (S312).

[0131] <Example of difference position index acquisition process> FIG. 8 shows an example of the operation of the difference position index acquisition process according to this embodiment. FIG. 8 shows an example of the operation of the difference position index acquisition process of S220 in FIG. 6. In the difference position index acquisition process, the serial string and the input string, or the leaf string and the input string, are compared to check for differences between the two strings and acquire the index positions where there are differences. In the example of FIG. 8, the number of characters to be compared is 16 (SIMD 128-bit size). Note that in this example (including FIGS. 9 to 11), the SIMD data size is 128 bits (16 bytes) using SIMD instructions of the X86 architecture as an example, but this is not limiting, and similar processing may be performed for even wider data widths by using SIMD instructions of 256 bits (32 bytes) or more.

[0132] As shown in FIG. 8, two character strings to be compared are stored in 16-byte SIMD registers Src1 and Src2, respectively. In the difference position index acquisition process, first, the character string comparison unit 132 uses an SIMD instruction to compare Src1 and Src2 (S401). Specifically, "C=_mm_cmpeq_epi8(Src1,Src2)" is executed to perform a SIMD byte-wise equality comparison on Src1 and Src2, and the comparison result is set to the 16-byte variable C. _mm_cmpeq_epi8 performs a byte-wise comparison of 16 bytes of data at a time, setting "FF" to bytes with the same value and "00" to bytes with different values. In this example, since the characters in the 6th and 11th bytes of Src1 and Src2 are different, the 6th and 11th bytes of variable C are set to "00," and the other bytes are set to "FF."

[0133] Next, the string comparison unit 132 uses a SIMD instruction to aggregate the bits of variable C to which the comparison result has been set (S402). Specifically, "D=_mm_movemask_epi8(C)" is executed to aggregate the most significant bit of each byte of the 16-byte variable C and set it as variable D of type int16 (signed 16-bit integer). _mm_movemask_epi8 aggregates 16 bytes of data using only one assembler instruction and converts it to 16 bits. In this example, the 6th and 11th bits of variable D become "0", and all other bits become "1".

[0134] Next, the character string comparison unit 132 inverts all bits of variable D, which is an aggregate of the comparison results (S403). Specifically, "E=~D" is executed, and the result of inverting all bits of variable D is set to variable E of type int16. In this example, the 6th and 11th bits of variable E become "1", and all other bits become "0".

[0135] Next, the character string comparison unit 132 determines whether or not a difference has been found between Src1 and Src2 based on the variable E after all bits have been checked (S404). Specifically, it executes "if(E!=0)" to determine whether or not the variable E is other than 0. In this example, since the variable E is other than 0, it is determined that a difference has been found.

[0136] Next, if it is determined that a difference is found between Src1 and Src2, the string comparison unit 132 obtains the first index position where there is a difference from variable E (S405). Specifically, it executes "diff_idx = _BitScanForward(E)", obtains the position of the first ON bit from variable E, sets the obtained bit position to variable diff_idx, and identifies the index position where there is a difference. In this example, the index position where there is a difference is "6". Since the first difference position has been obtained, the magnitude result of the key in dictionary order of the strings is obtained by comparing one byte at this difference position [6] as an unsigned numeric value. Note that _BitScanForward() is directly expanded inline into a bit position index obtainment command (BSF or CLZ), which is an assembler command that the CPU has as a result of compilation, and therefore is executed at high speed without overhead such as a function call (the same applies to _BitScanReverse()).

[0137] <Example of matching position index acquisition process> Fig. 9 shows an example of the operation of the matching position index acquisition process according to this embodiment. Fig. 9 shows an example of the operation of the matching position index acquisition process of S302 and S309 in Fig. 7. In the matching position index acquisition process, a check is made to see if there is a byte with the same value as the comparison byte in branch byte sequence 206 of node 200 or in the search section of branch byte sequence 206, and an index indicating the matching position is acquired.

[0138] In the example of Figure 9, the search character (comparison byte) is "E", the value of each byte is expressed in ASCII notation, the number of characters to be searched is 7, "?" indicates an indefinite value, and the branch byte string allocate size is 8.

[0139] As shown in FIG. 9, the character string to be searched (branch byte string or search section of branch byte string) is stored in a 16-byte SIMD register Src1. In this example, the allocated size of the branch byte string is 8 bytes (FIG. 9(a)), and the branch character is stored in bytes 0 to 6 of Scr1. The value of the remaining bytes, 7 to 15, is undefined. For example, the remaining bytes store transition destination information, as described below (FIG. 9(b)).

[0140] In the match position index acquisition process, first, the branch comparison unit 133 uses a SIMD instruction to generate a character string in which the search character (comparison byte) is expanded (S501). Specifically, "A=_mm_set1_epi8('E')" is executed to expand the search character "E" to all bytes of the 16-byte variable A.

[0141] 8, the branch comparison unit 133 uses an SIMD instruction to compare the search target Src1 with the search character variable A (S502). Specifically, it executes "C=_mm_cmpeq_epi8(Src1,A)", performs a SIMD byte-wise equality comparison on Src1 and A, and sets the comparison result to the 16-byte variable C. In this example, since the fourth byte of Src1 is the search character "E", the zeroth to third bytes of variable C are "00", the fourth byte is "FF", the fifth and sixth bytes are "00", and the seventh to fifteenth bytes are undefined.

[0142] 8, the branch comparison unit 133 uses a SIMD instruction to aggregate the bits of variable C to which the comparison result is set (S503). Specifically, it executes "D=_mm_movemask_epi8(C)" to aggregate the most significant bits of each byte of the 16-byte variable C, and sets the aggregated bits to variable D of type int16. In this example, bits 0 to 3 of variable D are "0", bit 4 is "1", bits 5 to 6 are "0", and bits 7 to 15 are undefined.

[0143] Next, the branch comparison unit 133 clears the indefinite bits of the variable D that aggregates the comparison results (S504). For example, as shown in FIG. 9, mask[0] to

[16] is prepared as a mask that matches the number of valid characters. Then, "E=D&mask[number of valid characters]" is executed, a mask that matches the number of valid characters is applied to variable D, and the result after clearing the bits other than the number of valid characters is set to variable E. In this example, since the number of characters to be searched is seven, mask[7] in which bits 0 to 6 are "1" is used, and the indefinite bits from bit 7 to bit 15 are cleared to "0".

[0144] Next, the branch comparison unit 133 determines whether or not the search character has been found from the variable E whose indefinite bits have been cleared (S505), similarly to S404 in Fig. 8. Specifically, "if (E!=0)" is executed to determine whether or not the variable E is other than 0. In this example, since the variable E is other than 0, it is determined that the search character has been found.

[0145] Next, if it is determined that the search character has been found, the branch comparison unit 133 acquires the index position where the search character is located from variable E (S506), similar to S405 in Fig. 8. Specifically, it executes "match_idx=_BitScanForward(E)", acquires the position of the first ON bit from variable E, sets the acquired bit position to variable match_idx, and identifies the index position with the same value as the search character. In this example, the index position where the search character is located is "4".

[0146] <Example of search section index acquisition process> 10A and 10B show an example of the operation of the search section index acquisition process according to this embodiment, which is the process of S307 in FIG.

[0147] Since the maximum number of branch bytes is 256, if the branch size exceeds 16 bytes, the search section index acquisition process is first performed. In the search section index acquisition process, the search section is acquired from the branch byte sequence 206 with a size greater than 16. The result is then used to further acquire the match position index described above, thereby determining the final match position.

[0148] In the examples of FIGS. 10A and 10B, the search character is 0x6d (ASCII "m"), the value of each byte is expressed in hexadecimal notation, the number of characters to be searched is 71, and "?" indicates an indefinite value.

[0149] As shown in FIG. 10A, the search target (branch byte string) has a character string of 80 bytes ([0] to

[79] ), and this character string is divided into five segments of 16 bytes each. Segment [0] is the character string from byte 0 to byte 15, segment [1] is the character string from byte 16 to byte 31, segment [2] is the character string from byte 32 to byte 47, segment [3] is the character string from byte 48 to byte 63, and segment [4] is the character string from byte 64 to byte 79. The values ​​of bytes 71 to 79 are undefined.

[0150] In the search section index acquisition process, the branch comparison unit 133 first acquires the character of the first byte of each segment (S601). Specifically, "A=_mm_setr_epi8 (byte at a multiple of 16)" is executed, and the first byte of the search target is loaded for each SIMD processing width up to the number of characters to be searched, and set to the 16-byte variable A. In this example, the character at the 0th byte of the search target is set to the 0th byte of variable A, the character at the 16th byte of the search target is set to the 1st byte of variable A, the character at the 32nd byte of the search target is set to the 2nd byte of variable A, the character at the 48th byte of the search target is set to the 3rd byte of variable A, and the character at the 64th byte of the search target is set to the 4th byte of variable A. Bytes 5 to 15 of variable A are undefined.

[0151] Next, the branch comparison unit 133 converts the variable A for signed arithmetic (S602). For example, a 16-byte variable N with "80" set in all bytes is used. Specifically, "A=_mm_xor_si128(A,N)" is executed to convert the values ​​of 0 to 255 of each byte of the variable A to values ​​of -128 to +127. Note that the SIMD integer comparison of the X86 CPU only supports signed greater-than (gt) comparison, so conversion to signed values ​​is performed. However, if the processing system is different and SIMD comparison can be performed using unsigned values ​​as they are, the comparison may be performed as unsigned values ​​without conversion.

[0152] Next, the branch comparison unit 133 uses an SIMD instruction to perform a signed greater-than comparison on a byte-by-byte basis of the converted variable A (S603). For example, a 16-byte variable B is used, in which all bytes are set to "ed" (-19), which is the search character 0x6d converted for signed arithmetic using the same method as in S602. Specifically, "C=_mm_cmpgt_epi8(A,B)" is executed, a SIMD byte-by-byte signed comparison is performed on variables A and B, and the comparison result is set to the 16-byte variable C. In this example, the fourth byte of variable A is "f7" (-9), which is greater than "ed" (-19), so the 0th to 3rd bytes are "00", the 4th byte is "FF", and the 5th to 15th bytes are undefined.

[0153] 8, the branch comparison unit 133 uses a SIMD instruction to aggregate the bits of variable C to which the comparison result has been set (S604). Specifically, it executes "D=_mm_movemask_epi8(C)" to aggregate the most significant bits of each byte of the 16-byte variable C, and sets the aggregated bits to variable D of type int16. In this example, bits 0 to 3 of variable D are "0", bit 4 is "1", and bits 5 to 15 are undefined.

[0154] Next, the branch comparison unit 133 inverts all bits of variable D, which aggregates the comparison results, in the same way as in S403 of Fig. 8 (S605). Specifically, "E = ~D" is executed, and the result of inverting all bits of variable D is set to variable E of type int16. This all-bit inversion operation converts the result of a greater-than comparison (gt) into the result of a less-than or equal comparison (le). In this example, bits 0 to 3 of variable E are "1", bit 4 is "0", and bits 5 to 15 are undefined.

[0155] Next, the branch comparison unit 133 uses a mask based on the number of search characters, as in FIG. 9, to clear the indefinite bits of variable D (S606). Specifically, "F=E&mask[((71-1)>>4)+1]" is executed, and the result of clearing the indefinite bits is set to variable F. The value obtained by subtracting 1 from the number of search characters 70 is shifted 4 bits to the right, and the shift result is added by 1, resulting in a value of 5. Therefore, using mask[5], in which the 5 bits from bit 0 to bit 4 are "1," the indefinite bits from bit 5 to bit 15 are cleared to "0."

[0156] 8, the branch comparison unit 133 determines whether the search section has been found from the variable F whose indefinite bits have been cleared (S607). Specifically, it executes "if (F!=0)" to determine whether the variable F is other than 0. In this example, since the variable F is other than 0, it is determined that the search section has been found.

[0157] Next, the branch comparison unit 133 obtains the index position that identifies the search range from variable F (S608). Specifically, it executes "segment_idx=_BitScanReverse(F)", obtains the position of the last ON bit from variable F, and sets the obtained position, 3, to variable segment_idx to identify the search range. As a result, segment [3] (48th byte to 63rd byte) becomes the finally identified search range. After this, the segment in the obtained search range [3] is used to execute the above-mentioned match position index acquisition, thereby determining the final index position, 54.

[0158] Note that the process of collecting the first byte for each SIMD processing width in S601 involves sporadically accessing a relatively wide range of memory, which reduces cache efficiency. For this reason, these bytes may be collected in advance and stored in the first 16 bytes of the branch byte sequence, forming an index (super index) for range search. <Example of byte most significant bit aggregation processing>

[0159] FIG. 11 shows an example of emulation of byte most significant bit aggregation according to this embodiment. FIG. 11 is an example of emulation of byte most significant bit aggregation (_mm_movemask_epi8(a)) in S402 of FIG. 8, S503 of FIG. 9, and S604 of FIG. 10B. Since the byte most significant bit aggregation instruction cannot be used in CPUs other than the X86 system, an equivalent function is emulated as shown in FIG. 11. FIG. 11 is an example in an Arm CPU using horizontal addition. For example, an emulator included in the string comparison unit 132 or the branch comparison unit 133 executes the operation of FIG. 11.

[0160] In the example in Figure 11, the aggregation target is the 16-byte variable a. As shown above, the comparison result of 0xFF or 0x00 is set in each byte of variable a. In this example, the 6th and 11th bytes are 00, and the other bytes are FF.

[0161] As shown in FIG. 11, first, the emulator uses a bit mask to extract bits from variable a to be aggregated (S701). For example, a bit mask M is used, which has values ​​obtained by shifting each byte one bit to the left, such as 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, and 0x80. Specifically, "B=vandq_u8(a,M)" is executed, and the AND of variable a and bit mask M is taken to extract bits, and the extracted results are set in 16-byte variable B. In this example, the 6th and 11th bytes of variable B are 0, and each of the other bytes becomes the value of bit mask M.

[0162] Next, the emulator divides variable B into two parts and converts the divided 8-byte data into 8-bit data (S702). For example, variable B is divided into two parts (top and bottom), byte 0 to byte 7 and byte 8 to byte 15, and these are added horizontally. Specifically, "CL=vaddv_u8(vget_Low_u8(B))" is executed, and each byte from byte 0 to byte 7 of variable B is added horizontally, and the result of the horizontal addition is set to the 8-bit variable CL. In this example, the 6th bit of variable CL is set to 0, and the other bits are set to 1. Similarly, "CH=vaddv_u8(vget_high_u8(B))" is executed, and each byte from byte 8 to byte 15 of variable B is added horizontally, and the result of the horizontal addition is set to the 8-bit variable CH. In this example, the 3rd bit of variable CH is set to 0, and the other bits are set to 1.

[0163] Next, the emulator combines the two converted 8-bit data (S703). Specifically, it executes "Res=CL | (CH<<8)" to combine (combine top and bottom) the variable CL with the value of the variable CH shifted 8 bits to the left, sets the combined result to the variable Res, and completes the aggregation. In this example, the 6th and 11th bits are 0, and all other bits are 0.

[0164] <Example of node data memory allocation> 12 shows an example of memory arrangement of data in node 200 according to this embodiment. As shown in Fig. 12, the elements of node 200 are arranged in memory in the following order: entity flag 203, branch position 204, serial string 205, branch byte string 206, and transition destination information 207. That is, the transition destination information 207 is stored consecutively after the branch byte string 206. In this embodiment, the entity flag 203, branch position 204, and serial string 205 are referenced using a normal instruction, then the branch byte string 206 is referenced using a SIMD instruction, and then the transition destination information 207 is referenced using a normal instruction.

[0165] The branch byte sequence can vary in size from 1 byte to a maximum of 256 bytes. SIMD processing, on the other hand, is performed on consecutive memory addresses according to the SIMD size (128 bits = 16 bytes, 256 bits = 32 bytes). For this reason, when processing data that does not meet the SIMD size, a buffer memory area is typically provided after the data to avoid memory reference violations. However, this method increases the waste of buffer memory when there are few branch bytes, and simultaneously leads to performance degradation, especially in recent CPUs that utilize caches more effectively. For this reason, in this embodiment, the transition destination information (Figure 9(b)) is placed immediately after the branch byte sequence (Figure 9(a)). This prevents a decrease in memory utilization efficiency due to the allocation of buffer memory, even in cases where the allocation number is 4 or 8, and also increases the probability that the transition destination information used immediately after the branch byte access will be pre-loaded into the cache.

[0166] <Effects> As described above, in this embodiment, the node information of a multi-node tree stores a set of a serial string that references string information, a byte string of a branch byte that indicates the value of the next byte, and transition destination information that corresponds to that branch byte. Furthermore, the node information also contains information that complements this information: an entity flag that indicates that the string pointed to by the serial string is the entity of the string, and branch position information that indicates which byte in the string is to be compared with the branch byte.

[0167] In this embodiment, nodes having pairs of serial strings and branch bytes, and leaves that are string information, are configured as a multi-node tree, and by combining operations on both serial strings and branch bytes with parallel comparisons (SIMD instructions), variable-length strings can be searched efficiently.

[0168] In this embodiment, when performing an exact match search, the search is performed by tracing the nodes from the top down while using two comparison operations on the input string: serial string comparison and branch byte string comparison. Because strings are often composed of combinations of specific words and place names such as "Corporation" or "California," the effectiveness of serial string comparison, which performs wide-range comparisons internally using SIMD, is significant when identical strings appear for long periods of time. Similarly, even when the length of the string itself exceeds 100 or 1,000 bytes, wide-range comparisons using SIMD can be expected to reduce the number of comparisons. Furthermore, in the above example, the number of branch bytes is assumed to be several for the sake of simplicity. However, the maximum number of branch bytes is 256. Therefore, as the number increases, the effectiveness of parallel comparison operations using SIMD and index conversion within the branch byte string comparison increases.

[0169] Furthermore, recent CPUs attempt to reduce instruction processing time by performing pipeline operation, in which instructions are divided into multiple stages and executed sequentially. However, this pipeline operation becomes disrupted when conditional branching is performed, resulting in reduced processing efficiency. For this reason, in this embodiment, SIMD instructions are used when obtaining a difference position index, a match position index, and a search section index in serial string comparison and branch byte string comparison, and conditional branching is used only once in each processing sequence (if statements in Figures 8, 9, and 10B). This reduces pipeline disruption within the CPU caused by conditional branching, enabling efficient processing.

[0170] Furthermore, recent CPUs have relatively large cache memories so that their operating speed is not hindered by the memory access speed of DRAM, which is generally used for main memory. In this embodiment, by storing transition destination information of the node / leaf corresponding to the branch after the branch byte string in the node, memory reference violations by SIMD do not occur when the number of branches is less than the basic size of 128 bits or 256 bits of SIMD, improving memory utilization efficiency, and by simultaneously loading the next transition destination information to be accessed into the cache, the cache hit rate is increased, thereby improving processing efficiency. In the search process to check whether the same value has already been registered, the process of comparing serial strings when descending the tree of search nodes (S105-S106) may be omitted, and a check for identity with the final leaf string (S130) and a check for identity with serial strings (S150) may be performed to determine whether the entire string matches the input string. However, this omission is not possible in the registration process described below (Embodiment 3).

[0171] (Embodiment 2) Next, a description will be given of a second embodiment. In this embodiment, an example will be described in which a prefix match search is performed in the search device 100 shown in the first embodiment. The configuration of the search device 100 is the same as in the first embodiment.

[0172] <Example of prefix search operation> 13A and 13B show an example of the operation of the prefix match search process in the search device 100 according to this embodiment. The prefix match search process in Fig. 13A and 13B differs from the exact match search process in Fig. 4A and 4B in the processes of S131, S150, and S151.

[0173] In the case of an exact match search, in S131, which determines the comparison result between the input string and the leaf string, the search is determined to be successful if the content and length of the input string and the leaf string are identical. In contrast, in the case of a prefix match search, in S131a, it is determined whether the characters up to the length of the input string are the same as those in the leaf string, and if the characters up to the length of the input string are the same as those in the leaf string, the search is determined to be successful regardless of the content of the subsequent strings. In S132, since there is a match at the leaf, only one string is returned.

[0174] Also, in the case of an exact match search, in S150 and S151, where the loop is exited midway through a node, only the serial string of the node in question is the search result. In contrast, in the case of a prefix match search, in S150a and S151a, all of the multiple leaf strings below the node in question are included in the search results. For this reason, in S150a, initialization required for iterative acquisition (iterator) is performed. Specifically, the stack level is set to 0, the current node is set to stack[0].node, and -1 is set to stack[0].branchnumber. Next, in S151a, information for iterative acquisition (iterator) is returned.

[0175] <Example of prefix search processing> A specific example of the prefix search processing of Figures 13A and 13B will be described using Figure 14. In the example of Figure 14, similar to Figure 5, character strings 300-1 to 300-8 are registered in the data tree 111 including nodes 200-1 to 200-4. In this example, the operation when searching for the input character string "DG" (two characters) in a prefix search from the data tree 111 of Figure 14 will be described.

[0176] (1) First loop The search control unit 131 first checks the data registration in the data tree 111 (S101), and since the data is registered as shown in Fig. 14, proceeds to initialization. In initialization, the search control unit 131 sets 0 to the byte check position and sets the root node as the current node (S102). In this case, the current node will point to the top node 200-1.

[0177] Next, in the first loop, the search control unit 131 checks whether the node 200-1, which is the current node, is a character string (leaf) (S103), and as it is not a character string, continues the loop processing.

[0178] Next, the search control unit 131 calculates the comparison size (S104). In this case, the comparison size is calculated by subtracting 0, which is the byte check position, from 1, which is the smaller of the branch position 204 of the current node 200-1 (=1) and the character string length of the input character string "DG" + 1 = 3, resulting in 1.

[0179] Next, the string comparison unit 132 performs a serial string comparison (S105). In this case, the serial string comparison uses the string "DBXPN" pointed to by the serial string 205 of node 200-1, which is the current node, and the input string "DG", and checks whether the characters from the 0th byte, which is the byte check position, to the comparison size of 1 byte are the same. As a result of the serial string comparison, the 0th byte of both the two strings is "D", and there is no difference in the strings (S106), so the search control unit 131 continues the loop processing.

[0180] Next, the search control unit 131 sets the byte check position to 1, which is the branch position 204 of the node 200-1, which is the current node (S107).

[0181] Next, the search control unit 131 checks whether the byte check position, 1, is equal to or greater than the input character string length, 2, i.e., whether the input character check is complete (S108), and continues the loop processing because the byte check position does not exceed the input character string length.

[0182] Next, the branch comparison unit 133 performs a branch byte string comparison (S109). In this case, the branch byte string comparison checks whether or not the branch byte string 206 = ("B", "G", "R") of the current node, node 200-1, contains the same value as the character "G" at byte check position = 1 in the input character string "DG". As a result of the branch byte string comparison, the first index of the branch byte string 206 of node 200-1 contains the same value (S110), so the search control unit 131 continues the loop processing.

[0183] Next, the search control unit 131 adds 1 to the byte check position, 1, to make it 2, and sets the transition destination information 207 corresponding to the first index="G" of the matching branch byte sequence 206 in the current node (S111). In this case, the current node points to the second highest node 200-2.

[0184] (2) Second loop Similarly, in the second loop, since the current node 200-2 is not a character string (leaf) (S103), the search control unit 131 calculates the comparison size (S104). In this case, the comparison size is calculated by subtracting the byte check position 2 from the smaller value of the branch position 204 of the current node 200-2 (=2) or the character string length of the input character string "DG" + 1 = 3, resulting in 0.

[0185] Next, the string comparison unit 132 performs a serial string comparison (S105). In this case, the serial string comparison compares the string "DG" indicated by the serial string 205 of the current node, node 200-2, with the input string "DG," and checks whether the characters from the second byte, which is the byte check position, to the comparison size of 0 bytes are identical. As a result of the serial string comparison, no difference is detected because the comparison size is 0 (S106), and the search control unit 131 continues the loop processing.

[0186] Next, the search control unit 131 sets the byte check position to 2, which is the branch position 204 of the node 200-2, which is the current node (S107).

[0187] Next, the search control unit 131 checks whether the byte check position, 2, is equal to or greater than the input character string length, 2, i.e., whether the input character check is complete (S108), and since the byte check position is equal to or greater than the input character string length, the search control unit 131 exits the loop.

[0188] (3) End of loop If the loop is exited in S108, the search process ends at a non-leaf position. In this case, the search control unit 131 returns information for the iterator, which will be described next, and then uses the iterator again to sequentially output multiple leaf character strings below the node. Specifically, for the iterator, the stack level is initialized to 0, the top stack node is set to the current node (the second-highest node 200-2), and the branch number is set to -1 (S150a). Next, the search control unit 131 returns information for the iterator (S151a).

[0189] <Example of repeated acquisition process> 15A and 15B show an example of the operation of the iterative acquisition process according to this embodiment. Figures 15A and 15B show an example of the operation of the iterative output process using the iterative acquisition (iterator) information returned in S151a of Figure 13B.

[0190] When iterative retrieval is performed in ascending order (iterator), registered data is repeatedly retrieved from a specific string, and the results are obtained in the lexicographical order of the string. When iterative retrieval is performed in ascending order, the serial string (entity) and branch leaf (from smallest to largest) are retrieved within the node, and if the branch points to a node, the node is moved to and the same procedure is repeated.

[0191] When iteratively acquiring in descending order, the acquisition direction is reversed from the ascending order. In descending order, within the node, the branch leaves (largest first) and the serial string (entity) are acquired in that order, and if the branch points to a node, the node is moved to and the same procedure is repeated.

[0192] The iterative retrieval process can also be applied to sorting and range searches. Iterative retrieval can return leaf nodes in order from a specified node, so by targeting the top node, all registered data can be retrieved in ascending (descending) order. This is the same as the result of sorting registered data in lexicographical order. In addition, by using a search or other method to perform iterative retrieval starting from an arbitrary node, it can also be applied to range searches in ascending (descending) order or retrieval of a specified number of data items.

[0193] 15A and 15B show an example of operation when repeated acquisition is performed in ascending order. As shown in FIGS. 15A and 15B, the search control unit 131 clears the output list (S801). Next, the search control unit 131 determines whether there is free space in the output list and whether the stack level is 0 or greater (S802). If it is determined in S820 that there is no free space in the output list or that the stack level is less than 0, the search control unit 131 returns the current result list (S820) and ends the process.

[0194] If it is determined in S820 that there is space in the output list and the stack level is 0 or greater, the search control unit 131 sets the current node to stack[stack level].node and the current branch to stack[stack level].branch number (S803).

[0195] Next, the search control unit 131 determines whether the current branch is equal to or larger than the branch size 201 of the current node, i.e., whether all branches have been processed (S804). If it is determined in S804 that the current branch is equal to or larger than the branch size 201 of the current node, the search control unit 131 decrements the stack level (S810) and repeats the processing from S802 onwards.

[0196] If it is determined in S804 that the current branch is smaller than the branch size 201 of the current node, the search control unit 131 increments the stack [stack level].branch number (S805).

[0197] Next, the search control unit 131 checks whether the current branch is -1, i.e., whether it is a serial character string position (S806). If it is determined in S806 that the current branch is -1, the search control unit 131 determines whether the serial character string of the current node is an entity (S821).

[0198] If it is determined in S821 that the serial character string of the current node is not an entity, the search control unit 131 repeats S802 and subsequent steps. If it is determined in S821 that the serial character string of the current node is an entity, the search control unit 131 adds the serial character string of the current node to the output list (S822) and repeats S802 and subsequent steps.

[0199] If it is determined in S806 that the current branch is not -1, the search control unit 131 determines whether the current branch points to a node (S807). If it is determined in S807 that the current branch does not point to a node, the search control unit 131 adds the character string of the leaf corresponding to the current branch to the output list (S823), and repeats S802 and subsequent steps.

[0200] If it is determined in S807 that the current branch points to a node, the search control unit 131 increments the stack level (S808). Next, the search control unit 131 sets the node pointed to by the current branch to stack[stack level].node, sets stack[stack level].branch number to -1 (S809), and repeats the processing from S802 onwards.

[0201] <Example of repeated acquisition processing> A specific example of the iterative acquisition process of Figures 15A and 15B will be described using Figure 16. In the example of Figure 16, similar to Figure 14, character strings 300-1 to 300-8 are registered in a data tree 111 including nodes 200-1 to 200-4. In this example, similar to Figure 14, an operation will be described in which the input character string "DG" (two characters) is searched for in the data tree 111 using a prefix search, and the set below "DG" is acquired (in ascending order) with an output list storage capacity of three.

[0202] As explained in Figure 14, before the iterative acquisition process, in S150a of the forward match search, the stack level is set to 0, the current node (node ​​200-2) is set to stack[0].node, and -1 is set to stack[0].branchnumber.

[0203] (1) First loop The search control unit 131 first clears and initializes the output list (S801). Next, in the first loop, the search control unit 131 checks the free space and stack level of the output list (S802). Since there is free space in the output list and the stack level is 0, the process continues.

[0204] Next, the search control unit 131 extracts the node (node ​​200-2) and branch number = -1 from the stack [0] with stack level = 0 that was initially set in S150a for the prefix match search, and sets them as the current node and current branch (S803).

[0205] Next, the search control unit 131 compares the current branch with the branch size 201 of the current node (S804), and because the current branch = -1 is smaller than the branch size 201 of the current node = 3, the search control unit 131 continues processing as is. Next, the search control unit 131 increments -1, which is the branch number of stack [0] with stack level = 0, to 0 (S805).

[0206] Next, the search control unit 131 checks whether the current branch is -1 (S806). In this case, since the current branch is -1, the search control unit 131 checks whether the serialized string 205="DG" of the current node (node ​​200-2) is an entity (S821). Then, since the serialized string 205 of the current node is an entity, the search control unit 131 adds the serialized string 205="DG" (string 300-2) of the current node to the output list (S822) and proceeds to the next loop.

[0207] (2) Second loop For the second loop, the search control unit 131 checks the free space and stack level of the output list (S802), and since the number of items stored in the output list is still 1, which is smaller than the storage capacity of 3, and the stack level is 0, the process continues.

[0208] Next, the search control unit 131 extracts the node (node ​​200-2) and branch number=0 from the stack [0] with stack level=0, and sets them as the current node and current branch (S803).

[0209] Next, the search control unit 131 compares the current branch with the branch size 201 of the current node (S804), and because the current branch is 0, which is smaller than the branch size 201 of the current node (=3), the search control unit 131 continues processing. Next, the search control unit 131 increments 0, which is the branch number of stack [0] with stack level=0, to 1 (S805).

[0210] Next, the search control unit 131 checks whether the current branch is -1 (S806), and since the current branch is 0, which is different from -1, the processing continues. Next, the search control unit 131 checks whether the current branch points to a node (S807), and since the 0 of the current branch points to a node, the processing continues.

[0211] Next, the search control unit 131 increments the stack level from 0 to 1 (S808). Next, the search control unit 131 sets the transition destination node information (node ​​200-3) corresponding to 0 of the current branch as the node for stack [1] with stack level=1, sets −1 as the branch number (S809), and proceeds to the next loop.

[0212] (3) Third Loop In the following, the description will be a little simplified, as many of the operations are the same as those described above. Note that the operations are performed by the search control unit 131. In the third loop, the number of items stored in the output list is still 1, which is smaller than the number of items that can be stored (3), and the stack level is 1, so the process continues (S802).

[0213] Next, the node (node ​​200-3) and branch number = -1 are extracted from stack [1] with stack level = 1, and set as the current node and current branch (S803).

[0214] Next, since the current branch is -1, which is smaller than the branch size 201 of the current node (=1), processing continues as is (S804), and then the branch number of stack [1] with stack level = 1, -1, is incremented to 0 (S805).

[0215] Next, it checks whether the current branch is -1 (S806), and since the current branch is -1, it then checks whether the serialized string 205="DGHKP" of the current node (node ​​200-3) is an entity (S821). As a result, since the serialized string 205 of the current node is an entity, it adds the serialized string 205="DGHKP" (string 300-3) of the current node to the output list (S822), and proceeds to the next loop.

[0216] (4) 4th loop In the fourth loop, the number of items stored in the output list is still 2, which is smaller than the maximum number of items that can be stored (3), and the stack level is 1, so processing continues (S802).

[0217] Next, the node (node ​​200-3) and branch number=0 are extracted from stack [1] with stack level=1, and set as the current node and current branch (S803).

[0218] Next, the current branch is compared with the branch size 201 of the current node (S804), and since the current branch is 0, which is smaller than the branch size 201 of the current node (=1), processing continues as is. Next, the branch number 0 of stack [1] with stack level = 1 is incremented to 1 (S805).

[0219] Next, it checks whether the current branch is -1 (S806), and since the current branch is 0, which is different from -1, processing continues as is. Next, it checks whether the current branch points to a node (S807), and since the 0 in the current branch points to a string, not a node, the leaf string "DGHKPS" (string 300-4) corresponding to the 0 in the current branch is added to the output list (S823), and processing moves to the next loop.

[0220] (5) 5th loop For the fifth loop, the free space in the output list and the stack level are checked (S802). Since the number of items stored in the output list is 3, which is the maximum number that can be stored, the loop is exited, the contents of the current output list (the three elements "DG", "DGHKP", and "DGHKPS") are returned (S820), and processing ends.

[0221] (6) 6th Loop As a continuation of data acquisition, the repeat acquisition is called again, and the search control unit 131 then first clears and initializes the output list (S801).

[0222] Next, in the sixth loop, the free space in the output list and the stack level are checked (S802), and since there is free space in the output list and the stack level is 1, processing continues.

[0223] Next, the node (node ​​200-3) and branch number=1 are extracted from stack [1] with stack level=1, and set as the current node and current branch (S803).

[0224] Next, the branch size 201 of the current branch is compared with that of the current node (S804). Since the current branch is 1, which is the same as the branch size 201 of the current node = 1, processing of the current node is completed, and the search control unit 131 decrements the stack level by 1 to 0 (S810) and moves to the next loop.

[0225] (7) 7th Loop In the seventh loop, the number of items stored in the output list is still 0, which is smaller than the maximum number of items that can be stored (3), and the stack level is 0, so processing continues (S802).

[0226] Next, the node (the second highest node 200-2) and branch number=1 are extracted from stack [0] with stack level=0, and set as the current node and current branch (S803).

[0227] Next, the current branch is compared with the branch size 201 of the current node (S804), and since the current branch is 1, which is smaller than the branch size 201 of the current node (=3), processing continues as is. Next, the branch number of stack [0] with stack level = 0, 1, is incremented to 2 (S805).

[0228] Next, it checks whether the current branch is -1 (S806), and since the current branch is 1, which is different from -1, processing continues as is. Next, it checks whether the current branch points to a node (S807). In this case, the 1 in the current branch points to a character string, not a node, so the leaf character string "DGK" (character string 300-5) corresponding to the current branch is added to the output list (S823), and processing moves to the next loop.

[0229] (8) 8th Loop In the eighth loop, the number of items stored in the output list is still 1, which is smaller than the maximum number of items that can be stored (3), and the stack level is 0, so processing continues (S802).

[0230] Next, the node (node ​​200-2) and branch number=2 are extracted from stack [0] with stack level=0, and set as the current node and current branch (S803).

[0231] Next, the current branch is compared with the branch size 201 of the current node (S804), and since the current branch is 2, which is smaller than the branch size 201 of the current node (=3), processing continues as is. Next, the search control unit 131 increments the branch number of stack [0] with stack level=0 from 2 to 3 (S805).

[0232] Next, it is checked whether the current branch is -1 (S806), and since the current branch is 2, which is different from -1, processing continues as is. Next, it is checked whether the current branch points to a node (S807), and since the 2 in the current branch points to a node, processing continues.

[0233] Next, the stack level of 0 is incremented to 1 (S808). Next, for stack [1] with stack level = 1, the transition destination node information (node ​​200-4) corresponding to 2 of the current branch is set as the node, and -1 is set as the branch number (S809), and the process moves to the next loop.

[0234] (9) 9th Loop In the ninth loop, the number of items stored in the output list is still 1, which is smaller than the maximum number of items that can be stored (3), and the stack level is 1, so processing continues (S802).

[0235] Next, the node (node ​​200-4) and branch number = -1 are extracted from stack [1] with stack level = 1, and set as the current node and current branch (S803).

[0236] Next, the current branch is compared with the branch size 201 of the current node (S804), and since the current branch is -1, which is smaller than the branch size 201 of the current node (2), processing continues as is. Next, the branch number -1 of stack [1] with stack level = 1 is incremented to 0 (S805).

[0237] Next, it checks whether the current branch is -1 (S806), and since the current branch is -1, it checks whether the serialized string 205 of the current node (200-4) = "DGLEBG" is an entity (S821). In this case, since the serialized string 205 of the current node is not an entity, the string is not added to the output list, and the process moves to the next loop.

[0238] (10) 10th loop In the tenth loop, there is space in the output list and the stack level is 1, so processing continues (S802).

[0239] Next, the node (node ​​200-4) and branch number=0 are extracted from stack [1] with stack level=1, and set as the current node and current branch (S803).

[0240] Next, the current branch is compared with the branch size 201 of the current node (S804), and since the current branch is 0, which is smaller than the branch size 201 of the current node (2), processing continues as is. Next, the branch number 0 of stack [1] at stack level 1 is incremented to 1 (S805).

[0241] Next, it checks whether the current branch is -1 (S806), and since the current branch is 0, which is different from -1, processing continues as is. Next, it checks whether the current branch points to a node (S807). In this case, the 0 in the current branch points to a character string, not a node, so the leaf character string "DGLEA" (character string 300-6) corresponding to the 0 in the current branch is added to the output list (S823), and processing moves to the next loop.

[0242] (11) 11th Loop In the 11th loop, the number of stored items in the output list is 2, there is still space, and the stack level is 1, so the process continues (S802).

[0243] Next, the node (node ​​200-4) and branch number=1 are extracted from stack [1] with stack level=1, and set as the current node and current branch (S803).

[0244] Next, the current branch is compared with the branch size 201 of the current node (S804), and since the current branch is 1, which is smaller than the branch size 201 of the current node (=2), processing continues as is. Next, the branch number 1 of stack [1] with stack level = 1 is incremented to 2 (S805).

[0245] Next, it checks whether the current branch is -1 (S806), and since the current branch is 1, which is different from -1, processing continues as is. Next, it checks whether the current branch points to a node (S807), and since the 1 in the current branch points to a character string, not a node, it adds the leaf character string "DGLEBG" (character string 300-7) corresponding to the 1 in the current branch (S823), and proceeds to the next loop.

[0246] (12) 12th Loop For the 12th loop, the free space in the output list and the stack level are checked (S802). Since the number of items stored in the output list is 3, which is the maximum number that can be stored, the loop is exited, the contents of the current output list (the three elements "DGK", "DGLEA", and "DGLEBG") are returned (S820), and processing ends.

[0247] (13) 13th Loop As a continuation of data acquisition, the repeat acquisition is called again, and the search control unit 131 then first clears and initializes the output list (S801).

[0248] Next, in the thirteenth loop, the free space in the output list and the stack level are checked (S802), and since there is free space in the output list and the stack level is 1, processing continues.

[0249] Next, the node (node ​​200-4) and branch number=2 are extracted from stack [1] with stack level=1, and set as the current node and current branch (S803).

[0250] Next, the current branch is compared with the branch size 201 of the current node (S804). In this case, the current branch is 2, which is the same as the branch size 201 of the current node = 2, so processing of the current node is completed, the stack level is decremented by 1 to 0 (S810), and the process moves to the next loop.

[0251] (14) 14th Loop In the 14th loop, there is space in the output list and the stack level is 0, so processing continues (S802).

[0252] Next, the node (the second highest node 200-2) and branch number=3 are extracted from stack [0] with stack level=0, and set as the current node and current branch (S803).

[0253] Next, the current branch is compared with the branch size 201 of the current node (S804). In this case, the current branch is 3, which is the same as the branch size 201 of the current node = 3, so processing of the current node is completed, the stack level is decremented from 0 to -1 (S810), and the process moves to the next loop.

[0254] (15) Final (15th) Loop In the final (15th) loop, the search control unit 131 checks the availability of the output list and the stack level (S802). In this case, there is availability of the output list, but the stack level is -1, so the loop is exited, the number of results is returned as 0 (no acquired data) (S820), and the process ends.

[0255] As described above, in the search device 100 shown in embodiment 1, a prefix search may be performed in the same way as an exact match search. Even when a prefix search is performed, variable-length character strings can be searched efficiently, as in embodiment 1. Furthermore, since the results of a prefix match, range search, or sorting may return a very large amount of data, by supporting repeated acquisition, it is possible to divide the data into any number of acquisitions and return them efficiently.

[0256] (Embodiment 3) Next, a description will be given of a third embodiment. In this embodiment, an example in which registration processing is performed in the search device 100 shown in the first or second embodiment will be described.

[0257] <Configuration of search device> Fig. 17 shows an example of the configuration of a search device 100 according to this embodiment. As shown in Fig. 17, the search device 100 further includes a registration unit 150 in addition to the configuration shown in Fig. 3. The search device 100 may be an information processing device including both the search unit 130 and the registration unit 150, or an information processing device including only one of them. For example, a registration device including only the registration unit 150 may be configured.

[0258] The registration unit 150 executes a registration process for registering a character string (registered character string) input to the input unit 120 in the data tree 111. The registration unit 150 registers the character string in the data tree 111 by setting necessary information (such as serial character string and branch information) in the nodes 200 constituting the data tree 111 or in the node 200 to be newly assigned (generated) based on the character string to be newly registered. For example, the registration unit 150 includes a registration control unit 151, a character string comparison unit 152, and a branch comparison unit 153.

[0259] The registration control unit 151 selects nodes 200 in the data tree 111 in order from the root, and controls the registration process based on the comparison result between the information of the selected node 200 and the registered character string. The registration control unit 151 controls the registration of the registered character string and the transition of the node based on the result of the serial character string comparison by the character string comparison unit 152 and the result of the branch byte string comparison by the branch comparison unit 153. The registration control unit 151 is also a selection unit (second selection unit) that selects the branch node indicated by the selected node 200 as the transition destination node (the node to be compared next) according to the result of the serial character string comparison and the result of the branch byte string comparison.

[0260] The string comparison unit (second string comparison unit) 152 performs serial string comparison processing similar to that of the string comparison unit 132 of the search unit 130. The string comparison unit 152 and the string comparison unit 132 may be a single block. The string comparison unit 152 performs serial string comparison processing to compare the serial string of the selected node 200 with a registered string. When a leaf string is selected, the string comparison unit 152 compares the leaf string with the registered string. As with the string comparison unit 132 of the search unit 130, the serial string comparison processing compares two strings using SIMD instructions and general instructions.

[0261] The branch comparison unit (second branch comparison unit) 153 performs a branch byte sequence comparison process similar to that of the branch comparison unit 133 of the search unit 130. The branch comparison unit 153 and the branch comparison unit 133 may be a single block. The branch comparison unit 153 performs a branch byte sequence comparison process that compares the branch byte of the branch byte sequence 206 of the selected node 200 with the character at the branch position 204 of the registered character string. Through the branch byte sequence comparison process, the branch comparison unit 153 identifies a branch byte (branch character) from the branch byte sequence 206 that matches the character at the branch position 204 of the registered character string. As with the branch comparison unit 133 of the search unit 130, the branch byte sequence comparison process compares the branch byte sequence 206 with the corresponding character of the registered character string using an SIMD instruction and a general instruction.

[0262] <Example of registration process> 18A and 18B show an example of the operation of the registration process in the search device 100 according to this embodiment. In the registration process of FIG. 18, each registration process is performed at the parts (S120, S133, S140, S152, S160) where the exact match search process of FIG. 4 results in a search failure. Each registration process includes the five basic operations of initial registration, leaf division, header division, serial string exchange, and branch addition, which are shown below. Other processes are the same as those of FIGS. 4A and 4B. Note that in FIGS. 18A and 18B, the input string is the string to be registered.

[0263] (1) Initial registration If it is determined in S101 that the data has not been registered, the registration control unit 151 performs initial registration (S900), and ends the process as a successful data registration (S901).

[0264] In initial registration (S900), the registration control unit 151 registers the input character string as the first leaf (character string 300) in the data tree 111. The registration control unit 151 newly registers the input character string in the registered character string 112, and sets the character string in the root node.

[0265] (2) Leaf division In S131, if it is determined that there is a difference between the leaf string and the input string from the byte check position to the end of the input string, or that the input string and the leaf string are different in size, the registration control unit 151 performs leaf division (S910), and terminates the processing by determining that the data registration was successful (S911).

[0266] In S131, if it is determined that the input string from the byte check position to the end of the input string and the leaf string are identical (are identical), and that the input string and the leaf string are the same size, the registration control unit 151 determines that the input string has been registered, returns the leaf string, and terminates the processing (S912).

[0267] In leaf division (S910), if a difference is found between the target leaf character string and the input character string, the registration control unit 151 inserts a new node 200 above the target leaf character string and divides the target leaf character string. First, the registration control unit 151 newly registers the input character string in the registered character string 112 and further assigns the new node 200. If the difference position (the position of the different character) is at the end of either the existing leaf character string or the input character string, the registration control unit 151 registers the end character string in the serial character string 205 of the new node 200 and turns on the entity flag 203. The registration control unit 151 registers the byte at the difference position of the other character string as a branch byte in the branch byte sequence 206 of the new node 200 and sets the branch size 201 to 1. The registration control unit 151 further registers the character string as a leaf in the transition destination information 207 of the new node 200.

[0268] If the difference position is an intermediate position in both the target leaf character string and the input character string, the registration control unit 151 registers one of the character strings (either is acceptable since the part before the difference is the same in both) in the serial character string 205 of the new node 200 and turns off the entity flag 203. The registration control unit 151 extracts each byte from the difference position between the target leaf character string and the input character string, registers them as branch bytes in the branch byte string 206 of the new node 200 in ascending order of unsigned numeric values, and sets the branch size 201 to 2. The registration control unit 151 registers the two corresponding character strings as leaves in the transition destination information 207 of the new node 200 in accordance with the order in which the branch bytes were registered.

[0269] (3) Header division In S106, if it is determined that there is a difference between the string of the comparison size from the byte check position in the input string and the serial string 205 of the current node (target node), the registration control unit 151 performs header division (S920), and terminates the processing by determining that the data registration was successful (S921).

[0270] In header division (S920), if a difference is found when comparing the serial string 205 of the target node 200 with the input string, the registration control unit 151 divides the serial string 205 of the target node 200 into a new node 200 and a target node 200 at the difference portion. At this time, the new node 200 is added so that the target node 200 is subordinate to the new node 200. In other words, the new node 200 is inserted above the target node 200 in the data tree 111. The registration control unit 151 newly registers the input string in the registered string 112 and further assigns the new node 200. If the difference position is at the end of the input string, the registration control unit 151 registers the input string in the serial string 205 of the new node 200 and turns ON the entity flag 203. The registration control unit 151 registers the byte at the difference position in the serial string of the target node 200 as a branch byte in the branch byte sequence 206 of the new node 200 and sets the branch size 201 to 1. The registration control unit 151 further registers the target node 200 as a node in the transition destination information 207 of the new node 200 .

[0271] If the difference position is an intermediate position in both the serial string 205 of the target node 200 and the input string, the registration control unit 151 registers one of the strings (either is acceptable since the part before the difference is the same in both) in the serial string 205 of the new node 200 and turns off the entity flag. The registration control unit 151 extracts each byte from the difference position between the serial string 205 of the target node 200 and the input string, registers them as branch bytes in the branch byte sequence 206 of the new node 200 in ascending order of unsigned numeric values, and sets the branch size 201 to 2. The registration control unit 151 registers the target node 200 and the input string as a node and leaf in the transition destination information 207 of the new node 200 in accordance with the order in which the branch bytes were registered.

[0272] (4) Serial string exchange In S150, if it is determined that the serialized string 205 of the current node (target node) references the actual string and that the size of the input string and the serialized string 205 are the same, the registration control unit 151 determines that the input string has been registered, returns the serialized string, and terminates the processing (S932).

[0273] If it is determined in S150 that the serialized string 205 of the current node does not refer to the actual string, or that the input string and the serialized string 205 are different in size, the registration control unit 151 performs serial string conversion (S930), and terminates the process by determining that the data registration was successful (S931).

[0274] In the serial string exchange (S930), the registration control unit 151 replaces the serial string 205 of the target node 200 with the input string. The registration control unit 151 newly registers the input string in the registered string 112, registers the string in the serial string 205 of the target node 200, and turns on the entity flag 203.

[0275] (5) Add a branch If it is determined in S110 that the branch byte sequence 206 of the current node (target node) does not contain the same value as the byte check position of the input string, the registration control unit 151 adds a branch (S940), considers the data registration successful, and terminates the processing (S941).

[0276] In branch addition (S940), if a byte in the input string pointed to by the branch position 204 of the target node 200 does not match any of the branch byte sequence 206 of the target node 200, the registration control unit 151 inserts a branch byte and a leaf (character string) corresponding to the input string into the target node 200. The registration control unit 151 newly registers the input string in the registered character string 112. If the branches of the target node 200 are full, the registration control unit 151 first expands the node / leaf storage areas for the branch byte sequence 206 and the transition destination information 207. The registration control unit 151 extracts a byte pointed to by the branch position 204 of the target node 200 from the input string, inserts this byte into the branch byte sequence 206 so that the branch byte sequence 206 of the target node 200 is in ascending order of unsigned numeric values, and further inserts the newly registered input string as a leaf into the transition destination information 207 corresponding to the insertion position of the branch byte. The registration control unit 151 counts up the branch size 201 of the target node 200 by one.

[0277] <Example of registration process> 18A and 18B will be described using Figures 19 to 25. Figures 19 to 25 show examples of registering character strings 300-1 to 300-7 in Figure 5 of the first embodiment in data tree 111. Note that in Figures 19 to 25, the same reference numerals as in Figure 5 are used for character strings and nodes.

[0278] (1) Initial registration (S900) Fig. 19 shows a specific example of the initial registration (S900) that is performed first. As shown in Fig. 19, in a state where no data has been registered, the character string "DGHKP" is entered.

[0279] The registration control unit 151 checks the data tree 111 (S101) and performs initial registration since no data has been registered in the initial state (S900). In this case, the registration control unit 151 newly registers the input character string "DGHKP" as character string 300-3 in the registered character string 112 and sets the character string to the root node.

[0280] (2) Leaf division (S910) Fig. 20 shows a specific example of leaf division (S910) performed after Fig. 19. As shown in Fig. 20, after the character string "DGHKP" (character string 300-3) is registered in Fig. 19, the character string "DGHKPS" is input.

[0281] The registration control unit 151 follows the data tree 111 and performs a serial string comparison between the input string "DGHKPS" and the already registered leaf string "DGHKP" (S130). As a result of the serial string comparison, the input string "DGHKPS" differs from the leaf string "DGHKP", so the registration control unit 151 performs leaf division (S910).

[0282] In this case, the registration control unit 151 newly registers the input character string "DGHKPS" as character string 300-4 in the registered character string 112, and further assigns a new node 200-3. Here, the difference position between the input character string "DGHKPS" and the leaf character string "DGHKP" is 5.

[0283] Because difference position=5 is the end of the existing leaf character string "DGHKP", the registration control unit 151 registers the existing leaf character string "DGHKP" in the serial character string 205 of the new node 200-3 and turns ON the entity flag 203. The registration control unit 151 sets difference position=5 to the branch position 204 of the new node 200-3, registers the byte "S" at difference position=5 in the input character string "DGHKPS" as a branch byte in the branch byte string 206 of the new node 200-3, and sets 1 to the branch size 201 of the new node 200-3.

[0284] The registration control unit 151 registers the newly registered input character string "DGHKPS" (character string 300-4) as a leaf in the transition destination information 207 of the new node 200-3.

[0285] (3) Header division (S920) Fig. 21 shows a specific example of header division (S920) performed after Fig. 20. As shown in Fig. 21, after the character string "DGHKPS" (character string 300-4) is registered in Fig. 20, the character string "DGLEBG" is input.

[0286] The registration control unit 151 follows the data tree 111 and performs a serial string comparison between the input string "DGLEBG" and "DGHKP"", which is the serial string 205 of node 200-3 (S105). As a result of the serial string comparison, the input string "DGLEBG" differs from "DGHKP", which is the serial string 205 of node 200-3, in the middle position, so the registration control unit 151 performs header division (S920).

[0287] In this case, the registration control unit 151 newly registers the input character string "DGLEBG" as a character string 300-7 in the registered character string 112, and further assigns a new node 200-2. Here, the difference position between the input character string "DGLEBG" and the serial character string "DGHKP" is 2.

[0288] Because difference position=2 is the middle position in both the serial string 205 of the target node 200-3 and the input string, the registration control unit 151 registers one of the strings (in this example, "DGHKP," which is the serial string 205 of the existing node 200-3) in the serial string 205 of the new node 200-2 and turns OFF the entity flag 203. The registration control unit 151 extracts each byte ("H," "L") at difference position=2 from "DGHKP," which is the serial string 205 of the existing node 200-3, and the input string "DGLEBG," registers them as branch bytes in the branch byte string 206 of the new node 200-2 in ascending order of unsigned numeric values ​​(in the order "H," "L"), and sets the branch size 201 of the new node 200-2 to 2.

[0289] The registration control unit 151 registers the node information of the existing node 200-3 and the newly registered input character string "DGLEBG" (character string 300-7) in the transition destination information 207 of the new node 200-2 in accordance with the order of branch byte registration.

[0290] (4) Serial string exchange (S930) Fig. 22 shows a specific example of serial character string exchange (S930) that is performed after Fig. 21. As shown in Fig. 22, after the character string "DGLEBG" (character string 300-7) is registered in Fig. 21, the character string "DG" is input.

[0291] The registration control unit 151 follows the data tree 111 and performs a serial string comparison between the input string "DG" and "DG"", the serial string 205 of node 200-2 (S105). As a result of the serial string comparison, the input string "DG" matches "DG", the serial string 205 of node 200-2, in both content and length, and the entity flag 203 of node 200-2 is OFF, so the registration control unit 151 performs a serial string exchange (S930).

[0292] In this case, the registration control unit 151 newly registers the input character string "DG" as character string 300-2 in the registered character string 112. The registration control unit 151 registers (overwrites) the newly registered input character string "DG" (character string 300-2) in the serial character string 205 of the target node 200-2 and turns on the entity flag 203.

[0293] (5) Add branch (S940) Fig. 23 shows a specific example of branch addition (S940) performed after Fig. 22. As shown in Fig. 23, after the character string "DG" (character string 300-2) is registered in Fig. 22, the character string "DGK" is input.

[0294] The registration control unit 151 follows the data tree 111 and performs a serial string comparison between the input character string "DGK" and "DG"", which is the serial string 205 of node 200-2 (S105). As a result of the serial string comparison, the input character string "DGK" is no different from "DG", which is the serial string 205 of node 200-2, so the registration control unit 151 performs a branch byte string comparison between the branch byte string 206 of node 200-2 and the branch byte of the input character string "DGK" (S109). As a result of the branch byte string comparison, the branch byte "K" at branch position = 2 of the input character string "DGK" is not present in the branch byte string 206 ("H", "L") of node 200-2, so the registration control unit 151 adds a branch (S940).

[0295] In this case, registration control unit 151 newly registers input character string "DGK" as character string 300-5 in registered character string 112. Because there is room (4-2=2) in branch byte sequence 206 of target node 200-2, registration control unit 151 does not expand the node / leaf storage area of ​​branch byte sequence 206 and transition destination information 207 (expanding in the order of 4, 8, 16, 32, 256).

[0296] The registration control unit 151 extracts the byte "K" pointed to by branch position=2 of the target node 200-2 from the input character string "DGK", inserts this "K"' into the branch byte string 206 of the target node 200-2 so that the branch byte string 206 is in ascending order of unsigned numeric values, and further registers the newly registered input character string "DGK" (character string 300-5) as a leaf in the transition destination information 207 corresponding to the insertion position of the branch byte. The registration control unit 151 counts up the branch size 201 of the target node 200-2 by 1 to make it 3.

[0297] (6) Leaf division (S910) Fig. 24 shows a specific example of leaf division (S910) performed after Fig. 23. As shown in Fig. 24, after the character string "DGK" (character string 300-5) is registered in Fig. 23, the character string "DGLEA" is input.

[0298] The registration control unit 151 follows the data tree 111 and performs a serial string comparison between the input string "DGLEA" and the already registered leaf string "DGLEBG" (S130). As a result of the serial string comparison, the input string "DGLEA" differs from the already registered leaf string "DGLEBG", so the registration control unit 151 performs leaf division (S910).

[0299] In this case, the registration control unit 151 newly registers the input character string "DGLEA" as a character string 300-6 in the registered character string 112, and further assigns a new node 200-4. Here, the difference position between the input character string "DGLEA" and the existing leaf character string "DGLEBG" is 4.

[0300] Because difference position=4 is the middle position in both the existing leaf character string "DGLEBG" and the input character string "DGLEA," the registration control unit 151 registers one of the character strings (in this example, the existing leaf character string "DGLEBG") in the serial character string 205 of the new node 200-4 and turns OFF the entity flag 203. The registration control unit 151 sets difference position=4 to the branch position 204 of the new node 200-4, extracts each byte ("B", "A") at difference position=4 from the existing leaf character string "DGLEBG" and the input character string "DGLEA," registers them in the branch byte string 206 of the new node 200-4 in ascending order of unsigned numeric values ​​(in the order "A", "B"), and sets the branch size 201 of the new node 200-4 to 2.

[0301] The registration control unit 151 registers the newly registered input character string "DGLEA" (character string 300-6) and the existing leaf character string "DGLEBG" (character string 300-7) in the transition destination information 207 of the new node 200-4 in accordance with the order of branch byte registration.

[0302] (7) Header division (S920) Fig. 25 shows a specific example of header division (S920) performed after Fig. 24. As shown in Fig. 25, after the character string "DGLEA" (character string 300-6) is registered in Fig. 24, the character string "DBXPN" is input.

[0303] The registration control unit 151 follows the data tree 111 and performs a serial string comparison between the input string "DBXPN" and "DG"", which is the serial string 205 of node 200-2 (S105). As a result of the serial string comparison, the input string "DBXPN" differs from "DG", which is the serial string 205 of node 200-2, in the middle position, so the registration control unit 151 performs header division (S920).

[0304] In this case, the registration control unit 151 newly registers the input character string "DBXPN" as character string 300-1 in the registered character string 112, and further assigns a new node 200-1. Here, the difference position between the input character string "DBXPN" and the serial character string "DG" is 1.

[0305] Because difference position=1 is in the middle position in both the serial string 205 of the target node 200-2 and the input string, the registration control unit 151 registers one of the strings (in this example, the newly registered input string “DBXPN”) in the serial string 205 of the new node 200-1 and turns OFF the entity flag 203. The registration control unit 151 extracts each byte (“G”, “B”) at difference position=1 from “DG”, which is the serial string 205 of the existing node 200-2, and the input string “DBXPN”, registers them as branch bytes in the branch byte string 206 of the new node 200-1 in ascending order of unsigned numeric values ​​(“B”, “G”), and sets the branch size 201 of the new node 200-1 to 2.

[0306] The registration control unit 151 registers the newly registered input character string "DBXPN" (character string 300-1) and the node information of the existing node 200-2 in the transition destination information 207 of the new node 200-1 in accordance with the order of registration of the branch bytes.

[0307] As described above, the registration process may be performed in the search device 100 shown in the first or second embodiment. The registration process can be realized by using SIMD instructions to perform serial string comparison and branch byte string comparison, just like the exact match search. Therefore, just like the first embodiment, variable-length character strings can be registered efficiently.

[0308] (Fourth embodiment) Next, a fourth embodiment will be described. In this embodiment, an example will be described in which, in the search device 100 shown in the first to third embodiments, numeric data is converted when data is stored, and an integrated multi-key is used. The configuration of the search device 100 is the same as in the first to third embodiments.

[0309] Generally, comparison of character strings and comparison of numeric values ​​require different comparison operations depending on the data type. In contrast, in this embodiment, numerical data such as fixed-point and floating-point numbers are also converted and stored as described below, eliminating the overhead of switching internal operations depending on the data type and enabling efficient processing using the same unified operations as for character strings.

[0310] The table in Fig. 26 shows an example of conversion rules for storing numeric data according to this embodiment. For example, when retrieval device 100 registers numeric data in data tree 111 and stores it in database 110, it converts the numeric data in accordance with the conversion rules in Fig. 26 and stores the converted data in registered character string 112. Note that the storage location may be a separate storage location from registered character string 112, and the data may be stored therein.

[0311] In the example of Figure 26, a conversion condition, a data conversion method, and an endian conversion target are associated with each data type of target data. The retrieval device 100 determines the data type of the target data and converts the target data using a data conversion method corresponding to the data type. In the case of a data type (floating-point type) for which a conversion condition is defined, the retrieval device 100 determines the conversion condition in accordance with the target data and converts the target data using a data conversion method corresponding to the determined result. Furthermore, the retrieval device 100 performs endian conversion on each byte of the target data converted using the data conversion method, and stores the data after endian conversion.

[0312] Note that Figure 26 shows an example for the little-endian architecture, and endian conversion is not necessary for the big-endian architecture. The conversion in Figure 26 is completely reversible, and the original value can be easily restored by performing the reverse operation.

[0313] The data conversion rules for numbers in Figure 26 depend on the characteristics of the magnitude relationship when comparing numbers in each data type. In other words, strings are basically a collection of byte codes, and the magnitude relationship is handled by treating the byte sequence as an array in lexicographical order. This magnitude relationship is the same as when unsigned fixed-point numbers are arranged in order from the most significant digit. On the other hand, numbers come in different internal formats, such as fixed-point and floating-point. Fixed-point numbers come in signed and unsigned types, and floating-point numbers also have the concept of positive and negative signs.

[0314] <Conversion principle of signed integer values> Figure 27 shows the magnitude relationship of the comparison results of unsigned integer values, and Figure 28 shows the magnitude relationship of the comparison results of signed integer values. Comparing Figure 27 and Figure 28, the magnitude relationship of the comparison results differs in the parts enclosed in bold frames, but is the same in other parts. Therefore, it can be seen that the following method is effective in changing the comparison of signed integers to the comparison of unsigned integers. · No change to equality comparisons. When comparing greater than or less than, the comparison result is inverted where the first bit of the comparison values ​​differ.

[0315] From this result, in the case of signed fixed-point values, by "inverting the leading bit of the data, converting it to an unsigned fixed-point value, and storing it," it is possible to unify the processing to unsigned fixed-point comparison, the same as for strings. For example, as shown in Figure 26, if the target data is of signed int8 type, the leading bit is inverted by performing an xor operation with 0x80 on the target data.

[0316] <Floating-point number conversion principle> Figure 29 shows the format of a floating-point number (IEEE754 format). As shown in Figure 29, a floating-point number (IEEE754 format) consists of a sign bit (sign), an exponent (exponent), and a fraction (fraction), so at first glance it does not seem applicable to unsigned fixed-point comparisons. However, upon careful observation, it becomes clear that the arrangement of the bits other than the sign bit is designed so that numbers with higher-order bits set are larger than numbers with no bits set.

[0317] Furthermore, the comparison result of floating-point numbers depends on the value of the leading sign bit: · 0,0: Comparison when both sign bits are 0 (positive) is the same as comparing an unsigned int. · 0,1: When comparing numbers with different sign bits, the number with a sign bit of 0 (positive) is larger. · 1,1: When both sign bits are 1 (negative), the comparison is the same as the inverted result of an unsigned int (for negative values, the smaller the absolute value, the greater the value).

[0318] From this result, in the case of floating-point values, by storing them as follows, it is possible to unify them into unsigned fixed-point comparisons and process them. If the sign bit is 0, only the leading sign bit is inverted before storing. If the sign bit is 1, all bits, including the leading sign bit, are inverted and stored.

[0319] For example, as shown in Figure 26, if the target data is a float (32-bit) type, the target data is masked with 0x80000000 to determine the first bit, and if the first bit is ON, all bits are inverted by performing a not operation on the target data, and if the first bit is OFF, the first bit is inverted by performing an xor operation on the target data with 0x80000000.

[0320] <Endian (byte order) conversion principle> The data handled by computers comes in various types, such as strings, fixed-point numbers, and floating-point numbers, but when these types of data are handled by a computer, their handling is affected by endianness (byte order), a type of hardware architecture.

[0321] Figure 30 shows an example of memory layout when storing strings and numbers in Big-Endian and Little-Endian architectures. For example, when the string "ABCDEF" and the 4-byte number 12345678 (Hex) are stored in Big-Endian and Little-Endian architectures, as shown in Figure 30, the actual layout in memory is the same for the string, but the order of the upper and lower bytes of the number is reversed.

[0322] Therefore, in Little-Endian architectures, when numbers consist of multiple bytes, the most significant and least significant bytes are stored in reverse order, making it the same as the comparison order for strings. When communicating using TCP / IP and other protocols, the byte order must conform to the standard rule (Big-Endian). For this reason, CPUs generally have instructions to support this conversion, and high-speed conversion is possible using instructions such as the BSWAP instruction in X86 and the REV instruction in Arm. As shown in Figure 26, when the target data is a 16-bit to 64-bit number, these endian conversion instructions are used to convert the target data.

[0323] <Example of integrated multi-key configuration> Generally, when searching or comparing the size of a multi-key that combines multiple data, the process is performed by comparing each key in order, starting from the first key, and if the keys are identical, comparing the next key.

[0324] However, this method repeats key comparisons and judgments, so when checking whether all keys in a multi-key are the same, the comparison and judgment operations must be performed as many times as the number of keys that make up the multi-key, which is inefficient. Also, even when comparing magnitudes, the number of key comparisons increases as the difference occurs in later keys.

[0325] In contrast, in the multi-key support of this embodiment, a single initial conversion enables unified processing of all data types as unsigned byte strings, the same as character strings. That is, the numeric data is converted and stored in advance as described above. This allows the search device 100 to efficiently perform comparison processing without being aware of key boundaries of multi-keys when performing the serial character string comparison or branch byte string comparison shown in the first embodiment.

[0326] FIG. 31 shows an example of the configuration of a multi-key. In the example of FIG. 31, the multi-key is 32 bytes long and contains five keys. When comparing the multi-keys of FIG. 31, it is generally necessary to compare the keys included in the multi-key element by element, starting from the beginning, as shown in FIG. 32. For example, if character strings are compared byte by byte, the number of comparisons will be 18. In contrast, in this embodiment, as shown in FIG. 33, it is possible to compare 32 bytes of the multi-key all at once. For example, in the search device 100, for a multi-key with a total size of 32 bytes, processing can be performed with one comparison and determination operation in the case of 256-bit processing using SIMD, or two comparison and determination operations in the case of 128 bits.

[0327] As shown in the numeric data conversion above, the effect of the conversion during storage is to make it possible to perform unified comparison operations using unsigned fixed-point comparisons while still maintaining the magnitude relationship of the original data. Therefore, the magnitude relationship of multiple keys can be obtained by simply comparing the values ​​of the first byte position where a difference occurs, without worrying about key boundaries.

[0328] Furthermore, the processing of stored data involves only logical operations and byte order changes, and the data position and size remain unchanged. Therefore, even if a key has a discrepancy, it can be easily identified by simply comparing the difference position with the original key position (offset position).

[0329] As described above, when storing data in the search device 100 shown in the first to third embodiments, the data may be converted using the conversion rules shown in Fig. 26. In this way, by performing simple data conversion and storing fixed-point or floating-point data, it becomes possible to perform a search using logic for unsigned byte strings similar to character strings.

[0330] Furthermore, since it is possible to search for both character strings and numeric data in the same way, it is also possible to process multi-key data consisting of heterogeneous data, such as character strings, fixed-point numbers, and floating-point numbers, concatenated in any order, all at once, enabling efficient searches.

[0331] The present invention is not limited to the above-described embodiment, and can be modified as appropriate within the scope of the invention.

[0332] Each component in the above-described embodiments may be configured by hardware or software, or both, and may be configured by a single piece of hardware or software, or may be configured by multiple pieces of hardware or software. The functions (processing) of each device may be realized by a computer having a CPU, memory, etc. For example, a program for performing the method in the embodiment may be stored in a storage device, and each function may be realized by executing the program stored in the storage device with a CPU.

[0333] These programs include instructions (or software code) that, when loaded into a computer, cause the computer to perform one or more functions described in the embodiments. The programs may be stored on a non-transitory computer-readable medium or a tangible storage medium. By way of example and not limitation, computer-readable media or tangible storage media include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technology, CD-ROM, digital versatile disc (DVD), Blu-ray® disc or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device. The programs may also be transmitted on a transitory computer-readable medium or communication medium. By way of example and not limitation, transitory computer-readable media or communication media include electrical, optical, acoustic, or other forms of propagated signals. [Explanation of symbols]

[0334] 100 Search Device 110 databases 111 Data Tree 112 Registration String 120 Input section 130 Search Department 131 Search control section 132 String Comparison 133 Branch Comparison Unit 140 Output section 150 Registration Department 151 Registration control section 152 String Comparison 153 Branch Comparison Unit 200 nodes 201 branch size 202 alloc size 203 Entity Flag 204 Branch Location 205 Serial String 206 Branch Byte Sequence 207 Migration Advance Information 300 text columns

Claims

1. a storage unit for storing a variable-length registered character string and a data tree composed of a plurality of nodes, each of which includes serial character string information indicating at least a part of the registered character string and branch information relating to a transition destination below the node; a search unit that searches for the registered character string that includes a search character string based on the serial character string information and the branch information of the node; Equipped with The serialized character string information holds the entity of the registered character string when there is a registered character string whose end matches the character string indicated by the serialized character string information, and when there is no registered character string whose end matches the character string indicated by the serialized character string information, it makes a shared reference to the registered character string of the transition destination indicated by the branch information of the node. Search device.

2. The node includes an entity flag indicating whether the serialized string information has an entity. The search device according to claim 1 .

3. the search unit performs the search based on a comparison result between the string indicated by the serialized string information included in the node and the search string, and based on the entity flag included in the node. The search device according to claim 2 .

4. the search unit compares the string indicated by the serial string information included in the node with the search string in units of data that can be processed in parallel; The search device according to any one of claims 1 to 3.

5. the search unit compares a character string indicated by the serialized character string information included in the node with the search character string using a single instruction / multiple data (SIMD) command; The search device according to claim 4.

6. the branch information includes a plurality of branch characters following the character string indicated by the serial character string information, and transition destination information corresponding to each of the plurality of branch characters; The search device according to any one of claims 1 to 3.

7. The transition destination information is stored consecutively after the plurality of branch characters. The search device according to claim 6.

8. the search unit compares the plurality of branch characters included in the node with a character corresponding to a position of the branch character in the search string in units of data that can be processed in parallel; The search device according to claim 6.

9. the search unit compares the plurality of branch characters included in the node with a character corresponding to a position of the branch character in the search string using an SIMD instruction; The search device according to claim 8.

10. a registration unit that assigns the node based on the newly registered registration character string and sets the serialized character string information and the branch information in the assigned node; The search device according to any one of claims 1 to 3.

11. the registration unit compares, in units of data that can be processed in parallel, a character string indicated by the serial character string information included in the node that configures the data tree with the registered character string to be newly registered; The search device according to claim 10.

12. the registration unit compares, using a SIMD instruction, a character string indicated by the serialized character string information included in the node constituting the data tree with the newly registered character string; The search device according to claim 11.

13. the registered character string includes numeric data, the registration unit inverts a leading bit of a signed fixed-point number included in the numeric data to convert it into an unsigned fixed-point number, and stores the converted number in the storage unit. The search device according to claim 10.

14. the registered character string includes numeric data, the registration unit inverts the sign bit of the floating-point value included in the numeric data when the sign bit is 0 and stores the inverted numeric value in the storage unit, and inverts all bits when the sign bit of the floating-point value is 1 and stores the inverted numeric value in the storage unit. The search device according to claim 10.

15. The registered character string is a composite key that combines a variable-length character string and the numeric data. The search device according to claim 13.

16. the registration unit converts data in little endian format included in the registered character string into data in big endian format, and stores the converted data in the storage unit. The search device according to claim 10.

17. A data tree is stored that includes a variable-length registered character string and a plurality of nodes, each of which includes serial character string information indicating at least a part of the registered character string and branch information relating to a transition destination below the node; searching for the registered character string that includes a search character string based on the serial character string information and the branch information of the node; The serialized character string information holds the entity of the registered character string when there is a registered character string whose end matches the character string indicated by the serialized character string information, and when there is no registered character string whose end matches the character string indicated by the serialized character string information, it makes a shared reference to the registered character string of the transition destination indicated by the branch information of the node. How to search.

18. A data tree is stored that includes a variable-length registered character string and a plurality of nodes, each of which includes serial character string information indicating at least a part of the registered character string and branch information relating to a transition destination below the node; searching for the registered character string that includes a search character string based on the serial character string information and the branch information of the node; The serialized character string information holds the entity of the registered character string when there is a registered character string whose end matches the character string indicated by the serialized character string information, and when there is no registered character string whose end matches the character string indicated by the serialized character string information, it makes a shared reference to the registered character string of the transition destination indicated by the branch information of the node. A program that causes a computer to execute a process.

Images