JP5639011B2 - Data storage device, data storage method, and program - Google Patents

Description

  The present invention relates to a data storage device that stores data in a secondary storage device, a data storage method, and a program thereof.

  In the method for accumulating data in the secondary storage device, data obtained by combining several pieces of information called records is handled as a minimum unit for storing data. Further, there is a physical block as a minimum access unit to the secondary storage device, and a block that can be virtually handled on the system is called a logical block. A file is composed of a plurality of logical blocks, and the logical block often includes a plurality of records.

  An index is used to efficiently search for a specific record. An index can be created for any attribute value a record has. At this time, the value of an arbitrary attribute that creates this index is called a key value. Among the indexing methods, there are a dense index and a sparse index as methods for performing a range search (see, for example, Non-Patent Document 1). The dense index does not depend on the data input order, but creates an index for all the input records. On the other hand, in the sparse index, an index is created only for some of the input records using the data input order. For records for which no index is created, a search is performed on the assumption that the input order is sorted by key value. Therefore, the sparse index is a method that can be used only when the data input order is sorted with respect to the key value.

  On the other hand, when a large amount of time-series sensor data collected through the sensor network is to be stored in the secondary storage device in real time in a form in which a range search is possible using the time as a key value, high speed data writing is required. When using a dense index among the conventional indexing methods, it is necessary to create an index for each input record. Therefore, the cost of writing data is higher than that of the sparce index, and the data writing speed catches up with the generation of data. There is no fear. On the other hand, in order to use the sparse index, it is necessary to input the input data in a state where the key values (in this case, time) are sorted. However, it is conceivable that a large amount of time-series data collected through the sensor network does not have a constant time data input order according to the time and is reversed due to a network delay or disconnection of the data source side such as a sensor. For this reason, if the time is a key value, the data is roughly aligned according to the key value, but cannot be used with a sparse index because the data is partially reversed in order due to delay.

  In order to deal with this problem, a method has been proposed in which data representing the storage position of data whose order has been reversed by a bitmap called new offset data is added to sparse index to cope with the data order reversal (for example, non-patent literature). 2). In this method, a bit map is used and the bit of the bit number corresponding to the offset number is set to 1. By expressing the offset number, the position of the delayed data is indicated, and high-speed indexing and order reversal data are converted. It is compatible.

Abraham Silverschatz, Henry F. Korth, S.H. Sudarshan, “Database System Concepts Fifth Edition”, pp. 483-485, McGraw-Hill (2006). T. T. et al. Yamazaki, T .; Inoue, H.M. Sato, N .; Takahashi, J. et al. Takagi, M .; Minami, “Efficiently indexing with offset bitmaps for huge sets of lightly disordered sensor data”, APSITT 2010, 2010. H. Williams and J.M. Zobel, “Compressing integers for fast file access”, Computer Journal, 42 (3): 193-201, 1999. Vo Ngoc Anh, Alistair Moffat: “Inverted Index Compression using Word-Aligned Binary Codes”, Information Retrieval, 8 (1): 151-166, 2005.

  In the conventional method of dealing with data reversal at high speed, a method is used in which the number of offsets is expressed by using a bit map and setting the bit of the bit number corresponding to the number of offsets to 1. However, in this case, it is possible to efficiently express the small delay that occurs continuously, but for the sudden large delay that occurs due to disconnection on the data source side such as a sensor, it is the same as the number of offsets. A large number of bits, the number of bits, is required, and there is a problem that the space efficiency is poor.

  Therefore, in order to solve the above-described problem, the present invention maintains a speed close to that of a sequentially written file even when the data order is reversed to some extent when the data is stored in the secondary storage device. It is possible to search exactly by key value, to efficiently read data by range search, and even if the data order is greatly reversed due to sudden large delay, this can be expressed efficiently in space An object of the present invention is to provide a data storage device, a data storage method, and a program capable of realizing a data structure.

  In order to solve the above-mentioned problem, the present invention performs indexing by a sparse index using a specific value of a record as a key value, and a record of a key value included in a range of key values that one logical block handles is another logical block. In this case, offset data obtained by compressing the number of offsets from one logical block to another logical block as a bit string is recorded in the secondary storage device as an offset file.

  Specifically, the data storage device according to the present invention includes a secondary storage device that sequentially stores data continuously input with a record as a minimum unit, and a specific value of the record as a key. When indexing with a sparse index as a value and the record having the key value included in the range of the key value that one logical block handles is in another logical block, the one logical block System control means for causing the secondary storage device to record the offset data compressed by expressing the number of offsets to the other logical block as a bit string as an offset file.

  Specifically, in the data storage method according to the present invention, when data that is continuously input with a record as a minimum unit is sequentially stored in a secondary storage device with a logical block as a unit, a specific value of the record is stored. Is indexed using a sparse index as a key value, and if the record having the key value included in the range of key values that one logical block handles is in another logical block, the one A system control procedure is performed for causing the secondary storage device to record offset data compressed by expressing the number of offsets from the logical block to the other logical block as a bit string.

  Since the data storage device and the data storage method according to the present invention combine sparse index and offset data, it is possible to search for data whose order has been reversed. Furthermore, by compressing the offset data, it is possible to more efficiently represent a sudden large delay due to the disconnection of the network.

  Therefore, according to the present invention, when data is stored in the secondary storage device, it is possible to maintain a speed close to that of a sequentially written file even if the order of data is reversed to some extent for key values. Data storage device that can perform exact match search, can efficiently read data by range search, and can realize a data structure that can express this even if the data order is greatly reversed due to a sudden large delay And a data storage method can be provided.

  There are the following three methods for compressing the offset data.

(1) Run Length Compression Run Length compression is a technique in which when a certain value appears continuously for a certain number or more, it represents the number of consecutive bits instead of expressing it as it is.

  The system control means of the data storage apparatus comprises the offset data as a code length storage unit, a compression count storage unit, a compression position and compression bit number storage unit, and a code unit, and in the code unit, the offset number If the bit string of the bit part of the code part includes a continuous bit part in which the bit string of the code part includes the same bit more than a preset threshold value, the number of bits of the continuous bit part is counted up, Record the start position of the continuous bit part and the number of bits of the continuous bit part in the compressed position and the compressed bit number storage part, and delete the other bits of the continuous bit part, leaving the first bit of the continuous bit part An offset compression unit is provided.

  The system control procedure of the data storage method includes the offset data including a code length storage unit, a compression count storage unit, a compression position and compression bit number storage unit, and a code unit, and the code unit includes the offset number. If the bit string of the bit part of the code part includes a continuous bit part in which the bit string of the code part includes the same bit more than a preset threshold value, the number of bits of the continuous bit part is counted up, Record the start position of the continuous bit part and the number of bits of the continuous bit part in the compressed position and the compressed bit number storage part, and delete the other bits of the continuous bit part, leaving the first bit of the continuous bit part It is characterized by doing.

  In this compression method, when applied to an offset expression method using a bitmap, a code length storage unit, a compression count storage unit, a compression position and compression bit number storage unit, and a code unit are prepared as the offset data structure.

  At this time, the code part expresses the number of offsets by setting the bit having the bit number equal to the number of offsets to 1 by using a bitmap in the same manner as in the proposed method, but the bit of 0 or 1 is predetermined. If more than a certain number of consecutive, this is compressed into Run Length. At this time, in the compression, it is necessary to express the position of the compressed bit and the number of consecutive bits, which are stored in the compressed position and compressed bit number storage unit. This compression position and compression bit number storage unit prepares for each number of times the Run Length compression has been performed. The number of times this compression is performed is stored in the compression number storage unit. The size of the bitmap stored in the code part is stored in the code length storage part.

  By using this data structure, it is possible to perform more efficient offset expression by performing this when the Run Length compression is possible while performing the expression by the bitmap. In addition, since the compression position and the number of compression bits are separated from the code part, a new offset can be added without referring to the code part to decode all offsets, enabling efficient offset addition processing. It becomes.

(2) Simple9
4 bytes (32 bits) are handled as one code, and as many integer values as possible are packed into one code, the number of bits to be used is 1 to 28 bits according to the size of the integer value. (For example, refer nonpatent literature 4).

  When the record having the key value included in the range of the key value handled by one logical block is in a plurality of other logical blocks, the system control unit of the data storage device starts from the one logical block. The number of offsets to each of a plurality of other logical blocks is obtained, and the difference in the number of offsets from the obtained number of offsets to each logical block is determined for the logical blocks having the closest block position among the plurality of other logical blocks. The offset data is composed of a header part and a code part, and the code part includes the single offset number or a plurality of differential offset numbers as the offset number or the differential offset number. Offset bit string expressed by the number of bits according to the offset, and the offset A code header having a fixed number of bits describing the number of bits of a code string, and an offset compression unit for displaying the number of codes and the number of offsets in the header unit Features.

  When the record having the key value included in the range of the key value handled by one logical block is in a plurality of other logical blocks, the system control procedure of the present data storage method starts from the one logical block. The number of offsets to each of a plurality of other logical blocks is obtained, and the difference in the number of offsets from the obtained number of offsets to each logical block is determined for the logical blocks having the closest block position among the plurality of other logical blocks. The offset data is composed of a header part and a code part, and the code part includes the single offset number or a plurality of differential offset numbers as the offset number or the differential offset number. Offset bit string expressed by the number of bits according to the offset, and the offset Stores Tsu preparative column fixed number of bits of the code header that describes the number of bits of, in the code to be formed, in the header portion, and displaying the number and the number of the offset number of the code.

  When applying this compression method to offset data, a header part and a code part are prepared as the structure of the offset data. At this time, the code part stores an integer value sequence compressed by Simple9, and the header part stores the number of integer values compressed by Simple9 and the number of codes of Simple9. By using this data structure, when the code of Simple 9 is expanded, the processing of extra data is suppressed by using the data of this header portion, and efficient processing becomes possible.

(3) Variable Byte Code
In this method, an integer value represented by 4 bytes is usually changed to 1 to 4 bytes according to the size of the integer value (see Non-Patent Document 3, for example).

  The system control means of the data storage device comprises a plurality of bytes of the offset data, and when the offset number is expressed by the number of bytes corresponding to the offset number, a fixed number of each byte expressing the offset number It is characterized by having an offset compression section that uses a number of bits as a header and displays the number of bytes expressing the number of offsets in the header.

  The system control procedure of the data storage method is configured such that when the offset data is composed of a plurality of bytes and the offset number is expressed by the number of bytes corresponding to the offset number, each byte expressing the offset number is fixed. The number of bits is used as a header, and the number of bytes expressing the number of offsets is displayed in the header.

  A program according to the present invention causes a computer to execute the system control procedure of the data storage method.

  In the present invention, when data is stored in the secondary storage device, it is possible to maintain a speed close to that of a sequentially written file even if the order of data is reversed to some extent for key values. Data storage device and data that can be searched, data can be efficiently read by range search, and even if the data order is greatly reversed due to an unexpectedly large delay An accumulation method and a program can be provided.

It is a figure explaining the structure of the data storage apparatus which concerns on this invention. It is a figure explaining the data structure of the data storage apparatus which concerns on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining the data structure of the data storage apparatus which concerns on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining the data structure of the data storage apparatus which concerns on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining operation | movement of the data storage apparatus based on this invention. It is a figure explaining the effect of the data storage device concerning the present invention. It is a figure explaining the effect of the data storage device concerning the present invention. It is a figure explaining the effect of the data storage device concerning the present invention. It is a figure explaining the effect of the data storage device concerning the present invention.

  Hereinafter, the present invention will be described in detail with specific embodiments, but the present invention is not construed as being limited to the following description. In the present specification and drawings, the same reference numerals denote the same components.

(Embodiment 1)
The first embodiment uses a variable byte code for expressing the number of offsets.

  FIG. 1 is a diagram illustrating the configuration of the data storage device 10 according to the first embodiment. The data storage device 10 includes a system control unit 300, an interface 110, a buffer memory 120, and a secondary storage device 330. The interface 110 exchanges data with the buffer memory 120, and the buffer memory 120 exchanges data with the interface 110 and the secondary storage device 330, respectively. The system control unit 300 analyzes whether the input data of the interface 110 is a write request or a read request. The system control unit 300 performs memory management for buffering input / output data in the buffer memory 120. The system control unit 300 performs file operations such as data writing to a file in data input with respect to the secondary storage device. There are three files in the secondary storage device: an index file 331, a data file 332, and an offset file 333.

  FIG. 2 is a diagram for explaining the data structure of the data storage device 10. Each logical block of the data file 332 is composed of input records.

  The offset data that is each record in the offset file 333 is fixed-length W-bit data. Each offset data has a one-to-one correspondence with each logical block of the data file using the position on the file. The offset data is composed only of a code portion that stores a compressed offset numerical value sequence. The compression of the offset numerical value sequence is performed using Variable Byte Code.

  3 and 4 are flowcharts showing data addition processing in the data storage device 10.

  In the data addition process, first, the input record is accumulated in the buffer memory (step S701). The input record is continuously accumulated in the buffer memory until the input record is accumulated for the logical block size (step S702).

  If the input records are accumulated in the buffer memory by the logical block size, the records in the buffer memory are sorted in ascending order with respect to the key values (step S703). After that, the records in the buffer memory are written for the logical block at the end of the data file (step S704). This written logical block is designated as B1. Further, a bit string with all bits set to 0 is written in the offset file as an initial value of the offset data (step S705).

  Next, the index file is referred to find the maximum key value in the index file, and the value is temporarily stored as the lower limit value L of the key value handled by the logical block B1 that has just written (step S706). Thereafter, an index is created for the last record having the largest key value in the written logical block, and the index file is updated (step S707).

  Further, the record in the buffer memory is referred to (step S708), and the record in which the key value of the record becomes the lower limit value L or less is searched in order from the first record (step S709). If the referenced record is larger than the lower limit value L, the search ends there and the writing process ends. If the referenced record is less than or equal to the lower limit value L, the index file is examined to find a key value that is equal to or greater than the key value (step S710). Here, if B2 which is the logical block pointed to by the searched key value has already been updated (step S711), the update processing of the logical block B2 is canceled, and if there is a next record on the buffer memory, the next record The same processing is performed with reference to (Step S720, Step S721). If not, the search is terminated and the writing process is terminated. If the logical block B2 indicated by the searched key value has not been updated, the logical block B2 is read (steps S712 and S713).

  Next, the block positions of the read logical block B2 and the written logical block B1 are compared to calculate how many logical blocks are separated, and this is set as an offset X (step S714). With the offset X and offset data corresponding to the logical block B2 as inputs (step S715), an “offset data update” process is performed (step S716). Although this processing will be described later, offset data updated by adding the offset X to the offset data can be obtained. The original offset data is updated with the updated offset data, and the offset file is updated (step S719).

  If there is a next record on the buffer memory, it is referred to and the same processing is performed (step S720, step S721). If there is no next record, the data addition process is terminated.

  FIG. 5 is a flowchart for explaining the offset data update process S716 of FIG.

  In the offset data update process S716, offset data and an offset are received as inputs. As an example, it is assumed that an integer value string of “10, 11, 12” is compressed with Variable Byte Code as offset data, and 129 is input as an offset. At this time, a loop (step S812) is entered to check how many bits are required to represent the offset 129 in binary (step S813). At this time, 129 is larger than 128, which is one of the specified values, and smaller than 16384, so that it can be expressed by 14 bits. The 14 bits represent 129 (00000010000001), and this bit string is set to P (step S815). For P, one bit is added as a header for every seven bits in order from the top, and a single byte is handled. For this reason, P becomes (00000001 00000001). Further, if the 1 byte is the least significant byte representing a numerical value, 1 bit of the header is set to 1 (step S816). Therefore, P becomes (00000001 10000001). This is added to the end of the offset data (step S817), and it is assumed that the offset data is compressed "10, 11, 12, 129". At this time, if the bit length necessary for representing the offset data is equal to or smaller than the fixed bit length W set in advance for the offset data (step S818), the updated offset data is output and the updating process is terminated (step S819). ). If it is greater than or equal to W, the added offset 129 cannot be stored (step S814), so an error is output and the process ends without updating the offset data.

  FIG. 6 is a flowchart for explaining the complete match search processing of data by the key value of the data storage device.

  First, the key value X to be searched is input (step S911). A key value A having the smallest value equal to or greater than the search key value X is searched from the index file, and the logical block D1 including the record pointed to by the value A is read (step S912). Next, a record having a search key value X is searched using a binary search from the record portion in the read logical block D1 (step S913).

  At this time, if a record having the search key value X is found (step S914), the record having the search key value X is output and the process ends (step S921). If a record having the search key value X is not found, offset data corresponding to the read logical block D1 is read from the offset file in order to examine a record in another logical block (step S915). Thereafter, “offset data reference” processing is performed using the read offset data as input (step S916). Although details of this processing will be described later, an offset integer value sequence F can be obtained. After that, for all elements of the offset integer value sequence F (step S917), the number of offsets indicated by the element is set to G, and the logical block D2 that is the G block destination of the logical block D1 is read (step S918), and D2 is the search key value. Whether or not X is present is checked using a binary search (step S919). If a record having the search key value X is found (step S920), the record is output and the process ends (step S921). If no record having the search key value X is found even after checking all the elements of the offset integer value sequence F, it is output that there is no corresponding record, and the process is terminated (step S922).

  FIG. 7 is a flowchart for explaining the offset data reference process S916 of FIG.

  In the offset data reference process S916, offset data is received as an input. As an example, it is assumed that the input offset data is a compressed integer value string of “10, 11, 12, 129”. The offset data is returned to the original integer value sequence. One byte is read sequentially from the beginning (step S953), and it is checked whether the first header bit of the byte is 1 (step S954). At this time, if the first 1 bit is 0 (step S954), the subsequent 1 byte is regarded as a byte for expressing the same numerical value (step S955), and it is checked (step S953). If the first 1 bit is 1 (step S954), the bytes read up to that point are considered to represent one integer value, and the process of deleting the header of the first 1 bit of each byte is performed (step S954). S957). In the example, at this time, the offset data is (10001010 10001011 100001100 00000001 10000001), so that the numerical value of 1 byte is “10, 11, 12” and the numerical value of 1 byte is “129”. Recognize. In this way, all the bytes are converted into decimal numbers (step S958), which is output and the process is terminated.

  FIG. 8 and FIG. 9 are flowcharts showing range search processing by the key value of the data storage device 10.

  First, it is assumed that a search condition of not less than the lower limit key value and less than the upper limit key value is given as an input (step S1101). A key value that is not less than the lower limit key value and has the smallest value is searched from the index file, and a logical block including a record indicated by the value is read from the data file (step S1102). Subsequently, offset data corresponding to the read logical block is read from the offset file (step S1103). Using this read offset data as an input, an “offset data reference” process is performed (step S916), and an offset integer value sequence F is obtained as an output. The block position of the read logical block is added to each element of this offset integer value sequence F, and these are temporarily recorded as a block position set U (step S1105).

  Next, in order from the first record in the record portion of the logical block, it is checked whether the key value of the record is equal to or greater than the lower limit key value (step S1107). When a record that is equal to or higher than the lower limit key value is found, first, the last record having the maximum key value in the logical block is referred to and it is checked whether the key value is equal to or higher than the upper limit key value (step S1109). At this time, if it is not equal to or greater than the upper limit key value, all records from the currently referenced record of this logical block to the last record are added to the record set R satisfying the search condition as satisfying the search condition (step S1116). ). Thereafter, if there is a next logical block in the data file (step S1117), it is read and the same processing is performed (step S1118). If there is no logical block, the search ends there, the record set R is output, and the processing ends (step S1125).

  If the key value of the last record is greater than or equal to the upper limit key value (step S1109), it is compared in order from the referring record to the last record whether the key value is less than the upper limit value (step S1110). . If the key value of the record being referred to is less than the upper limit key value, the record is added to the record set R that satisfies the search condition (step S1111). If a record that is not less than the upper limit key value is found, the next search is performed for the record of the logical block pointed to by the offset data (step S1113).

  Reference is made to logical blocks at all block positions of the block position set U (step S1114), and records that are lower than the upper limit key value and lower than the upper limit key value are sequentially found and searched from the records of the blocks that have not been searched yet. The records are added to the record set R that satisfies the conditions (step S1123). When the search for the logical block pointed to by all addresses in the block position set U is completed, the search is terminated, and the record set R is output and the process is terminated (step S1125).

  The advantage of the data storage device 10 is that it can cope with an offset representing a large data arrival delay more efficiently. Conventionally, since the bit number is used to express the offset, the bit string length W of the offset data is the maximum recordable offset. On the other hand, since the data storage device 10 can represent one numerical value using a maximum of 28 bits, it is possible to show a large offset more efficiently. In the above example, “10, 11, 12, 129” is stored as the offset, but the data storage device 10 can store 40 bits as compared with the conventional case where 129 bits are required. For this reason, it is possible to efficiently cope with a large arrival delay that may occur due to an unexpected factor.

(Embodiment 2)
In the second embodiment, an integer value compressed by Simple 9 is used for expressing the offset. The configuration of the data storage device of the second embodiment is the same as that of the data storage device 10 of FIG.

  FIG. 10 is a diagram illustrating the data structure of the data storage device according to the second embodiment.

  The offset data, which is each record in the offset file 333 ', is fixed-length W-bit data. The position on the file is used to correspond to each logical block of the data file on a one-to-one basis. The offset data includes a code part that stores a compressed offset numerical sequence, and a header part that represents the number of elements of the offset numerical sequence stored in the code part and the number of 4-byte codes in the code part. The offset numerical value sequence is compressed using Simple9. In Simple 9, one integer value is usually expressed by 4 bytes (32 bits), but is expressed by 1 to 28 bits according to the size, and data is compressed.

  11 and 12 are flowcharts showing data addition processing in the data storage device of the second embodiment. 3 and 4 is that the offset data update process is step S716 '.

  FIG. 13 is a flowchart for explaining offset data update processing S716 'in the second embodiment.

  In the offset data update process S716 ', an offset and offset data are received as inputs. As an example, it is assumed that the input offset data is an encoded numeric string of “10, 11, 12” and the offset is 129.

  In the offset data update process S716 ′, the process is performed in the order of decoding the offset data into Simple9 (step S831), adding an offset to the decoded offset data (step S832), and encoding the offset data into Simple9 (step S833). Is called.

  In this example, first, “10, 11, 12” encoded with Simple 9 is decoded, 129 is added to the decoded numerical sequence, and the numerical sequence of “10, 11, 12, 129” is encoded with Simple 9, It is determined whether or not the encoded bit string fits in the fixed length W bits (step S834). If so, the updated offset data is output and the process ends.

  FIG. 14 is a flowchart for explaining the Simple9 encoding process (step S833) of FIG.

  In the Simple 9 encoding process S833, a non-negative integer value sequence is received as an input. In the encoding process, first, the difference between an element and the next element is calculated in the order of elements in the input integer value sequence (step S1004) and recorded (steps S1003 to S1005). The numerical sequence of “10, 11, 12, 129” given as an example becomes “10, 1, 1, 117” after calculation. The numerical sequence after this calculation is encoded by Simple9. The elements of the numeric string are checked from the beginning, and it is checked how many bits the numeric value can be expressed (steps S1011 to S1013). When encoding “10, 1, 1, 117”, the first three elements “10, 1, 1” can be encoded with 4 bits, but the subsequent 117 requires 7 bits for encoding. All numeric string encoding is performed using 7 bits. At this time, by adding a 4-bit header (0101) as the header of the bit string, it indicates that the subsequent 28 bits represent a numerical value in units of 7 bits (step S1012). The following 28 bits represent “10, 1, 1, 117” with 7 bits, respectively, to obtain a bit string (0001010 00000001 0000001 1110101). As a result, the 32-bit code obtained by encoding “10, 1, 1, 117” is (0101 0101010 00000001 0000001 1110101), and this is recorded as one code of Simple 9 (step S1018). Finally, the number of encoded values N = 4 and the number of simple 9 codes T = 1 are entered in the header portion of the offset data (step S1020), the offset data is output, and the process ends.

  FIG. 15 is a flowchart showing the Simple 9 decoding process (step S831) of FIG.

  In the Simple 9 decoding process S831, offset data is received as an input. As an example, it is assumed that the input offset data is an encoded numerical sequence of “10, 11, 12, 129” (0101 0101010 0000001 0000001 1110101). First, referring to the header portion of the offset data, the number of 32-bit Simple9 codes T = 1 and the encoded integer value N = 4 are obtained (step S1031). After that, decoding processing is performed in order from the top for all T Simple9 codes (steps S1033 to S1038). In the decoding process, by referring to the upper 4 bits which are the headers of the respective codes, it is obtained how many bits following the 28 bits are divided and converted into decimal integer values. In this example (0101 01010 0000001 0000001 1110101), the first 4 bits are (0101), which indicates that the following 28 bits are divided into 7 bits each, so (00010100000000001,0000001,1110101) is a decimal number. The numerical sequence “10, 1, 1, 117” converted into the above is obtained. Further, the sum of the element and the previous element is calculated in order from the top of the obtained number sequence, and the number sequence is updated using the sum as a new element (step S1041). This is repeated up to the last element of the sequence (steps S1040 to S1042). In this example, since it is “10, 1, 1, 117”, the numerical sequence that can be calculated from this is “10, 11, 12, 129”. The Simple9 decoding process S831 outputs this sequence as a decoding result, and ends the process.

  FIG. 16 is a flowchart for explaining complete match search processing using key values in the data storage apparatus according to the second embodiment.

  The exact match search process is the same as the exact match search process of the first embodiment described with reference to FIG. 6 except that the offset data reference process S916 in FIG. 6 becomes the Simple 9 decode process S831.

  17 and 18 are flowcharts for explaining range search processing by key values in the data storage device of the second embodiment.

  The range search process is the same as the range search process of the first embodiment described with reference to FIGS. 8 and 9 except that the offset data reference process S1104 is a Simple9 decode process S831.

  The advantage of the data storage device according to the second embodiment is that not only can a large offset be efficiently expressed as in the data storage device 10 of the first embodiment, but even a small offset can be expressed with a minimum of 1 bit, and a small offset Can also be expressed efficiently. In the example given in the embodiment, “10, 11, 12, 129” is stored as the offset, but in the second embodiment, 129 bits are required in the conventional method, but in the second embodiment, the header is divided into 32 bits. For example, 32 bits, and 64 bits.

(Embodiment 3)
The third embodiment is a method in which a bit number is used to express an offset, and Run Length compression is used when 0 or 1 bits are consecutive. The configuration of the data storage device of the third embodiment is the same as that of the data storage device 10 of FIG.

  FIG. 19 is a diagram illustrating a data structure of the data storage device according to the third embodiment.

  The offset data that is each record in the offset file 333 ″ is fixed-length W-bit data. The position on the file is used to correspond to each logical block of the data file on a one-to-one basis. The code length storage unit is composed of one code length storage unit, one compression count storage unit, a plurality of compression positions and compression bit number storage units, and one code unit. The compression count storage unit holds the number of subsequent compressed positions and the number of compressed bit number storage units, and the compressed position and compressed bit number storage unit compresses the bit position where compression is performed in the subsequent code portion and the compressed position. In the code part, the bit string after compression processing is held.

  In the bit string of the code part, the bit position of 1 bit basically indicates the number of delayed blocks of data. At this time, however, if 1 or 0 of the bit continues in the code part for more than k threshold values, this is subjected to Run Length compression. At this time, as the compression position and compression bit number storage unit, a position in which the Run Length compression is started and the number of compressed bits are created and added to the offset data. The added compression position and the number of compression bit number storage units are entered in the compression number storage unit and added as needed.

  20 and 21 are flowcharts showing data addition processing in the data storage device of the third embodiment. The difference from the flowcharts of FIGS. 3 and 4 is that the offset data update process is step S716 ″.

  FIG. 22 is a flowchart illustrating the offset data update process S716 ″ according to the third embodiment.

  In the offset data update process S716 ", the offset data X and the offset Y to be added are received as inputs. As an example, the input offset data X is a numerical string of" 10, 11, 12 "compressed by the offset data compression process. Assume that the offset Y to be added is 129.

  In the offset update process S716 ″, first, the compression count storage unit is referred to obtain the number M of compressed position and compression bit number storage units (step S851). Next, the M compression position and compression bit number storage units are stored. The M compression positions P [1..M] and the number of compression bits S [1..M] are stored (step S852), and the number of M compression bits S [1..M] is then stored. All are added, and the last division position P [M] is added to this to obtain the last bit position when the compressed portion recorded by the offset data is expanded, and this value is set as Last_P (steps S853 to S857). Next, the offset Y to be added and the value of Last_P are compared, and if the value obtained by incrementing Y and Last_P by 1 is equal (step S858), the Mth compression is performed. The number of compressed bits S [M] is incremented by 1 (step S859) If Y and Last_P are not equal to each other in the code portion of the offset data X, the Y to Last_P The bit at the position of the value obtained by subtracting 1 is set to 1 (step S861), and the value of the code length storage unit N is updated by subtracting Last_P from Y (step S862). The data X is input to the offset compression process (step S863), and as a result, compressed offset data Z is obtained, and then it is determined whether the offset data Z can fit within a predetermined fixed length W bits ( Step S864) and the offset data update process are terminated.

  In the example, the offset data is obtained by compressing “10, 11, 12” by the offset compression process. When this is represented by a bit string, the bit string (00000000 0111) in which the 10th, 11th, and 12th bits are set to 1. It becomes. When “129” which is an offset is added to this, if this is represented by a bit string, 116 0s exist between “12” and “129”. When the 116 0 bits are subjected to Run Length compression, the number of compressions is 1, the compression position and the number of compression bits are “13,115”, and the bit string of the code part is (00000000 011001). As another example, it is assumed that there is offset data in which numerals “11, 12, 13,..., 98, 99, 100” are continuous, and a new offset 101 is added thereto. This data is subjected to Run Length compression, the compression position and the number of compression bits are “11,89”, and the code part is (00000000 001). When offset 101 is added to this, since it is larger by 1 than the last numerical value, if only the compression bit number is updated and the compression position and the compression bit number are “11, 90”, the offset 101 is added. It becomes.

  FIG. 23 is a flowchart for explaining the offset data compression processing S863 in FIG.

  In the offset data compression process S863, offset data is received as an input. The offset data is searched for a compressible portion, and Run Length compression is performed. First, the code length storage unit and the compression count storage unit of the offset data are respectively referred to, and the bit number N of the code unit, the compression position, and the number M of the compression bit number storage units are obtained (steps S1051 and S1052). Next, it is determined whether M is larger than 0 (step S1055). When M is larger than 0, since the offset data is compressed, i = P [M] +1 is set in order to skip the already compressed portion (step S1056), and the compression is performed. The search for the compressible part is started from the bit following the last bit. If M is equal to or less than 0, since the offset data is not compressed, i = 1 is set, and a search for a compressible portion is started from the first bit of the code portion (step S1057). In the search for a compressible portion, i is incremented by 1 (step S1058), and X [i] and X [i-1] are compared (step S1059), so that 0 or 1 bits are consecutive. If it is continuous, the counter is incremented by 1 to count up the continuous number (step S1060). If X [i] and X [i-1] are different, it is considered that the continuation of 0 or 1 bits is interrupted, and whether or not the counter indicating the number of consecutive bits exceeds the threshold value K (step S1068). It is determined whether or not to compress this. If counter is equal to or greater than K, compression processing is performed. In the compression process, first, M indicating the number of compressions is incremented by 1 (step S1069). Next, S [M] indicating the number of compressed bits is set as a counter (step S1070). Subsequently, P [M] indicating the compression position is a value obtained by subtracting 1 from i and further subtracting counter (step S1071). Next, processing is performed to prepend bits by the number of compressed bits (steps S1073 to S1076). Further, N indicating the effective bit length of the code part is also reduced by the counter in accordance with the compression (step S1077). Finally, i indicating the position of the currently checked bit is set to i = P [M] +1 and is set to the position of the bit next to the compressed bit (step S1078).

  On the other hand, even when the 0 or 1 bit continues and reaches the end of the bits of all code parts, if the consecutive number exceeds the threshold value K, compression processing is performed (step S1062). . In this compression processing, first, M indicating the number of compressions is incremented by 1 (step S1063), and S [M] indicating the number of compression bits is used as a counter (step S1064), but P [M] indicating the compression position is A value obtained by subtracting counter from i is set (step S1065). Next, N indicating the effective bit length of the code part is also reduced by the counter in accordance with the compression (step S1066). Finally, N, M, P, S, and X are respectively reflected in the offset data code length storage unit, compression count storage unit, compression position and compression bit number storage unit, and code unit to update the offset data (step S1067). ). The updated offset data is output and the compression process is terminated.

  As an example, in the offset data update process S716 "shown in FIG. 22, a numerical string whose offset data X is" 10, 11, 12 "is compressed by the offset data compression process, the offset Y to be added is 129, and the threshold value Consider the case where K is 32. The offset data X is data in which the code length N = 12, the number of compressions M = 0, and the code part is (000000000111), where M = 0, the compression position and the number of compression bits. Since there is no storage unit, P [1] = 0 and S [1] = 0, so that Sum_S and Last_P are also 0. Y is 129, which is equal to Last_P plus 1. Therefore, the 129th bit of the code part of the offset data X is set to 1, and the intervening bits are filled with 0. N is also set to 129 in the same manner. Updating set data X. Next, as input offset data X updated, an offset data compression processing S863 shown in FIG. 23.

  In the offset data compression processing S863, first, the code length storage unit and the compression count storage unit are referred to, and the code length N = 129 and the compression count M = 0 are obtained. Since M = 0 and there is no compression position and compression bit number storage unit, P [1] = 0 and S [1] = 0. Read the code part and replace it with X [1. . . 129]. Since M = 0, i = 1 is set, and it is checked whether the same bits are consecutive from the first bit of X. Since X is (000000000111000... 0001), 0s are consecutive in the first 9 bits. However, with 9 consecutive bits, the counter is 8, and the threshold value K of 32 is not exceeded, so compression is not performed. Similarly, the following (111) is also continuous with only 3 bits, and the counter is 2, which is smaller than the threshold value K, so that compression is not performed. The following 0 is 116 bits continuous, and the counter is 115, which is larger than the threshold value K, so compression is performed. First, M, which is the number of compressions, is increased by 1, and M = 1. Next, the value of counter is substituted into S [M], and S [M] = 115. P [M] is 13 which is obtained by subtracting 1 and counter = 115 from i = 129. Subsequently, a process is performed in which the bits behind the compressed position are prepended by the number of compressed bits. Thereafter, the code length N = 129 is reduced by counter = 115, which is the amount compressed, and N = 14. Finally, i, which is the position of the next bit to be checked, is set to P [M] + 1 = 14, which is the next position of the compressed bit, counter is set to 0, and the process returns to the loop. At this time, since i is no smaller than N, the loop exits, the code length N = 14, the number of compressions M = 1, the compression position P [1] = 13, the number of compression bits S [1] = 115, X = (00000000011101) is reflected in the offset data and updated, and the process ends, and the process returns to the offset data update process S716 ″ of FIG.

  Here, it is determined whether or not the obtained offset data Z exceeds W, which is a predetermined fixed length of offset data. If not, offset data updating is terminated. If it exceeds, it is determined that the offset Y cannot be stored, and a message to that effect is output. At that time, the offset data is not updated, and the offset data before the update is left as it is.

  FIG. 24 is a flowchart for explaining complete match search processing using key values in the data storage apparatus of the third embodiment.

  In the exact match search process, the same process as the complete match search process of the first embodiment described with reference to FIG. 6 is performed, but the offset data reference process S916 in FIG. 6 becomes the offset data reference process S916 ″.

  FIG. 25 is a flowchart for explaining the offset data reference process S916 ″ of FIG.

  In the offset data reference process, offset data is received as an input. First, the number M of compression position and compression bit number storage units is obtained by referring to the compression number storage unit of offset data (step S960). Subsequently, the M compressed positions and the compressed bit number storage unit are read, and the compressed positions P [1. . M] and the number of compression bits S [1. . M] is obtained (step S961). Next, the code length storage unit of the offset data is referred to obtain the code length N (step S962), and each bit of the code unit of the offset data is set to X [1. . N] (step S963). Next, an area for temporarily storing the offset as an integer string is prepared, and this is set as F (step S964). The process proceeds with i being a counter indicating the bit position, j being a counter indicating the compressed position and the position of the compressed bit number storage unit, and skip being the total number of compressed bits (step S965). First, P [j] is compared with i to check whether X [i] is a compressed bit (step S966). If X [i] is not a compressed bit, it is confirmed whether the bit is 0 or 1 (step S973). If it is 1, the offset indicated by it is obtained by adding i and skip (step S974), and this is stored in F (step S975). If it is 0 (step S973), this does not indicate an offset and no calculation is performed. Thereafter, i and N are compared (step S971). If i is smaller than N, i is increased by 1 (step S972), and the process returns to the comparison between i and P [j]. If i is greater than or equal to N, F is output and the process ends.

  Similarly, when X [i] is a compressed bit, it is confirmed whether the bit is 0 or 1 (step S967). If it is 1, in order to obtain all offsets indicated by X [i], counter = 0 is set (step S976), offset is calculated as offset = i + skip + counter (step S977), and stored in F (step S978). . This is repeated by incrementing by 1 until the counter becomes equal to S [j] (steps S979 and S980), and all offsets indicated by X [i] are stored in F. Thereafter, S [i] is added to skip to update skip (step S968). If X [i] is 0, the offset is not calculated and stored, and only the skip is updated (step S968). When skip is updated, j and M are compared (step S969). If j is smaller than M, j is incremented by 1 (step S970). Thereafter, the process proceeds to the comparison of i and N (step S971), and the same processing is performed.

  As an example, in the offset data reference process S916 "shown in FIG. 25, the input offset data is" 10, 11, 12, 129 "compressed by the offset data update process S716" shown in FIG. Think. At this time, M = 1, P [1] = 13, S [1] = 115, N = 14, and X = (00000000011101).

  When i = 1 to i = 9, P [1] = 13 and X [i] = 0, so that F in the offset integer string is not updated. When i = 10, 11, 12 and X [i] = 1, offset is calculated and stored in F, and F = “10, 11, 12”. Since i = P [1] = 13 when i = 13, it can be seen that X [13] is a compressed bit. At this time, since X [13] = 0, only the update of skip is performed, and skip = 115. Since j = 1 and M = 1, j is not updated, only i is incremented by 1, and i = 14. Since X [14] = 1, offset is calculated as offset = i + skip, offset = 129 is obtained, F is updated, and F = “10, 11, 12, 129”. Since i = N = 14, F is output, and the offset data reference processing is completed.

  26 and 27 are flowcharts for explaining range search processing based on key values in the data storage apparatus according to the third embodiment.

  The range search process is the same as the range search process of the first embodiment shown in FIGS. 8 and 9, except that the offset data reference process S1104 becomes the offset data reference process S916 ″ described in FIG. Is different.

  The data storage device according to the third embodiment employs a method specialized for data such that data arrival delays occur continuously. An offset can be efficiently expressed when a large offset value continues continuously, such as when data accumulated in the output buffer is sent together after the line is restored due to line disconnection on the data source side or the like. In the example given in the embodiment, “10, 11, 12, 129” is stored as an offset, but in the third embodiment, 129 bits are required in the conventional method. If the size H1 is 16 bits, the compression count storage unit size H2 is 8 bits, and the compression position and compression bit number storage unit size H3 is 32 bits, the code part is 14 bits, so it can be stored in a total of 70 bits. it can.

(Compression effect)
Next, an example of improving bit efficiency by each compression method of the present invention is shown in a graph. In the following example, the size of the header portion in the offset data of Simple 9 is 32 bits, the size of the code length storage portion in the offset data of Run Length compression is 16 bits, the size of the compression count storage portion is 8 bits, and the compression position The calculation is performed by setting the size of the compression bit number storage unit to 32 bits.

  FIG. 28 is a graph showing the difference in the required number of bits depending on the compression method when a certain number of offsets is stored in the offset data. A comparison is made between Bitmap, which is a conventional method, and Variable Byte Code, Simple9, and Run Length compression, which are each method of this embodiment. The horizontal axis represents the number of offsets to be expressed, and the vertical axis represents the number of bits necessary to store the number of offsets corresponding to the horizontal axis on the logarithmic axis. From the graph, it can be confirmed that each method of the present embodiment has a more gradual increase in the required number of bits with respect to the increase in the number of offsets than the conventional Bitmap.

  FIG. 29 is a graph showing the difference in the required number of bits depending on the compression method when the number of offsets continuous in a certain range is stored in the offset data. A comparison is made between Bitmap, which is a conventional method, and Variable Byte Code, Simple9, and Run Length compression, which are each method of this embodiment. The horizontal axis indicates a range of consecutive offset numbers, and “1-10” represents an offset numerical value sequence of “1, 2, 3, 4, 5, 6, 7, 8, 9, 10”. The vertical axis indicates the number of bits necessary for storing the offset numerical value sequence indicated by the horizontal axis in the offset data, on the logarithmic axis. From the graph, it can be seen that the bit efficiency of Bitmap, which is the conventional method, is good when the number of offsets is continuously arranged, but that Run Length has a bit efficiency exceeding Bitmap when “1-70” or more. .

  FIG. 30 is necessary when the offset number of any one of 100, 200, 300, 400, 500, 600, 700, and 800 is stored as offset data in addition to the continuous offset numerical value sequence from 1 to 10. It is a graph which shows the difference by the compression method of bit number. A comparison is made between Bitmap, which is a conventional method, and Variable Byte Code, Simple9, and Run Length compression, which are each method of this embodiment. In addition, the horizontal axis indicates the number of offsets to be stored, and the vertical axis indicates the number of bits required to store this as offset data when the number of offsets indicated by the horizontal axis is added. From the graph, in the Bitmap which is the conventional method, the required number of bits increases linearly according to the size of the offset number to be stored additionally, whereas in each method of this embodiment, it is almost It can be seen that there is no change in the required number of bits and that the number of offsets can be stored with high bit efficiency.

  FIG. 31 shows bits required when offset numbers of any one of 100, 200, 300, 400, 500, 600, 700, and 800 are stored as offset data in addition to 1 to 64 consecutive offset numerical sequences. It is a graph which shows the difference by the compression method of a number. A comparison is made between Bitmap, which is a conventional method, and Variable Byte Code, Simple9, and Run Length compression, which are each method of this embodiment. In addition, the horizontal axis indicates the number of offsets to be stored, and the vertical axis indicates the number of bits required to store this as offset data when the number of offsets indicated by the horizontal axis is added. From the graph, in the conventional method Bitmap, the required number of bits increases linearly corresponding to the size of the offset number to be stored additionally, whereas in each system of this embodiment, it is necessary. It can be seen that there is almost no change in the number of bits, and in particular, whatever length numerical value sequence is added to Run Length compression, the bit efficiency is equal to or higher than Bitmap.

(Other embodiments)
Each data storage device described above can also be realized by a computer and a program. The operation of each data storage device described above can be a computer-executable program, which can be recorded on a computer-readable recording medium or provided to the computer via a network.

10: Data storage device 110: Interface 120: Buffer memory 300: System control unit 301: Input data analysis unit 302: Memory management unit 303: File operation unit 304: Offset compression unit 330: Secondary storage device 331: Index file 332: Data file 333, 333 ', 333 ": offset file

Claims (3)

A secondary storage device that sequentially stores data continuously input in units of records, in units of logical blocks;
When a specific value of the record is used as a key value and indexing is performed using a sparse index, and the record having the key value included in the range of key values handled by one logical block is in another logical block Includes a system control unit that records the offset number of the offset from the one logical block to the other logical block as a bit string, and records the compressed offset data as an offset file in the secondary storage device;
Equipped with a,
The system control means includes
The offset data is composed of a code length storage unit, a compression number storage unit, a header unit consisting of a compression position and a compression bit number storage unit, and a code unit,
In the code part, the bit at the bit position equal to the offset number is set to “1”,
When the bit string of the code part includes a continuous bit part in which the same bit is continuous over a preset threshold value, the number of bits of the continuous bit part is counted, and the leading position of the continuous bit part and the continuous bit part Are recorded in the compressed position and the compressed bit number storage unit,
Deleting the other bits of the continuous bit part leaving the first bit of the continuous bit part,
Record the number of bits used in the code part after bit deletion in the code length storage part,
Record the compression position and the number of compressed bit number storage units in the compression count storage unit
A data storage device comprising an offset compression unit . When sequentially storing data that is continuously input in units of records in a secondary storage device in units of logical blocks,
When a specific value of the record is used as a key value and indexing is performed using a sparse index, and the record having the key value included in the range of key values handled by one logical block is in another logical block the, have row system control procedure for recording in the secondary storage device the offset data compressed to express offset number to said separate logical blocks in the bit string from said one logical blocks as an offset file,
In the system control procedure,
The offset data is composed of a code length storage unit, a compression number storage unit, a header unit consisting of a compression position and a compression bit number storage unit, and a code unit,
In the code part, the bit at the bit position equal to the offset number is set to “1”,
When the bit string of the code part includes a continuous bit part in which the same bit is continuous over a preset threshold value, the number of bits of the continuous bit part is counted, and the leading position of the continuous bit part and the continuous bit part Are recorded in the compressed position and the compressed bit number storage unit,
Deleting the other bits of the continuous bit part leaving the first bit of the continuous bit part,
Record the number of bits used in the code part after bit deletion in the code length storage part,
Record the compression position and the number of compressed bit number storage units in the compression count storage unit
A data storage method characterized by the above . The program for making a computer perform the said system control procedure of the data storage method of Claim 2 .

Images