WO2013175909A1 - データ解凍/圧縮装置 - Google Patents
データ解凍/圧縮装置 Download PDFInfo
- Publication number
- WO2013175909A1 WO2013175909A1 PCT/JP2013/061552 JP2013061552W WO2013175909A1 WO 2013175909 A1 WO2013175909 A1 WO 2013175909A1 JP 2013061552 W JP2013061552 W JP 2013061552W WO 2013175909 A1 WO2013175909 A1 WO 2013175909A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data
- compressed
- compression
- size
- column
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/12—Replacement control
- G06F12/121—Replacement control using replacement algorithms
- G06F12/126—Replacement control using replacement algorithms with special data handling, e.g. priority of data or instructions, handling errors or pinning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/221—Column-oriented storage; Management thereof
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/46—Conversion to or from run-length codes, i.e. by representing the number of consecutive digits, or groups of digits, of the same kind by a code word and a digit indicative of that kind
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0864—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches using pseudo-associative means, e.g. set-associative or hashing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
- G06F12/0871—Allocation or management of cache space
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0893—Caches characterised by their organisation or structure
- G06F12/0895—Caches characterised by their organisation or structure of parts of caches, e.g. directory or tag array
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/10—Providing a specific technical effect
- G06F2212/1016—Performance improvement
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/40—Specific encoding of data in memory or cache
- G06F2212/401—Compressed data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/46—Caching storage objects of specific type in disk cache
- G06F2212/465—Structured object, e.g. database record
Definitions
- the disclosed subject matter relates to a technique for rapidly decompressing data in which a sequence of a plurality of fixed-length records is compressed.
- the car navigation system processes map data and provides users with traffic guidance information.
- HDD Hard Disk Drive
- SD card and SSD Solid State Drive
- the semiconductor element memory has advantages such as low power consumption and excellent impact resistance as compared with the conventional HDD, but has a disadvantage that the unit price per capacity is high. For this reason, in order to provide a car navigation system to a user at a price range similar to the conventional one, it is necessary to reduce the capacity of the semiconductor element memory to be used. On the other hand, the contents of data necessary for the operation of the car navigation system are the same regardless of whether the storage medium is an HDD or a semiconductor device memory, and the size of the database tends to increase year by year due to the development of new roads and facilities. For this reason, a technology for reducing the size of data recorded in car navigation is always desired. The following techniques have been proposed as techniques for reducing the data size.
- Patent Document 1 As a method generally used for reducing the data size without changing the data content, there is a data compression technique described in Patent Document 1. Since the data compression technique can easily reduce the data size, in addition to the technique described in Patent Document 1, a number of compression methods have been proposed and widely used.
- Patent Document 2 As another technique for reducing the data size, there is a technique described in Patent Document 2.
- a dictionary is created in a predetermined procedure by paying attention to each column of the table, and compression is performed in units of columns by using this dictionary. Reducing the data size. If the data to be compressed has a two-dimensional structure consisting of rows and columns, compressing the data in units of columns rather than simply processing the data (byte sequence) in the row direction from the top. It is generally known that an improvement in rate can be expected, and for example, it is mentioned in many documents such as Non-Patent Document 1.
- Patent Document 3 As another technique for reducing the data size, there is a technique described in Patent Document 3. This technology focuses on the fact that random access to a specific location in the database and sequential access when referring to relatively large data are mixed as a form of car navigation applications accessing the database. The performance of sequential access is improved by prefetching the subsequent block into the memory when referring to a certain block while enabling random access to the target data after dividing and compressing the data into predetermined block units Is also planned.
- Patent Document 1 Patent Document 2, and Patent Document 3 have the following problems.
- the data compression technique described in Patent Document 1 or the like requires a process of restoring the compressed data (hereinafter referred to as a decompression process) before referring to the data. Since this decompression process takes time, if the data is simply compressed, there is a problem that the performance when performing various navigations with reference to the data deteriorates.
- Patent Document 3 is intended to improve performance at the time of sequential access by prefetching a subsequent block to a cache memory when referring to data of a certain block. This is limited to the case where the contents stored in the cache memory are not replaced during the decompression process.
- data is compressed in the column direction as in the technique described in Patent Document 2, it is necessary to decompress all the columns in order to extract one row of data, as described above. Since the size of the area required to hold the decompression result of the column (ie, corresponding to the entire data) greatly exceeds the capacity of the cache memory, refer to the area where the CPU (Central Processing Unit) holds the decompression result In doing so, the pre-read compressed data is deleted from the cache memory.
- CPU Central Processing Unit
- the compressed data is not read from the cache memory but is read again from a slower storage medium such as the main storage device or the HDD, so that the effect of prefetching cannot be obtained.
- it is required to improve the decompression performance while improving the compression rate of large-capacity data including a large number of fixed-length records.
- the number of records to be subjected to one-time column-direction compression is not limited to the cache memory capacity of the decompression device, the capacity of the main storage device that can be used by the decompression device, or the decompression device
- a single maximum data transmission size according to a communication protocol may be used.
- the technology disclosed in the present specification is a system that distributes compressed data from a distribution server to various decompression devices having different performance indexes via a communication network.
- a second feature is that compressed data is created, and compressed data that matches the performance of the requested decompression device is selected and distributed.
- a terminal for browsing data corresponding to the decompression device disclosed in this specification
- various terminals having different performance such as a mobile phone and a smartphone in addition to a PC (Personal Computer). It is possible to distribute compressed data having the shortest decompression time in each terminal.
- one kind of compressed data created in advance is once decompressed, and this decompressed and restored data is a performance index specific to the decompressing device that requires the compressed data. It is good also as a structure which recompresses and distributes according to.
- a data compression apparatus that compresses data to be compressed including a plurality of fixed-length records, the size of one record of the fixed-length record, the specification information of the data decompression apparatus,
- the size of the compression target block is determined based on the unit size setting unit that accepts the input, the size of the fixed length record, and the specification information of the data decompression device, and a plurality of fixed lengths included in each compression target block
- a data compression device is disclosed that includes a column data compression unit that compresses the same column data of a record for each column to generate compressed column data, and generates compressed data including the respective compressed column data.
- the compression data is divided into predetermined compression target block size units, and each compression target block is compressed. If the compression target block size is determined based on the size of the fixed-length record and the specification information of the data decompression device, the fixed-length record The size of the compression target block is determined based on the size and the specification information of the data decompression device, one or more compression target blocks are obtained from the compressed data, and a plurality of fixed-length records included in the compression target block are the same Decompress each of the compressed column data, which is the result of compressing the column data for each column, and decompress the column data to restore multiple fixed-length records When, data decompression apparatus comprising a are disclosed.
- FIG. 1 is a diagram illustrating an overall configuration of a tree data compression system (first embodiment).
- FIG. Example illustrating the structure of one record of tree data (Example 1)
- Example illustrating compression target data (original data) (Example 1)
- FIG. 3 is an explanatory diagram illustrating the structure of a cache memory 170 (first embodiment). Explanatory drawing which illustrates the problem of the cache memory at the time of column direction compression (Example 1). The figure which illustrates the structure of compressed data (Example 1).
- the figure which illustrates the structure of a compression identifier Example .
- FIG. 3 is a diagram illustrating a configuration of a compression definition file (Example 1).
- the figure which illustrates a compression data creation screen (Example 1).
- movement of a block data compression part (Example 1).
- movement of a column data compression part (Example 1).
- movement of a column direction compression process (Example 1).
- Explanatory drawing which illustrates the request
- decompression part (Example 1).
- decompression part (Example 1).
- FIG. 6 is a diagram illustrating a configuration of a storage medium (second embodiment).
- the figure which illustrates a compression data creation screen (Example 2).
- a flowchart which illustrates operation of a block data compression part (example 2).
- 10 is a flowchart illustrating a compressed data creation process for each device (second embodiment).
- the figure which illustrates a compression data transmission / reception sequence (Example 2).
- Embodiment 1 compresses search data (hereinafter referred to as tree data) that occupies a large area in a database stored in a car navigation system, thereby reducing the size of the car navigation database.
- the column direction data decompression device 100 corresponds to a car navigation system
- the column direction data compression device 200 corresponds to a device (such as a personal computer) for creating data stored in the storage medium 150 of the car navigation system.
- FIG. 1 shows a functional configuration of the tree data compression system according to the first embodiment.
- This system includes a column direction data decompression device 100 and a column direction data compression device 200.
- the tree data to be compressed in the first embodiment is compressed by the column direction data compression device 200 and copied to the storage medium 150 of the column direction data decompression device 100.
- the application software executes a search process while partially decompressing the compressed tree data.
- the column direction data decompression apparatus 100 includes an application software execution unit 110 that executes application software, a block data decompression unit 120 that decompresses data compressed in units of blocks, and a column data decompression unit 140 that decompresses data compressed in the column direction.
- the column direction data compression apparatus 200 includes a block data compression unit 220 that compresses data in block units while referring to the compression definition file 700, a unit size setting unit 230 that sets data compression parameters, and a column that compresses data in the column direction.
- the data compression unit 240 is configured to include a storage medium 250 that stores the original data 600 to be compressed and the compressed data 500.
- the column-direction data compression apparatus 200 also has a main storage device and a cache for executing a series of processing, as in the column-direction data decompression apparatus 100. There is memory.
- Each device shown in FIG. 1 can be realized by using a general computer including a CPU and a storage device.
- the cache memory 170 is provided in the CPU
- the main storage device 160 is constituted by a semiconductor memory
- the storage medium 150 is a magnetic recording medium such as an HDD, or a non-volatile flash memory that is slower than the main storage device 160. It is assumed that it consists of.
- each processing unit constituting each device is embodied on the computer by the CPU executing a program stored in the main storage device 160 or the storage medium 150.
- Each program may be stored in advance in a storage device in the computer, or introduced to the storage device from another device via an input / output interface and a medium that can be used by the computer when necessary. May be.
- the medium refers to, for example, a storage medium that can be attached to and detached from the input / output interface, or a communication medium (that is, a wired, wireless, optical network, or a carrier wave or digital signal that propagates through the network).
- FIG. 2 shows an example of the format and data of tree data to be compressed.
- One record of tree data consists of 12 bytes, and stores an address 601 (4 bytes) of a lower node (child of the tree), a size 602 (4 bytes) of a lower node, and a record value 603 (4 bytes). Yes.
- the first character is “A”
- “B” and “D” are present as the second character
- “C” and “D” are present as the third character following “B”.
- E ”and“ H ” are present.
- Such tree data is used on a screen for inputting a destination name or the like provided in a general car navigation system (buttons indicating respective characters such as alphanumeric characters are displayed on the screen). ”Is entered, the second character of the name starting with“ A ”(ie,“ B ”,“ D ”, etc.) can be pressed, but other characters cannot be pressed. This is data for facilitating the search by the user.
- FIG. 3 shows an example in which the arrangement of the tree data included in the original data 600 is expressed in hexadecimal, and an example of the compressed data in the column 02 included in the compressed data 500.
- line breaks are written in units of 12 bytes, which is the size of one record, for easy understanding.
- the same digit value often has a characteristic pattern.
- the values of column 00 and column 01 are all 00.
- the run-length code 01, 01, 02, 04, 03, 06 are obtained.
- the meaning of this compressed data indicates that one symbol 01, four symbols 02, and six symbols 03 continue.
- the run-length code is a compression method that expresses data using a symbol and the number of consecutive symbols, and is disclosed in many documents.
- FIG. 4 In order to assist in understanding the background of the present embodiment, the problem when data is compressed in the column direction will be described with reference to FIGS. 4 and 5.
- FIG. 4 shows an example of a cache memory 170 based on a method generally called “set associative” which is generally used in recent years.
- the cache memory 170 is configured to include a plurality of areas (referred to as entries) for storing data of a certain size (referred to as lines), and is particularly the same as the set associative method using tags.
- entries a plurality of areas
- lines data of a certain size
- lines are particularly the same as the set associative method using tags.
- a plurality of lines are stored in an entry.
- the number of lines that can be stored in the same entry is called the number of ways, and the case where four lines can be stored in the same entry is called a 4-way set associative system.
- FIG. 4 shows an example of a 4-way set associative method in which one line size is 32 bytes and has 256 entries.
- 8 bits corresponding to the 5th to 12th bits of the virtual address Is an example of a method using 19 bits corresponding to the 13th to 31st bits of the address as a tag.
- a tag array 171 and a data array 172 having columns of the number of ways are described.
- the data array 172 is a table holding four lines stored in each entry, and the tag array 171 indicates which address the data stored in the data array 172 has for each entry.
- the tag to be shown is stored.
- the operation of the cache memory 170 will be described by taking as an example a case where a reference to data located at the virtual address (32-bit value) 0x00012041 occurs.
- an entry is determined from the 8-bit value stored in the fifth to twelfth bits of the virtual address (step S1701).
- the value stored in the 5th to 12th bits is 00000010 in binary representation, that is, 2 in decimal. If the data is on the cache memory 170, it means that it is stored in entry 2 To do.
- step S1702 19 bits (tags) stored in the 13th to 31st bits of the virtual address are compared with the 4 tags included in the entry 2 of the tag array 171 (step S1702).
- the same tag is stored in entry 2 and way 3, and from this, it is identified that the data of the line including virtual address 0x00012041 is held in way 3 of entry 2.
- This state is a state in which a so-called cache is hit, and the CPU can complete the processing with the output from the high-speed cache memory 170 without accessing the main storage device 160 (step S1703).
- a case where a tag matching the virtual address is not found is a so-called cache miss hit, and data is read from the main storage device 160.
- the least recently referenced line is deleted from the cache memory 170 by the LRU (Least Recently Used) method.
- a line newly read from the main storage device 160 is stored. If such line replacement occurs frequently, the data access performance by the CPU will be significantly reduced.
- FIG. 5 shows an example of a problem when the array of fixed-length records of 12 bytes per record is referenced in the column direction for the cache memory 170 shown in FIG.
- a square including “#n” means one record (12 bytes), and n is a record reference order.
- the black square indicates the location of row 00 (1 byte) and is located at the beginning of each record.
- entry 0 of way 1 stores record # 1 (12 bytes), # 2 (12 bytes), and the first 8 bytes of record # 3.
- Subsequent entry 1 stores 4 bytes that are a continuation of record # 3, record # 4 (12 bytes), # 5 (12 bytes), and the first 4 bytes of record # 6. The same applies to the subsequent entries.
- the way 3 and the way 4 are also actually used.
- the data referred to by the CPU is not only decompressed records but also compressed data before decompression, Since there is a work area used by the decompression algorithm, it is not possible to use all ways only for holding each decompressed record. Even if all the ways can be used, the number of records that can be stored is only doubled, and the problem is not essentially solved.
- FIG. 6 shows the format of the compressed data 500 in the first embodiment (the numerical value in parentheses means the size before compression).
- the compressed data 500 is obtained by dividing the original data into blocks of a predetermined size (64 KB in the figure) and compressing them.
- the compressed data 500 includes index data 501 indicating the start address of each block and a sequence of blocks to be compressed.
- a block data array 502 is included.
- Block details 503 describe data to be compressed included in each block, and are composed of a compression identifier, a record length, a sub-block arrangement, and remainder data.
- a sub-block is a block to be compressed by dividing it into sub-block sizes that do not cause the problem described above.
- each block is divided into 16380 bytes (size corresponding to 1365 records). This is data obtained by compressing the compression target block, and the remainder data is remainder data (16 bytes here) that is not divisible by the sub-block size (here 16380 bytes).
- the sub-block details 504 describe data included in each sub-block, and include a plurality of column compression identifiers and column compression data.
- column 00 compressed data is a compressed value of column 00 in 1365 records, and the original data size is 1365 bytes.
- FIG. 7 shows the value of the compression identifier 122 included in the block details 503.
- the compression identifier 122 indicates a method for compressing each block, and 00 (non-compression), 01 (column-direction compression), and 02 (row-direction compression) are defined.
- 00 (uncompressed) is an identifier used when there is no regularity in the data included in the block to be compressed, and the size reduction effect cannot be obtained even after compression
- 01 (column direction compression) is the column direction.
- This identifier is used when a size reduction effect can be obtained when compression is performed in (2).
- 02 line direction compression
- FIG. 8 shows the value of the column compression identifier 142 included in the subblock details 504.
- the column compression identifier 142 indicates a method for compressing each column to be compressed, and 00 (uncompressed), 01 (run-length code), 02 (fixed length bit code), 03 (Huffman code), etc.
- 00 (uncompressed) is an identifier used when there is no regularity in the data included in the compression target column, and a size reduction effect cannot be obtained even after compression
- 01 (run length code) is the compression target.
- This identifier is used when the size reduction effect can be obtained by compressing the data included in this column by the run length code.
- 02 (fixed-length bit code) and 03 (Huffman code) is an identifier used when a size reduction effect can be obtained by each method.
- the fixed-length bit code is replaced with a 4-bit code that can represent 16 if the original data contains only 16 symbols.
- the Huffman code is a method for reducing the data size by obtaining the appearance probability of a symbol and outputting a minimum redundant code.
- a compression method having the highest size reduction effect is selected and used, and it is assumed that a commonly used technique is used as it is. Details of each compression method are not particularly described.
- FIG. 9 shows a compression definition file 700 that is referred to when the block data compression unit 220 compresses data.
- the compression definition file 700 a start address 701, a compression identifier 702, and a record length 703 are described.
- all the data contained in one file is an array of fixed-length records having the same size, and there is no regularity other than the array of fixed-length records.
- Data and data that is not suitable for compression in the column direction, such as normal text data are also included.
- a sequence of fixed-length records which are 12 bytes per record from address 0x00000000, is stored.
- data having no regularity from address 0x001A0000 is 8 bytes per record from address 0x001B0000.
- the list of fixed-length records shows that text data is stored from the address 0x00300000 and data having no regularity is stored from the address 0x00310000.
- the compression definition file is used to determine a compression method to be applied to each block when the block data compression unit 220 compresses data based on these storage conditions.
- the first embodiment will be described along the flow of processing when the tree data is compressed and stored in the car navigation system and the tree data compressed in the car navigation system is referred to.
- FIG. 10 shows a unit size setting screen 231 displayed by the unit size setting unit 230 when tree data is compressed using the column direction data compression apparatus 200.
- the unit size setting screen 231 includes fields for inputting the target file 232, the compression definition file 233, the block size 234, and the terminal cache capacity 235.
- the target file 232 is a column for inputting the location where the original data 600 is located on the storage medium 250
- the compression definition file 233 is a column for inputting the location where the compression definition file 700 is located on the storage medium 250
- the block size 234 is
- the column for inputting the size (size before compression) of each block shown in FIG. 6 and the terminal cache capacity 235 are fields for inputting the capacity of the cache memory 170 provided in the column-direction data decompression apparatus 100.
- the compression process is started by inputting these parameters and pressing the OK button 239.
- FIG. 11 is a flowchart showing the operation of the block data compression unit 220 after the OK button 239 is pressed.
- the block data compression unit 220 first acquires the size of the file (original data) input to the target file 232 (step S2201).
- the number of blocks included in the original data is calculated based on the block size input to the block size 234 (step S2202). For example, when the size of the original data is 67588096 bytes and the block size is 64 KB (65536 bytes), the number of blocks is a value obtained by dividing 67588096 by 65536 (rounded up after the decimal point), which is 1032. The size of the 1032nd block is 20480 bytes that cannot be divided by 65536.
- step S2203 the counter variable i of the loop process repeated for each block is initialized to 0 (step S2203).
- step S2204 it is determined whether or not the variable i is less than the number of blocks obtained in step S2202 (step S2204).
- the start address (offset data) of the block being processed in the block data array 502 is output to the index data 501 (step S2205).
- a compression identifier and a record length used when compressing the block being processed are acquired (step S2206). This is done by scanning each line of the compression definition file and obtaining the compression identifier and record length corresponding to the address of the block being processed.
- the acquired compression identifier and record length are output to the block data array 502 (step S2207).
- step S2208 the process is branched according to the compression identifier (step S2208). If the compression identifier is 00 (uncompressed), the contents of the original data (64 KB for blocks 1 to 1031 and 20480 bytes for block 1032) are output as they are to the block data array 502 (step S2209). If the compression identifier is 01 (column-direction compression), compression in the column direction is performed (step S2210). Details of the column direction compression will be described later. If the compression identifier is 02 (row direction compression), the original data is compressed in the row direction (using a known compression algorithm such as Zlib), and the compressed data is output to the block data array 502 (step S2211).
- step S2212 the counter variable i is incremented by 1, and the process returns to step S2204 (step S2212).
- the above-described processing from step S2204 to step S2212 is repeated for all the blocks, and when the variable i becomes equal to the number of blocks in step S2204, the data compression processing is terminated, and the compressed data 500 is stored in the storage medium 250. Store.
- FIG. 12 is a flowchart showing the operation of the column data compression unit 240 executed in step S2210 of FIG.
- step S2402 the number of subblocks and the size of the remaining area are calculated from the block size input to the block size 234 and the subblock size obtained in step S2402 (step S2402). Since the block size is 65536 bytes and the subblock size is 16380 bytes, the number of subblocks is 4, and the size of the remainder area is 16 bytes.
- step S2403 the counter variable j of the loop process repeated for each sub-block is initialized to 0 (step S2403).
- step S2404 it is determined whether or not the variable j is less than the number of sub-blocks (step S2404). If the variable j is less than the number of sub-blocks, a loop processing counter variable k that is repeated for each digit of the record is initialized to 0 (step S2405).
- step S2406 it is determined whether or not the variable k is less than the record length. If the variable k is less than the record length, the column k is compressed (step S2408). The compression process for the column k will be described later.
- step S2409 1 is added to the counter variable k, and the process returns to step S2406 (step S2409).
- step S2406 The above processing from step S2406 to step S2409 is repeated for all the columns.
- the counter variable j is incremented by 1, and the processing returns to step S2404 (step S2407). ).
- step S2404 The above processing is repeated for each sub-block, and when the variable j becomes equal to the number of sub-blocks in step S2404, the remaining input data (that is, data for the size of the remainder area calculated in step S2402) The data is directly output to the data row 502, and the compression processing of the column data is finished (step S2410).
- FIG. 13 is a flowchart showing the column k compression processing executed in step S2408 of FIG.
- a column compression identifier used for column k compression is determined (step S2421). This processing is performed by counting the appearance frequency of the symbols included in the column k, so that any of 00 (uncompressed), 01 (run-length code), 02 (fixed length bit code), 03 (static Huffman code) Is used to calculate whether the size after compression is the smallest.
- the variables n, pSrc, and pDest used for the compression process are initialized (step S2422).
- the variable n is a variable indicating the processed input data size (number of bytes), and is initialized to 0.
- the variable pSrc is a variable indicating the address of the original data, and is initialized with the head address of the data in the column k.
- the variable pDest is initialized with the output destination address of the compressed data.
- Step S2424 When the variable n is smaller than the size of the column k, one byte existing at the address indicated by the variable pSrc is encoded by the method indicated by the column compression identifier, the variable pSrc is added by the record length, and the variable n is added by 1 ( Step S2424). If the encoded result is less than 1 byte and the variable n is less than the size of the column k, the process returns to step S2424. If the encoded result is 1 byte or the variable n is equal to the size of the column k, the process proceeds to step S2426 (step S2425).
- step S2423 is executed.
- the process returns (step S2426).
- step S2423 As a result of repeating the processing from step S2423 to step S2426 as many times as the number of symbols included in the column k, the compression processing of the column k is terminated when the value of the variable n becomes equal to the size of the column k.
- the compressed data 500 shown in FIG. 6 is created by the operations of the block data compressing unit 220 and the column data compressing unit 240 described with reference to FIGS.
- the compressed data 500 created in this way is copied to the storage medium 150 of the column direction data decompressing apparatus 100 and used by application software.
- FIG. 14 shows an example of a data acquisition request requested from the application software execution unit 110 to the block data decompression unit 120 in the first embodiment.
- 100 KB data starting from address 0x00010000 is referred to.
- the operation of the column direction data decompression apparatus 100 in response to this request will be described.
- FIG. 15 is a flowchart showing the operation of the block data decompression unit 120 when a data acquisition request is received from the application software execution unit 110.
- the block data decompressing unit 120 first calculates the target block range based on the requested address and the requested size (step S1201). In the case of the request shown in FIG. 14, the block 2 to the block 3 which are blocks including 100 KB starting from the address 0x00010000 are the range of the target block.
- step S1202 the compressed data for one block from the range of the target block is read from the storage medium 150 and stored in the main storage device 160 (step S1202). This process is performed by reading from the start address 0x0000001520 of the block 2 indicated by the index data 501 to the end address of block 2 (a value obtained by subtracting 1 from the start address of the next block 3), 0x0000005043.
- step S1203 the compression identifier and the record length are acquired from the head of the read block (step S1203).
- step S1204 the process branches according to the acquired compression identifier (step S1204).
- the compression identifier is 00 (uncompressed)
- the block data stored in the main storage device 160 is passed to the application software as it is (step S1205).
- the compression identifier is 01 (column direction compression)
- the column direction decompression process is performed on the block data stored in the main storage device 160 (step S1206). Details of the column direction decompression processing will be described later.
- the block data stored in the main storage device 160 is subjected to row direction decompression processing (using a known compression algorithm such as Zlib), and the result of decompression and decompression is the main result.
- the data is stored in the storage device 160 and transferred to the application software (step S1207).
- Step S1208 After any of the above three steps is executed, it is determined whether or not the decompression process has been completed for all the blocks included in the target block range. If there is a block that has not been decompressed, the process returns to step S1202 ( Step S1208).
- step S1208 the block data decompression processing is terminated.
- FIG. 16 is a flowchart showing the operation of the column data decompression unit 140 executed in step S1206 of FIG.
- the column data decompression unit 140 calculates the sub-block size from the capacity of the cache memory 170 (step S1401). This calculation process is performed by the same calculation formula as the sub-block size calculation process in the column-direction data compression apparatus 200. That is, when the cache memory capacity is 32 KB and the size of one record is 12 bytes, it is assumed that half of the 32 KB (16 KB) can be used to hold the data after decompression, and the maximum number of records that can be stored in 16 KB. The size (16380 bytes) is the sub-block size.
- step S1402 the number of sub blocks included in the block being processed and the remaining size are calculated. This calculation process is the same as the calculation process of the number of subblocks in the column direction data compression apparatus 200, and the number of subblocks is 4 and the remainder size is 16 bytes.
- step S1403 the counter variable j of the loop process repeated for each sub-block is initialized to 0 (step S1403).
- step S1404 it is determined whether or not the variable j is less than the number of sub blocks. If the variable j is less than the number of sub-blocks, a counter variable k for loop processing repeated for each column is initialized to 0 (step S1405).
- step S1406 it is determined whether or not the variable k is less than the record length. If the variable k is less than the record length, the data in the column k is decompressed (step S1408). Details of the decompression process of the column k will be described later.
- step S1409 the counter variable k is incremented by 1, and the process returns to step S1406 (step S1409).
- step S1406 the counter variable j is incremented by 1, and the processing returns to step S1404 (step S1407).
- step S1410 As a result of repeating the above processing for each sub-block, when the value of the variable j becomes equal to the number of sub-blocks, the remainder area is returned to the application software as it is (step S1410).
- FIG. 17 is a flowchart showing the decompression processing of data in column k, which is executed in step S1408 of FIG. First, a column compression identifier is acquired from the beginning of the compressed data (step S1421).
- variables n, pSrc, and pDest used for the decompression process are initialized (step S1422).
- the variable n is a variable indicating the output data size (number of bytes), and is initialized to 0.
- the variable pSrc is a variable indicating the storage address of the compressed data, and is initialized to the start address of the compressed data or the value of pSrc at the time when the decompression of the immediately preceding column k-1 is completed.
- the variable pDest is initialized to the first address + k of the decompressed data output destination (when the column width is 1 byte) in the case of the column k.
- step S1423 it is determined whether or not the variable is smaller than the size of the column k (ie, 1365) (step S1423).
- variable n is less than the size of the column k
- 1 byte existing at the address indicated by the variable pSrc is decoded by the method indicated by the column compression identifier, and 1 is added to the variable pSrc (step S1424).
- step S1426 After the output of a plurality of bytes decoded from 1 byte of compressed data is completed, the process returns to step S1423 (step S1426).
- step S1423 As a result of repeating the processing from step S1423 to step S1426, when the value of the variable n becomes equal to the size of the column k, the decompression processing of the data of the column k is terminated.
- the compressed data at the position requested by the application software execution unit is decompressed by the operations of the block data decompression unit 120 and the column data decompression unit 140 described with reference to FIGS.
- FIG. 18 shows the state of the cache memory 170 in the decompression process of the compressed data according to the first embodiment.
- the state in which records # 1 to # 1365 are stored in the cache memory 170 by referring to the column 00 is the same as in FIG. 5, but the cache 01 is processed to perform the decompression processing of the column 01 after processing up to the record # 1365.
- the contents of entry 0 on memory 170 are not replaced. That is, in the execution of the processing shown in FIGS. 16 and 17, unnecessary update of the cache memory 170 is suppressed, so that the compressed data can be decompressed at high speed.
- traveling history data of car navigation is collected in a center device and can be referred to from various terminals.
- the driving history is data that records the coordinates of the current location of the car navigation system every predetermined time, such as 1 second, and is useful for checking the situation when a malfunction occurs in the car navigation system.
- the user uploaded it to the center device.
- a service is also provided in which a travel history is used to superimpose a travel route on a map to assist in making memories of a trip.
- an external recording medium such as an SD card is connected to the car navigation system and output
- a communication device such as a mobile phone is connected to the car navigation system and uploaded to the center device via the communication network
- a method such as taking out from a car navigation system using a maintenance terminal is used at a dealer.
- there is no particular description about a method of collecting this travel history in the center device and the travel history is collected in the center device.
- a method for delivering a compressed travel history to various terminals will be described.
- Example 2 will be described focusing on differences from Example 1.
- the column direction data decompressing device 100 corresponds to a terminal for browsing a travel history
- the column direction data compression device 200 corresponds to a center device that distributes compressed travel history data.
- FIG. 19 is an overall configuration diagram of the travel history data browsing system according to the second embodiment.
- the overall configuration diagram of the second embodiment has a compressed data request unit 180 and a compressed data selection unit 280 added.
- the storage medium 250 stores a plurality of compressed data 510 to 530.
- the compression definition file 700 described in the first embodiment does not exist. This is because the driving history data is assumed to be composed of 8-byte fixed-length records, and there is no need to switch the compression method for each block.
- FIG. 20 shows an example of the format and data of the travel history data.
- One record of the travel history data is composed of an X coordinate (4 bytes) and a Y coordinate (4 bytes).
- the travel history data is composed of an array of XY coordinates collected in a predetermined cycle while the vehicle is traveling, and in the figure, an array of coordinates of 10 points is shown as an example.
- FIG. 21 shows an example in which the run history data included in the original data 610 is arranged in hexadecimal and an example of the compressed data in the column 00 included in the compressed data 510.
- line breaks are described in units of 8 bytes, which is the size of one record, for easy understanding.
- the content to be noted here is that the X byte and the Y coordinate rarely store a large numerical value that uses 4 bytes, so the upper byte is almost a small value such as 0 or 1. It is a point. Therefore, similarly to the tree data described in the first embodiment, an improvement in the compression rate can be expected by compressing the data in the column direction.
- FIG. 22 shows compressed data 510 to 530 stored in the storage medium 250.
- the compressed data 510 is compressed data for a column-direction data decompression device having a cache memory capacity of 8 KB
- the compressed data 520 is compressed data for a column-direction data decompression device having a cache memory capacity of 16 KB
- the compressed data 530 has a cache memory capacity. This is compressed data for a column direction data decompression device of 32 KB.
- FIG. 23 shows the details of the compressed data 510 for the column-direction data decompressing device having a cache memory capacity of 8 KB (the numerical value in parentheses means the size before compression).
- the number of records that can be stored in 4 KB, which is half the cache memory capacity 8 KB (the size of one record is 8 bytes) is 512 records, and therefore the size of the subblock is 4096 bytes, which is 512 records ⁇ 8 bytes.
- the size of each column included in the sub-block is 512 bytes.
- FIG. 24 shows the details of the compressed data 520 for the column-direction data decompressing device having a cache memory capacity of 16 KB (the numerical value in parentheses means the size before compression).
- the number of records that can be stored in 8 KB, which is half the cache memory capacity 16 KB (the size of one record is 8 bytes) is 1024 records, and therefore the size of the sub-block is 8192 bytes, which is 1024 records ⁇ 8 bytes.
- the size of each column included in the sub-block is 1024 bytes.
- FIG. 25 shows the details of the compressed data 530 for the column-direction data decompressing device having a cache memory capacity of 32 KB (the numerical value in parentheses means the size before compression).
- the number of records that can be stored in 16 KB, which is half the cache memory capacity of 32 KB (the size of one record is 8 bytes) is 2048 records, and therefore the size of the sub-block is 16384 bytes, which is 2048 records ⁇ 8 bytes.
- the size of each column included in the sub-block is 2048 bytes.
- Example 2 will be described along the flow of distributing the travel history data.
- FIG. 26 shows a unit size setting screen 238 displayed by the unit size setting unit 230 when the travel history data is compressed using the column direction data compression apparatus 200.
- the unit size setting screen 238 includes fields for inputting the target file 232 and the block size 234 as in the first embodiment. The difference from the first embodiment is that a record length 236 and a button 237 for specifying a cache memory capacity to be supported are added, and a column for inputting the compression definition file 700 does not exist.
- the button 237 for specifying the cache memory capacity to be supported is for specifying the cache memory capacity of the column-direction data decompressing device for browsing the travel history data.
- FIG. 27 is a flowchart showing the operation of the block data compression unit 220 after the OK button 239 is pressed on the unit size setting screen 238.
- the block data compression unit 220 acquires the type of cache memory capacity to be supported, which is input to the unit size setting screen 238 (step S2221).
- step S2222 it is determined whether or not compressed data corresponding to all specified cache memory capacity types has been created (step S2222). If creation has not been completed, uncreated compressed data is created (step S2222). S2223).
- the flow of compressed data creation executed in step S2223 is the same as that shown in FIG.
- FIG. 28 is a flowchart showing the operation of the block data decompression unit 120 when data is requested from the application software execution unit 110.
- FIG. 28 is substantially the same as FIG. 15 of the first embodiment, except that the compressed data acquisition process is initialized before the start of a series of processes (step S1810), and the process of acquiring data for one block is performed. The difference is that it is via a communication network (step S1820).
- FIG. 29 shows a process of initializing the compressed data acquisition process and receiving one block of data between the compressed data requesting unit 180 and the compressed data selecting unit 280, which are executed in steps S1810 and S1820 of FIG. It shows the flow.
- step S1810 first, the name of the target file is transmitted from the compressed data request unit 180 to the compressed data selection unit 280 (step S1811).
- the compressed data selection unit 280 notifies the compressed data request unit 180 of the cache memory capacity supported for the target file (step S1812).
- the target file is notified that the compressed data for the column-direction data decompression device having the cache memory capacity of 8 KB, 16 KB, and 32 KB can be transmitted.
- the compressed data request unit 180 notifies the compressed data selection unit 280 of the capacity of the cache memory 170 (step S1813).
- the compressed data selection unit 280 notifies the compressed data request unit 180 that the designated compressed data can be transmitted (step S1814).
- step S1812 if the cache memory capacity notified from the compressed data selection unit 280 does not match the capacity of the cache memory 170, the compressed data request unit 180 displays a warning.
- FIG. 30 shows an example of the application software execution screen 111 that displays this warning, and describes a message 112 that informs the user that the received compressed data is not optimal for this column-direction data decompression device. Is.
- the compressed data request unit 180 continues the process as it is. Processing may be stopped.
- Step S1821 and the subsequent steps in FIG. 29 show a flow of transmitting and receiving compressed data for one block in step S1820 in FIG. 28.
- the compressed data of the block corresponding to the designated block number is transmitted from the compressed data selection unit 280 to the compressed data request unit 180 (step S1822).
- the compressed data request unit 180 passes the received block to the block data decompression unit 120, performs decompression processing in the same procedure as in the first embodiment, and delivers the decompressed data to application software. The same applies to the subsequent blocks.
- the above is the flow of data compression processing and data decompression processing in the travel history data browsing system of the second embodiment.
- FIG. 31 is an overall configuration diagram of the travel history data browsing system according to the third embodiment.
- the overall configuration diagram of the third embodiment is a block data recompression unit 291, a column data recompression unit 292, a block data decompression unit 293, and a column data decompression unit. 294, a main storage device 260, and a cache memory 270 are added.
- the compressed data stored in the storage medium 250 is one of the compressed data 540. Further, the compressed data selection unit 280 does not exist.
- the travel history data compression process in the third embodiment is basically the same as that in the second embodiment.
- the generated compressed data is one of the compressed data 540, and this data is the compressed data having the highest decompression performance for the cache memory 270 provided in the column-direction data compression apparatus 200 itself. That is, if the capacity of the cache memory 270 is 32 KB, the contents of the compressed data 540 are the same as the compressed data shown in FIG.
- the communication sequence between the column direction data compression device 200 and the column direction data decompression device 100 is the same as that in FIG. 29 of the second embodiment.
- the capacity of the cache memory 170 of the column direction data decompression apparatus 100 matches the capacity of the cache memory 270. Find out what to do.
- the compressed data 540 is transmitted. If the capacities match, the compressed data 540 is decompressed by the block data decompressing unit 293 and the column data decompressing unit 294, and then the block data recompressing unit 291 and the column In the data recompression unit 292, the data is recompressed and transmitted in accordance with the request content from the column direction data decompression apparatus 100.
- the operation of the block data decompressing unit 293 is the same as the block data decompressing process in the column direction data decompressing apparatus 100 shown in FIG. 15, and the operation of the column data decompressing unit 294 is the same as the column direction data decompressing apparatus shown in FIG. This is the same as the column data decompression processing at 100.
- the operation of the block data recompression unit 291 is the same as the block data compression process shown in FIG. 11, and the operation of the column data recompression unit 292 is the same as the column data compression process shown in FIG.
- the third embodiment it is not necessary to hold a plurality of compressed data as in the second embodiment, and a single compressed data may be held.
- the column data decompressing unit 294 and the compression / decompression process in the column data recompression unit 292 may be executed in parallel for each column using a plurality of processing devices.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Memory System Of A Hierarchy Structure (AREA)
Abstract
データ圧縮装置は、固定長レコードの並びを列方向に圧縮する際、データ解凍装置のキャッシュメモリ容量やアプリケーションソフトが使用可能な主記憶装置の容量等、解凍装置側の性能と1レコードのサイズから1回の列方向圧縮で処理する行数を算出することにより、解凍装置の性能に合わせたデータ圧縮を行う。これにより、多数の固定長レコードの並びを含む大容量データの圧縮率を向上しつつ、解凍性能を向上させる。
Description
開示される主題は、複数の固定長レコードの並びが圧縮されたデータを高速に解凍する技術に関するものである。
カーナビゲーションシステム(以下、カーナビとする)は、地図データを加工してユーザーに交通案内情報を提供するものである。この地図データの記憶媒体として従来はHDD(Hard Disk Drive)を使用している機種が多かったが、近年はSDカードやSSD(Solid State Drive)等の半導体素子メモリを用いた機種が主流になりつつある。
半導体素子メモリは、従来のHDDと比較して、消費電力が少ない、耐衝撃性に優れている等の利点がある一方、容量あたりの単価が高いという欠点がある。そのため、従来と同程度の価格帯でユーザーにカーナビを提供するためには、使用する半導体素子メモリの容量を少なくする必要がある。これに対して、カーナビが動作するために必要なデータの内容は、記憶媒体がHDDでも半導体素子メモリでも変わりはなく、また、新しい道路や施設の整備等によりデータベースのサイズは年々増加する傾向にあるため、カーナビに収録するデータのサイズを削減する技術が常に望まれている。この、データのサイズを削減する技術として、以下の技術が提案されている。
まず、データの内容を変えずにデータサイズを削減するために一般的に用いられる方法として、特許文献1に記載されているデータ圧縮技術がある。データ圧縮技術は、容易にデータサイズを削減することが可能であるため、特許文献1に記載の技術の他、多数の圧縮方法が提案され、広く実用に供されている。
また、データサイズを削減する別の技術として、特許文献2に記載の技術がある。この技術は、データが2次元のテーブル状の構造を有している場合に、テーブルの各列に着目して所定の手順で辞書を作成し、この辞書を利用することにより列単位で圧縮してデータサイズを削減するものである。なお、このように圧縮対象のデータが行と列からなる二次元の構造を有する場合、単純にデータ(バイト列)を先頭から行方向に処理するよりも、列単位でデータを圧縮したほうが圧縮率の向上を期待できることは一般に知られており、例えば非特許文献1等、多数の文献において言及されている。
また、データサイズを削減する別の技術として、特許文献3に記載の技術がある。この技術は、カーナビのアプリケーションがデータベースにアクセスする形態として、データベース内の特定の位置へのランダムアクセスと、比較的大きなデータを参照する際のシーケンシャルアクセスが混在することに着目して、圧縮対象データを所定のブロック単位に分割して圧縮した上で、目的のデータへのランダムアクセスを可能にしつつ、あるブロックを参照した際に後続のブロックをメモリに先読みすることで、シーケンシャルアクセス時の性能向上も図ったものである。
B.R.Iyer、他1名 著,"Data Compression Support in Databases",In Proceedings of the 20th International Conference on Very Large Data Bases(VLDB94),(米国),1994,p.695-704
しかしながら、上記の特許文献1、特許文献2、および特許文献3に記載の技術には、以下の問題がある。
まず、特許文献1等に記載のデータ圧縮技術は、データを参照する前に、圧縮されたデータを元に戻す処理(以下、解凍処理と記載する)が必要になる。この解凍処理には時間がかかるため、単純にデータを圧縮してしまうと、データを参照して各種のナビゲーションを行う際の性能が悪化するという問題がある。
また、特許文献2等に記載されているような、列方向にデータを圧縮する技術の場合、たしかに圧縮率は向上するが、データが列単位で圧縮されているため、1行のデータを取り出すためには全ての列を解凍しなければならないという性能上の問題がある。この問題は、二次元構造のデータを列方向に圧縮する際の本質的な問題であるが、特に次の特許文献3のように、使用するメモリのサイズが小さい場合に問題が顕著となる。
特許文献3に記載の技術は、あるブロックのデータを参照した際に後続のブロックをキャッシュメモリに先読みすることによりシーケンシャルアクセス時の性能向上を図るものであるが、この効果を期待できるのは、キャッシュメモリに記憶している内容が解凍処理の途中で置き換わらない場合に限定される。例えば、特許文献2に記載の技術のようにデータが列方向に圧縮されている場合、前述したように、1行のデータを取り出すためには全ての列を解凍する必要があり、この全ての列の解凍結果(すなわちデータの全体に相当する)を保持するために必要な領域のサイズはキャッシュメモリの容量を大幅に超過するため、CPU(Central Processing Unit)が解凍結果を保持する領域を参照する際に、先読みした圧縮データはキャッシュメモリから削除されてしまう。その結果、圧縮データはキャッシュメモリからではなく主記憶装置やHDD等のより低速な記憶媒体から読み直されることになるため、先読みの効果は得られない。以上述べたように、多数の固定長レコードの並びを含む大容量データの圧縮率を向上しつつ、解凍性能を向上することが求められている。
上記の課題を解決するため、本明細書では、複数の固定長レコードの並びを列方向に(複数レコードの同一列データを列毎に)圧縮する際、キャッシュメモリ容量等、解凍装置側の性能指標と1レコードのサイズに基づいて、1回の列方向圧縮において処理する行数を算出することにより、解凍装置の性能に合わせたデータ圧縮を行うことを最も主要な特徴とする技術が開示される。なお、以降では1列の幅を1バイトとして説明するが、本明細書で開示される技術は、列幅が1バイトより大きい場合にも応用可能である。
開示される具体的な例では、32KBのキャッシュメモリを有する解凍装置向けに、1レコードが12バイトである固定長レコードの並びを圧縮する場合には、キャッシュメモリ32KBのうち半分の16KBを圧縮データ読み込み用として考え、この16KBに収まる最大のレコード数である1365レコード(=65536÷12)を1回の列方向に圧縮する単位とする。これによって、圧縮データを解凍する際のキャッシュメモリの不要な更新が抑制され、解凍処理を高速に行うことが可能となる。
なお、上記は一例であり、1回の列方向圧縮を行うレコード数の算出方法としては、解凍装置のキャッシュメモリ容量の他、解凍装置が使用可能な主記憶装置の容量や、あるいは、解凍装置が通信ネットワークを介して圧縮データを受信する場合は、通信プロトコルによる1回の最大データ送信サイズを使用しても良い。
また、本明細書で開示される技術は、性能指標が異なる各種の解凍装置に対して通信ネットワークを介して配信サーバから圧縮データを配信するシステムにおいて、あらかじめ各解凍装置の性能に適合する複数の圧縮データを作成しておき、要求を行った解凍装置の性能に適合する圧縮データを選択して配信することを第二の特徴とする。例えば、データを閲覧する端末(本明細書で開示される解凍装置に相当)としては、PC(Personal Computer)の他に、携帯電話やスマートフォン等、性能が異なる各種の端末があり、これらの各端末においてそれぞれ解凍時間が最短となる圧縮データを配信することが可能となる。
なお、あらかじめ複数の圧縮データを作成しておくのではなく、あらかじめ作成された一種類の圧縮データを一旦解凍し、この解凍され復元されたデータを、圧縮データを要求する解凍装置固有の性能指標に応じて再圧縮して配信する構成としても良い。
以上の特徴を持つ技術として、本明細書では、複数の固定長レコードを含む圧縮対象データを圧縮するデータ圧縮装置であって、固定長レコードの1レコードのサイズと、データ解凍装置の仕様情報と、の入力を受け付ける単位サイズ設定部と、固定長レコードのサイズと、データ解凍装置の仕様情報と、に基づいて圧縮対象ブロックのサイズを決定し、各々の圧縮対象ブロックに含まれる複数の固定長レコードの同一列データを列毎に圧縮して圧縮列データを作成し、各々の圧縮列データを含む圧縮データを作成する列データ圧縮部と、を備えるデータ圧縮装置が開示される。
また、上記データ圧縮装置によって圧縮された複数の固定長レコードを含む圧縮データを解凍するデータ解凍装置として、圧縮データが、圧縮対象データが所定の圧縮対象ブロックサイズ単位で分割され、圧縮対象ブロック毎に圧縮された結果を含んだものであり、圧縮対象ブロックサイズが、固定長レコードのサイズと、当該データ解凍装置の仕様情報と、に基づいて決定されるものである場合に、固定長レコードのサイズと、データ解凍装置の仕様情報と、に基づいて圧縮対象ブロックのサイズを判定し、圧縮データから一以上の圧縮対象ブロックを取得し、圧縮対象ブロックに含まれる、複数の固定長レコードの同一列データを列毎に圧縮した結果である圧縮列データの各々を解凍し、複数の固定長レコードを復元する列データ解凍部と、を備えるデータ解凍装置が開示される。
開示される内容により、多数の固定長レコードの並びを含む大容量データの圧縮率を向上しつつ、解凍性能を向上することが可能となる。
以下、図1から図18を用いて、実施例1のツリーデータ圧縮システムについて説明する。
実施例1は、カーナビに格納するデータベースにおいて多くの領域を占めている検索データ(以降、ツリーデータと呼ぶ)を圧縮し、カーナビのデータベースのサイズを削減するものである。実施例1においては、列方向データ解凍装置100はカーナビに相当し、列方向データ圧縮装置200は、カーナビの記憶媒体150に格納するデータを作成するための装置(パーソナルコンピューター等)に相当する。
図1は、実施例1のツリーデータ圧縮システムの機能構成を示したものである。本システムは、列方向データ解凍装置100、列方向データ圧縮装置200を含んで構成される。実施例1での圧縮対象であるツリーデータは、列方向データ圧縮装置200において圧縮され、列方向データ解凍装置100の記憶媒体150にコピーされる。列方向データ解凍装置100では、アプリケーションソフトが、圧縮されたツリーデータを部分的に解凍しながら検索処理を実行する。
列方向データ解凍装置100は、アプリケーションソフトを実行するアプリケーションソフト実行部110、ブロック単位で圧縮されたデータを解凍するブロックデータ解凍部120、列方向に圧縮されたデータを解凍する列データ解凍部140、圧縮データ500を格納する記憶媒体150、主記憶装置160、およびキャッシュメモリ170を含んで構成される。
列方向データ圧縮装置200は、圧縮定義ファイル700を参照しながらブロック単位でデータを圧縮するブロックデータ圧縮部220、データ圧縮のパラメータを設定する単位サイズ設定部230、列方向にデータを圧縮する列データ圧縮部240、圧縮対象の元データ600および圧縮データ500を格納する記憶媒体250を含んで構成される。なお、実施例1とは直接の関係が無いため図示していないが、列方向データ圧縮装置200においても、列方向データ解凍装置100と同様、一連の処理を実行するための主記憶装置およびキャッシュメモリが存在する。
図1に示す各装置は、CPUと記憶装置とを備える一般的な計算機を用いて実現することができる。本実施例では、キャッシュメモリ170はCPUの内部に備わり、主記憶装置160は半導体メモリで構成され、記憶媒体150はHDDなどの磁気記録媒体や、主記憶装置160より低速で不揮発性のフラッシュメモリなどで構成されている、と想定している。
さらに、各装置を構成するそれぞれの処理部は、CPUが主記憶装置160や記憶媒体150に格納されているプログラムを実行することにより、上記計算機上に具現化される。各プログラムは、あらかじめ、上記計算機内の記憶装置に格納されていても良いし、必要なときに、入出力インタフェースと上記計算機が利用可能な媒体を介して、他の装置から上記記憶装置に導入されてもよい。媒体とは、たとえば、入出力インタフェースに着脱可能な記憶媒体、または通信媒体(すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号)を指す。
図2は、圧縮対象のツリーデータのフォーマットおよびデータの例を示したものである。ツリーデータの1レコードは12バイトで構成され、下位ノード(ツリーの子)のアドレス601(4バイト)、下位ノードのサイズ602(4バイト)、およびレコードの値603(4バイト)を格納している。図2に示すデータの例では、例えば1文字目が「A」の場合、続く2文字目には「B」と「D」があり、「B」に続く3文字目には「C」「E」「H」が存在することを意味している。
このようなツリーデータは、一般的なカーナビが備えている目的地名称等を入力する画面(英数字等の各文字を示すボタンが画面に表示されている)において使用されるもので、「A」が入力された時は「A」で始まる名称の2番目の文字(すなわち「B」「D」等)のボタンは押下可能にするが他の文字は押下できないようにする等の制御を行い、ユーザーが検索を行い易くするためのデータである。
図3は、元データ600に含まれるツリーデータの並びを16進数で表記した例、および圧縮データ500に含まれる列02の圧縮データの例を記載したものである。ツリーデータの例は、理解し易いように、1レコードのサイズである12バイト単位で改行して記載している。このようにデータが固定長レコードの並びで構成される場合、同一桁の値は特徴的なパターンを有することが多く、例えば列00および列01の値は全て00になっている。列02については、同じ値が複数連続しており、これをランレングス符号によって圧縮すると、01、01、02、04、03、06のようになる。この圧縮データの意味は、記号01が1個、記号02が4個、記号03が6個連続するということを示している。なお、ランレングス符号は、記号と、その記号が連続する数を使ってデータを表現する圧縮方法であり、多数の文献で開示されているものである。
また、列08および列09は、ツリーデータの各ノードに対応する文字を、1文字が2バイトであるUNICODE(UTF16)で格納しており、1レコード目の「0041」は文字「A」に、2レコード目の「0042」は文字「B」に対応する。使用する文字が英数字のみである場合、UTF16のコードでは、列08(上位バイト)は全て00になる。
なお、図2および図3では、英数字による名称を持つ検索データの例を記載したが、本実施例は英数字を使用する場合に限るものではなく、日本語、ドイツ語、フランス語等、その他の言語の文字に対しても応用可能である。
ここで、本実施例の背景についての理解の一助とするため、このようにデータを列方向で圧縮する際の問題について図4および図5を用いて説明する。
図4は、近年、一般的に用いられている、セットアソシアティブと呼ばれる方式に基づいたキャッシュメモリ170の例を示したものである。一般的にキャッシュメモリ170は、一定サイズのデータ(これをラインと呼ぶ)を格納する複数の領域(これをエントリと呼ぶ)を含んで構成され、特にセットアソシアティブ方式とは、タグを用いて同一エントリに複数のラインを格納する方式である。同一エントリに格納できるラインの数をウェイ数と呼び、同一エントリに4つのラインを格納可能な場合を4ウェイセットアソシアティブ方式と呼ぶ。
図4は、1ラインサイズが32バイトで、256エントリを有する、4ウェイセットアソシアティブ方式の例を記載したものであり、エントリとして仮想アドレスの第5ビット目から第12ビット目に対応する8ビットを、タグとしてアドレスの第13ビット目から第31ビット目に対応する19ビットを使用する方式の例である。図4の例では、ウェイ数(すなわち4個)の列を持つタグアレイ171とデータアレイ172を記載している。データアレイ172は、各エントリに格納している4つのラインを保持しているテーブルであり、タグアレイ171は、各エントリに対して、データアレイ172に格納されているデータがどのアドレスのものかを示すタグを格納するものである。
ここで、仮想アドレス(32ビット値)0x00012041に位置するデータへの参照が発生した場合を例に、キャッシュメモリ170の動作を説明する。まず、仮想アドレスの第5ビット目から第12ビット目に格納されている8ビットの値からエントリを決定する(ステップS1701)。第5ビット目から第12ビット目に格納されている値は2進数表現で00000010、すなわち10進数の2であり、データがキャッシュメモリ170上にある場合はエントリ2に格納されていることを意味する。
次に、仮想アドレスの第13ビット目から31ビット目に格納されている19ビット(タグ)を、タグアレイ171のエントリ2に含まれる4つのタグと比較する(ステップS1702)。例の場合、エントリ2、ウェイ3に同一のタグが格納されており、このことから、エントリ2のウェイ3に仮想アドレス0x00012041を含むラインのデータが保持されていることが識別される。この状態がいわゆるキャッシュにヒットした状態であり、CPUは主記憶装置160にアクセスすることなく、高速なキャッシュメモリ170からの出力で処理を完了することができる(ステップS1703)。
一方で、タグアレイ171を参照した結果、仮想アドレスと一致するタグが見つからない場合がいわゆるキャッシュミスヒットであり、主記憶装置160からデータが読み込まれることになる。この場合、一般的に用いられる方式としては、エントリ2に含まれる4つのラインのうち、LRU(Least Recently Used)方式によって、最近最も参照されていないラインがキャッシュメモリ170から削除され、その場所に新たに主記憶装置160から読み込まれたラインが格納される。このようなラインの入れ替えが頻繁に発生すると、CPUによるデータへのアクセス性能が著しく低下することになる。
図5は、図4で示したキャッシュメモリ170に対して、1レコード12バイトの固定長レコードの並びを列方向に参照した場合の問題の例を記載したものである。「#n」を含む四角形は1レコード(12バイト)を意味するもので、nはレコードの参照順序である。黒い四角形は、列00(1バイト)の場所を示したものであり、各レコードの先頭に位置している。図には、1366番目のレコードを参照した時点でウェイ1およびウェイ2に保持されている内容を記載している。例えばウェイ1のエントリ0には、レコード#1(12バイト)、#2(12バイト)、およびレコード#3の先頭8バイトが格納されている。続くエントリ1には、レコード#3の続きである4バイト、レコード#4(12バイト)、#5(12バイト)、およびレコード#6の先頭4バイトが格納されている。
以降のエントリも同様である。
以降のエントリも同様である。
ここで、キャッシュメモリ170を構成する4ウェイのうち、元データを保持するのに使用できるウェイ数を2個とした場合、レコード#1367の列00を参照した時点でキャッシュミスヒットとなり、LRUによって、エントリ0のウェイ1が、#1367の列00を含むデータで置き換えられる。同様に、続く各エントリのデータも順次置き換えられていく。その後、各レコードの列00を参照する処理が終わり、列01を参照する処理が開始される際、再びレコード#1がキャッシュメモリ170に読み込まれる。すなわち、レコード#1について言えば、列00(1バイト)が処理されたのち、12バイトのうち残り11バイトは何ら参照されることなくキャッシュメモリ170から削除され、次に列01の処理においても残り10バイトは何ら参照されることなくキャッシュメモリ170から削除されており、キャッシュの利用効率が著しく悪いことになる。
なお、ウェイは4個あるため、実際はウェイ3およびウェイ4も使用されることになるが、CPUが参照するデータには、解凍された各レコードの他に、解凍する前の圧縮データや、圧縮解凍アルゴリズムが使用する作業領域があるため、解凍された各レコードの保持だけに全てのウェイを使用することは出来ない。また、仮に全てのウェイを使用できたとしても、格納できるレコード数が高々2倍になるだけであり、問題の本質的な解決にはならない。
以上の問題を踏まえて、以降、実施例1の詳細を説明する。
図6は、実施例1における圧縮データ500のフォーマットを記載したものである(括弧内の数値は圧縮前のサイズを意味する)。圧縮データ500は、元データを所定のサイズ(図では64KB)のブロックに分割して圧縮を行ったもので、各ブロックの開始アドレスを示すインデックスデータ501、および圧縮対象である各ブロックの並びであるブロックデータの並び502を含んで構成される。
ブロックの詳細503は、各ブロックに含まれる圧縮対象データを記載したものであり、圧縮識別子、レコード長、サブブロックの並び、および余りデータで構成される。サブブロックは、上記で説明した問題が発生しないサブブロックサイズでブロックを分割して圧縮対象ブロックとしたものであり、図では各ブロックを16380バイト(レコード数1365個に相当するサイズ)毎に分割した圧縮対象ブロックを圧縮したデータであり、余りデータは、サブブロックサイズ(ここでは16380バイト)で割り切れない余りデータ(ここでは16バイト)である。
サブブロックの詳細504は、各サブブロックに含まれるデータを記載したものであり、複数の列圧縮識別子および列圧縮データを含んで構成される。例えば列00圧縮データは、1365個のレコードにおける列00の値を圧縮したものであり、元のデータサイズは1365バイトである。
図7は、ブロックの詳細503に含まれる圧縮識別子122の値を記載したものである。圧縮識別子122は、各ブロックを圧縮する際の方式を示すもので、00(非圧縮)、01(列方向圧縮)、02(行方向圧縮)が定義される。00(非圧縮)は、圧縮対象のブロックに含まれるデータに何ら規則性がなく、圧縮してもサイズ削減効果を得られない場合に使用する識別子であり、01(列方向圧縮)は列方向で圧縮した場合にサイズ削減効果を得られる場合に使用する識別子であり、02(行方向圧縮)は行方向、すなわち通常どおりデータを先頭から1バイトずつ処理したほうがサイズ削減効果を得られる場合に使用する識別子である。
図8は、サブブロックの詳細504に含まれる列圧縮識別子142の値を記載したものである。列圧縮識別子142は、圧縮対象の各列を圧縮する際の方式を示すもので、00(非圧縮)、01(ランレングス符号)、02(固定長ビット符号)、03(ハフマン符号)等を定義する。00(非圧縮)は、圧縮対象の列に含まれるデータに何ら規則性がなく、圧縮してもサイズ削減効果を得られない場合に使用する識別子であり、01(ランレングス符号)は圧縮対象の列に含まれるデータに対してランレングス符号による圧縮を行うことによりサイズ削減効果を得られる場合に使用する識別子である。02(固定長ビット符号)、03(ハフマン符号)についても同様で、それぞれの方式によってサイズ削減効果を得られる場合に使用する識別子である。
なお、固定長ビット符号とは、例えば8ビットの記号を圧縮する際、元データに含まれる記号が高々16個しか存在しない場合に、16個を表現可能な4ビットの符号に置換して出力することによりデータサイズを削減する方式である。また、ハフマン符号とは、記号の出現確率を求めて最小冗長符号を出力することによりデータサイズを削減する方式である。実施例1は、各列の圧縮を行う際、最もサイズ削減効果が高い圧縮方法を選択して使用するものであり、一般的に使用されている技術をそのまま利用することを想定しているため、各圧縮方法の詳細については特に記載しない。
図9は、ブロックデータ圧縮部220がデータを圧縮する際に参照する圧縮定義ファイル700について記載したものである。圧縮定義ファイル700には、開始アドレス701、圧縮識別子702、レコード長703が記載されている。一般的に、カーナビのデータベースにおいて、1つのファイルに含まれるデータがすべて同一のサイズを有する固定長レコードの並びであることは稀であり、固定長レコードの並びの他に、何ら規則性が無いデータや、通常のテキストデータのように列方向の圧縮に適さないデータも含まれる。図9は、アドレス0x00000000からは1レコード12バイトである固定長レコードの並びが格納されており、同様に、アドレス0x001A0000からは何ら規則性が無いデータが、アドレス0x001B0000からは1レコード8バイトである固定長レコードの並びが、アドレス0x00300000からはテキストデータが、アドレス0x00310000からは何ら規則性が無いデータが格納されている様子を示している。圧縮定義ファイルは、これらの格納状況を踏まえ、ブロックデータ圧縮部220がデータを圧縮する際、各ブロックに適用する圧縮方法を決定するために使用される。
以降、ツリーデータを圧縮してカーナビに格納し、カーナビにおいて圧縮されたツリーデータを参照する際の処理の流れに沿って、実施例1を説明する。
図10は、列方向データ圧縮装置200を用いてツリーデータを圧縮する際、単位サイズ設定部230が表示する単位サイズ設定画面231を示したものである。単位サイズ設定画面231には、対象ファイル232、圧縮定義ファイル233、ブロックサイズ234、および端末キャッシュ容量235を入力する欄が存在する。対象ファイル232は、記憶媒体250上で元データ600が位置する場所を入力する欄、圧縮定義ファイル233は、記憶媒体250上で圧縮定義ファイル700が位置する場所を入力する欄、ブロックサイズ234は図6に示した各ブロックのサイズ(圧縮前のサイズ)を入力する欄、端末キャッシュ容量235は、列方向データ解凍装置100が備えるキャッシュメモリ170の容量を入力する欄である。これらのパラメータを入力し、OKボタン239を押下することで圧縮処理が開始される。
図11は、OKボタン239が押下された後の、ブロックデータ圧縮部220の動作を示すフローチャートである。ブロックデータ圧縮部220は、まず、対象ファイル232に入力されたファイル(元データ)のサイズを取得する(ステップS2201)。
次に、ブロックサイズ234に入力されたブロックサイズをもとに、元データに含まれるブロック数を計算する(ステップS2202)。例えば、元データのサイズが67588096バイト、ブロックサイズが64KB(65536バイト)の場合、ブロック数は、67588096を65536で割った値(小数点以下切り上げ)であり、1032になる。なお、1032番目のブロックのサイズは、65536で割り切れない20480バイトになる。
次に、ブロック毎に繰り返されるループ処理のカウンタ変数iを0に初期化する(ステップS2203)。
次に、変数iが、ステップS2202で求めたブロック数未満であるかどうかを判定する(ステップS2204)。変数iがブロック数未満である場合、インデックスデータ501に、ブロックデータの並び502における処理中のブロックの開始アドレス(オフセットデータ)を出力する(ステップS2205)。
次に、圧縮定義ファイル700を参照して、処理中のブロックを圧縮する際に使用する圧縮識別子およびレコード長を取得する(ステップS2206)。これは、圧縮定義ファイルの各行を走査し、処理中のブロックのアドレスに対応する圧縮識別子およびレコード長を取得することにより行われる。
次に、ブロックデータの並び502に、取得した圧縮識別子およびレコード長を出力する(ステップS2207)。
次に、圧縮識別子に応じて処理を分岐させる(ステップS2208)。圧縮識別子が00(非圧縮)の場合、元データの内容(ブロック1からブロック1031の場合は64KB、ブロック1032の場合は20480バイト)をそのままブロックデータの並び502に出力する(ステップS2209)。圧縮識別子が01(列方向圧縮)の場合、列方向の圧縮を行う(ステップS2210)。列方向圧縮の詳細については後述する。圧縮識別子が02(行方向圧縮)の場合は、元データを行方向に圧縮(Zlib等の公知の圧縮アルゴリズムを使用)して、圧縮データをブロックデータの並び502に出力する(ステップS2211)。以上の3ステップのいずれかが完了した後、カウンタ変数iを1加算して、ステップS2204に戻る(ステップS2212)。以上のステップS2204からステップS2212までの処理を全てのブロックに対して繰り返し、ステップS2204において変数iがブロック数に等しくなった時点で、データの圧縮処理を終了し、圧縮データ500として記憶媒体250に格納する。
図12は、図11のステップS2210で実行される、列データ圧縮部240の動作を示すフローチャートである。列データ圧縮部240は、まず、端末キャッシュ容量235に入力されたキャッシュメモリ容量、および圧縮定義ファイルから取得されたレコード長をもとに、サブブロックサイズを計算する(ステップS2401)。例えば、キャッシュメモリ容量が32KB、1レコードのサイズが12バイトの場合、32KBのうち半分(16KB)が解凍後のデータ保持に使用可能であると想定して、16KBに格納できる最大のレコード数のサイズがサブブロックサイズになる。すなわち、16KB÷12バイト=16380バイト(余り4バイト)がサブブロックサイズとなる。
次に、ブロックサイズ234に入力されたブロックサイズと、ステップS2402で求めたサブブロックサイズから、サブブロック数と余り領域のサイズを計算する(ステップS2402)。ブロックサイズが65536バイト、サブブロックサイズが16380バイトであるので、サブブロック数は4、余り領域のサイズは16バイトとなる。
次に、サブブロック毎に繰り返されるループ処理のカウンタ変数jを0に初期化する(ステップS2403)。
次に、変数jがサブブロック数未満であるかどうかを判定する(ステップS2404)。変数jがサブブロック数未満である場合、レコードの各桁に対して繰り返されるループ処理のカウンタ変数kを0に初期化する(ステップS2405)。
次に、変数kがレコード長未満であるかどうかを判定する(ステップS2406)。変数kがレコード長未満である場合、列kの圧縮処理を行う(ステップS2408)。列kの圧縮処理については後述する。
次に、カウンタ変数kを1加算してステップS2406に戻る(ステップS2409)。
以上のステップS2406からステップS2409までの処理を全ての列に対して繰り返し、ステップS2406において変数kがレコード長に等しくなった時点で、カウンタ変数jを1加算して、ステップS2404に戻る(ステップS2407)。
以上の処理を各サブブロックに対して繰り返し、ステップS2404において変数jがサブブロック数に等しくなった時点で、残りの入力データ(すなわちステップS2402において算出した余り領域のサイズ分のデータ)を、ブロックデータの並び502にそのまま出力して、列データの圧縮処理を終了する(ステップS2410)。
図13は、図12のステップS2408で実行される、列kの圧縮処理を示すフローチャートである。まず、列kの圧縮に使用する列圧縮識別子を決定する(ステップS2421)。この処理は、列kに含まれる記号の出現頻度をカウントすることにより、00(非圧縮)、01(ランレングス符号)、02(固定長ビット符号)、03(静的ハフマン符号)のどの方式を用いれば圧縮後のサイズが最も小さくなるかを計算することにより行う。
次に、圧縮処理に使用する変数n、pSrc、pDestを初期化する(ステップS2422)。変数nは、処理済み入力データサイズ(バイト数)を示す変数であり、0に初期化する。変数pSrcは、元データのアドレスを示す変数であり、列kのデータの先頭アドレスで初期化する。変数pDestは、圧縮データの出力先アドレスで初期化する。次に、変数nが列kのサイズ(すなわち1365)未満であるかどうかを判定する(ステップS2423)。変数nが列kのサイズ未満である場合、変数pSrcが示すアドレスに存在する1バイトを、列圧縮識別子が示す方式でエンコードし、変数pSrcをレコード長だけ加算、および変数nを1加算する(ステップS2424)。エンコードされた結果が1バイト未満、かつ変数nが列kのサイズ未満である場合、ステップS2424に戻る。エンコードされた結果が1バイトになるか、または変数nが列kのサイズに等しい場合,ステップS2426へ進む(ステップS2425)。
pSrcによって示される1バイト以上の記号が、1バイトにエンコードされた時点で、エンコードされた値(1バイト)をpDestが示すアドレスに出力するとともに、pDestの値を1加算して、ステップS2423に戻る(ステップS2426)。以上のステップS2423からステップS2426までの処理を列kに含まれる記号の数だけ繰り返した結果、変数nの値が列kのサイズに等しくなった時点で、列kの圧縮処理を終了する。
以上の図11から図13を用いて説明したブロックデータ圧縮部220および列データ圧縮部240の動作によって、図6に示した圧縮データ500が作成される。このようにして作成された圧縮データ500は、列方向データ解凍装置100の記憶媒体150にコピーされ、アプリケーションソフトによって使用される。
図14は、実施例1における、アプリケーションソフト実行部110からブロックデータ解凍部120へ要求されるデータ取得要求の例を示したものである。この例では、アドレス0x00010000から始まる100KBのデータを参照する様子を示している。以降、この要求に対する列方向データ解凍装置100の動作に沿って説明する。
図15は、アプリケーションソフト実行部110からデータ取得要求を受けた際の、ブロックデータ解凍部120の動作を示すフローチャートである。ブロックデータ解凍部120は、まず、要求されたアドレスおよび要求サイズをもとに、対象のブロック範囲を計算する(ステップS1201)。図14に示した要求の場合、アドレス0x00010000から始まる100KBを含むブロックであるブロック2からブロック3が対象ブロックの範囲となる。
次に、対象ブロックの範囲から1ブロック分の圧縮データを記憶媒体150から読み込み、主記憶装置160に格納する(ステップS1202)。この処理は、インデックスデータ501が示すブロック2の開始アドレス0x00001520から、ブロック2の終了アドレス(次のブロック3の開始アドレスから1を減算した値)である0x00005043までを読み込むことにより行われる。
次に、読み込まれたブロックの先頭から、圧縮識別子およびレコード長を取得する(ステップS1203)。
次に、取得した圧縮識別子に応じて処理を分岐する(ステップS1204)。圧縮識別子が00(非圧縮)の場合、主記憶装置160に格納したブロックデータをそのままアプリケーションソフトに渡す(ステップS1205)。圧縮識別子が01(列方向圧縮)の場合、主記憶装置160に格納したブロックデータに対して列方向解凍処理を行う(ステップS1206)。列方向解凍処理の詳細は後述する。
圧縮識別子が02(行方向圧縮)の場合、主記憶装置160に格納したブロックデータに対して行方向の解凍処理(Zlib等の公知の圧縮アルゴリズムを使用)を行い、解凍し復元した結果を主記憶装置160に格納してアプリケーションソフトに渡す(ステップS1207)。
以上の3ステップのいずれかが実行されたのち、対象ブロックの範囲に含まれる全てのブロックの解凍処理が完了したかどうかを判定し、まだ解凍されていないブロックがある場合はステップS1202に戻る(ステップS1208)。
S1202に戻った後の処理は上記と同様であり、ブロック3のデータに対しては、インデックスデータ501の内容からブロック3の格納アドレス(0x00005044から0x00008212)を取得し、ブロック3のデータを読み込み、解凍処理を行う。以上の処理を繰り返した結果、ステップS1208において全てのブロックの解凍が完了したと判定された場合、ブロックデータの解凍処理を終了する。
図16は、図15のステップS1206で実行される、列データ解凍部140の動作を示すフローチャートである。列データ解凍部140は、まず、キャッシュメモリ170の容量から、サブブロックサイズを計算する(ステップS1401)。この計算処理は、列方向データ圧縮装置200におけるサブブロックサイズの計算処理と同一の計算式によってなされる。すなわち、キャッシュメモリ容量が32KB、1レコードのサイズが12バイトの場合、32KBのうち半分(16KB)が解凍後のデータ保持に使用可能であると想定して、16KBに格納できる最大のレコード数のサイズ(16380バイト)がサブブロックサイズになる。
次に、処理中のブロックに含まれるサブブロック数および余りサイズを計算する(ステップS1402)。この計算処理も、列方向データ圧縮装置200におけるサブブロック数の計算処理と同一であり、サブブロック数は4、余りサイズは16バイトになる。
次に、各サブブロックに対して繰り返されるループ処理のカウンタ変数jを0に初期化する(ステップS1403)。
次に、変数jがサブブロック数未満であるかどうかを判定する(ステップS1404)。変数jがサブブロック数未満である場合、各列に対して繰り返されるループ処理のカウンタ変数kを0に初期化する(ステップS1405)。
次に、変数kがレコード長未満であるかどうかを判定する(ステップS1406)。変数kがレコード長未満である場合、列kのデータを解凍する(ステップS1408)。列kの解凍処理の詳細は後述する。
次に、カウンタ変数kを1加算して、ステップS1406に戻る(ステップS1409)。ステップS1406からステップS1409の処理を各列に対して繰り返した結果、変数kがレコード長に等しくなった場合は、カウンタ変数jを1加算して、ステップS1404に戻る(ステップS1407)。
以上の処理を各サブブロックに対して繰り返した結果、変数jの値がサブブロック数に等しくなった場合は、余り領域をそのままアプリケーションソフトに返却する(ステップS1410)。
図17は、図16のステップS1408において実行される、列kのデータの解凍処理を示すフローチャートである。まず、圧縮データの先頭から、列圧縮識別子を取得する(ステップS1421)。
次に、解凍処理に用いる変数n、pSrc、pDestを初期化する(ステップS1422)。変数nは、出力したデータサイズ(バイト数)を示す変数であり、0に初期化される。変数pSrcは、圧縮データの格納アドレスを示す変数であり、圧縮データの先頭アドレス、または、直前の列k-1の解凍が終了した時点でのpSrcの値に初期化される。変数pDestは、列kの場合、解凍データ出力先の先頭アドレス+k(列幅が1バイトの場合)に初期化される。
次に、変数が列kのサイズ(すなわち1365)未満であるかどうかを判定する(ステップS1423)。
変数nが列kのサイズ未満である場合、変数pSrcが示すアドレスに存在する1バイトを列圧縮識別子が示す方式でデコードし、変数pSrcを1加算する(ステップS1424)。
通常、1バイトからは1以上のバイト数のデータがデコードされるため、変数pDestの位置にデコードされた1バイトを出力し、pDestの値をレコード長だけ加算するとともに、変数nを1加算する処理を繰り返す(ステップS1425)。
圧縮データ1バイトからデコードされる複数のバイトの出力が完了した後、ステップS1423に戻る(ステップS1426)。
以上のステップS1423からステップS1426までの処理を繰り返した結果、変数nの値が列kのサイズに等しくなった場合は、列kのデータの解凍処理を終了する。
以上の図15から図17で説明したブロックデータ解凍部120および列データ解凍部140の動作によって、アプリケーションソフト実行部から要求された位置にある圧縮データの解凍が行われる。
以上が、実施例1のツリーデータ圧縮システムにおけるデータ圧縮処理およびデータ解凍処理の流れである。なお、図18は、実施例1による圧縮データの解凍処理における、キャッシュメモリ170の状態を示したものである。列00の参照によってレコード#1からレコード#1365までがキャッシュメモリ170に格納される状態は図5と同一であるが、レコード#1365まで処理した後に、列01の解凍処理を実行するため、キャッシュメモリ170上のエントリ0の内容は置き換わらない。すなわち、図16および図17に示した処理の実行において、キャッシュメモリ170の不要な更新が抑制されるため、圧縮されたデータを高速に解凍することが可能となる。
以下、図19から図30を用いて、実施例2の走行履歴データ閲覧システムについて説明する。実施例2は、カーナビの走行履歴データをセンタ装置に収集し、各種の端末から参照可能にするものである。走行履歴とは、カーナビの現在地の座標を1秒等の所定の時間毎に記録したデータであり、カーナビで不具合が発生した時の状況確認に役立つほか、近年では、ユーザーがセンタ装置にアップロードした走行履歴を用いて、地図上に走行経路を重畳描画して旅の思い出作りを支援するといったサービスも提供されている。
なお、走行履歴データを収集する方法としては、SDカード等の外部記録媒体をカーナビに接続して出力する、携帯電話等の通信装置をカーナビに接続して通信ネットワーク経由でセンタ装置へアップロードする、ディーラーにおいて保守端末を用いてカーナビから取り出す等の方法が用いられているが、本実施例では、この走行履歴をセンタ装置に収集する方法については特に記載せず、センタ装置に走行履歴が収集されていることを前提に、圧縮された走行履歴を各種の端末に配信する方法について説明する。
以降、実施例1との差異を中心に実施例2を説明する。実施例2において、列方向データ解凍装置100は走行履歴を閲覧する端末、列方向データ圧縮装置200は、圧縮された走行履歴データを配信するセンタ装置に相当する。
図19は、実施例2における走行履歴データ閲覧システムの全体構成図である。実施例2の全体構成図は、図1に示した実施例1の全体構成図と比較して、圧縮データ要求部180および圧縮データ選択部280が追加されている。また、記憶媒体250には複数の圧縮データ510から530が格納されている。また、実施例1で記載した圧縮定義ファイル700は存在しない。これは、走行履歴データは8バイトの固定長レコードで構成されていることを想定しており、ブロック毎に圧縮方法を切り替える必要性が無いためである。
図20は、走行履歴データのフォーマットおよびデータの例を示したものである。走行履歴データの1レコードは、X座標(4バイト)およびY座標(4バイト)によって構成される。走行履歴データは、車両が走行中に所定のサイクルで収集したXY座標の並びによって構成されており、図では、例として10地点の座標の並びを示している。
図21は、元データ610に含まれる走行履歴データの並びを16進数で表記した例、および圧縮データ510に含まれる列00の圧縮データの例を記載したものである。走行履歴データの例は、理解し易いように、1レコードのサイズである8バイト単位で改行して記載している。ここで着目すべき内容は、X座標およびY座標のそれぞれについて、4バイトを使用するほどの大きな数値が格納されることは滅多に無いため、上位バイトはほとんど0または1等の小さな値になっている点である。したがって、実施例1で記載したツリーデータと同様に、列方向にデータを圧縮することで圧縮率の向上を期待できる。
図22は、記憶媒体250に格納される、圧縮データ510から530を示したものである。圧縮データ510はキャッシュメモリ容量が8KBである列方向データ解凍装置用の圧縮データ、圧縮データ520はキャッシュメモリ容量が16KBである列方向データ解凍装置用の圧縮データ、圧縮データ530はキャッシュメモリ容量が32KBである列方向データ解凍装置用の圧縮データである。
図23は、キャッシュメモリ容量が8KBである列方向データ解凍装置用の圧縮データ510の詳細を示したものである(括弧内の数値は圧縮前のサイズを意味する)。キャッシュメモリ容量8KBの半分である4KBに格納可能なレコード数(1レコードのサイズは8バイト)は512レコードであり、したがってサブブロックのサイズは512レコード×8バイトである4096バイトになる。サブブロックに含まれる各列のサイズは、512バイトになる。
図24は、キャッシュメモリ容量が16KBである列方向データ解凍装置用の圧縮データ520の詳細を示したものである(括弧内の数値は圧縮前のサイズを意味する)。キャッシュメモリ容量16KBの半分である8KBに格納可能なレコード数(1レコードのサイズは8バイト)は1024レコードであり、したがってサブブロックのサイズは1024レコード×8バイトである8192バイトになる。サブブロックに含まれる各列のサイズは、1024バイトになる。
図25は、キャッシュメモリ容量が32KBである列方向データ解凍装置用の圧縮データ530の詳細を示したものである(括弧内の数値は圧縮前のサイズを意味する)。キャッシュメモリ容量32KBの半分である16KBに格納可能なレコード数(1レコードのサイズは8バイト)は2048レコードであり、したがってサブブロックのサイズは2048レコード×8バイトである16384バイトになる。サブブロックに含まれる各列のサイズは、2048バイトになる。
なお、圧縮データ510から530のいずれも、キャッシュメモリ容量がレコードサイズの倍数となっているため、図6に存在している余り領域は存在しない。
以降、走行履歴データを配信する流れに沿って、実施例2を説明する。
図26は、列方向データ圧縮装置200を用いて走行履歴データを圧縮する際、単位サイズ設定部230が表示する単位サイズ設定画面238を示したものである。単位サイズ設定画面238には、実施例1と同様に、対象ファイル232、ブロックサイズ234を入力する欄がある。実施例1との差異は、レコード長236およびサポートするキャッシュメモリ容量を指定するボタン237が追加されており、また、圧縮定義ファイル700を入力する欄は存在しない点である。サポートするキャッシュメモリ容量を指定するボタン237は、走行履歴データを閲覧する列方向データ解凍装置のキャッシュメモリ容量を指定するものであり、例では、キャッシュメモリ170のサイズが、それぞれ8KB、16KB、および32KBである複数の端末用の圧縮データを作成する設定を示している。図27は、単位サイズ設定画面238においてOKボタン239が押下された後の、ブロックデータ圧縮部220の動作を示すフローチャートである。ブロックデータ圧縮部220は、まず、単位サイズ設定画面238に入力された、サポートするキャッシュメモリ容量の種別を取得する(ステップS2221)。
次に、指定されたすべてのキャッシュメモリ容量の種別分の圧縮データを作成したかどうかを判定し(ステップS2222)、作成が完了していない場合は、未作成である圧縮データを作成する(ステップS2223)。ステップS2223において実行される圧縮データ作成の流れは、実施例1の図11に示した内容と同一である。
以上の動作によって、キャッシュメモリ170の容量が異なる各列方向データ解凍装置用の圧縮データが作成される。
図28は、アプリケーションソフト実行部110からデータを要求された時の、ブロックデータ解凍部120の動作を示すフローチャートである。図28は、実施例1の図15とほぼ同様であるが、一連の処理の開始の前に圧縮データ取得処理初期化を行う点と(ステップS1810)、1ブロック分のデータを取得する処理が通信ネットワーク経由になっている点が異なる(ステップS1820)。
図29は、図28のステップS1810およびステップS1820において実行される、圧縮データ要求部180と圧縮データ選択部280の間における、圧縮データ取得処理初期化と、1ブロック分のデータを受信する処理の流れを示したものである。ステップS1810においては、まず、圧縮データ要求部180から圧縮データ選択部280へ、対象ファイルの名称が送信される(ステップS1811)。これを受けて、圧縮データ選択部280から圧縮データ要求部180へ、対象ファイルについてサポートしているキャッシュメモリ容量が通知される(ステップS1812)。実施例2の場合、対象ファイルについて、8KB、16KB、および32KBのキャッシュメモリ容量を有する列方向データ解凍装置向けの圧縮データを送信可能であることが通知される。これを受けて、圧縮データ要求部180から圧縮データ選択部280へ、キャッシュメモリ170の容量が通知される(ステップS1813)。これを受けて、圧縮データ選択部280から圧縮データ要求部180へ、指定された圧縮データを送信可能な状態になったことが通知される(ステップS1814)。
なお、ステップS1812において、圧縮データ選択部280から通知されたキャッシュメモリ容量の中に、キャッシュメモリ170の容量と合致するものがなければ、圧縮データ要求部180は警告を表示する。図30は、この警告を表示するアプリケーションソフト実行画面111の例を示したものであり、受信した圧縮データがこの列方向データ解凍装置にとって最適なものではないことをユーザーに伝えるメッセージ112を記載したものである。実施例2では、このような場合でも解凍性能が低下するだけで解凍処理自体を続行することは可能のため、圧縮データ要求部180はそのまま処理を続行することを想定しているが、ここで処理を停止するとしても良い。
図29のステップS1821以降は、図28のステップS1820における、1ブロック分の圧縮データを送受信する流れを示したものであり、まず、圧縮データ要求部180から圧縮データ選択部280へ、必要なブロックの番号が送信される(ステップS1821)。これを受けて、圧縮データ選択部280から圧縮データ要求部180へ、指定されたブロック番号に対応するブロックの圧縮データが送信される(ステップS1822)。圧縮データ要求部180は、受信したブロックをブロックデータ解凍部120に渡し、実施例1と同様の手順で解凍処理が行った上で、解凍したデータをアプリケーションソフトに渡す。以降のブロックについても同様である。
以上が、実施例2の走行履歴データ閲覧システムにおけるデータ圧縮処理およびデータ解凍処理の流れである。このように、性能が異なる各種の端末向けにあらかじめ複数の圧縮データを用意しておくことで、各端末にとって最も高速にデータを閲覧可能となる圧縮データを提供することが可能となる。
以下、図31を用いて、実施例2とは別の形態の走行履歴データ閲覧システムについて説明する。
図31は、実施例3における走行履歴データ閲覧システムの全体構成図である。実施例3の全体構成図は、図19に示した実施例2の全体構成図と比較して、ブロックデータ再圧縮部291、列データ再圧縮部292、ブロックデータ解凍部293、列データ解凍部294、主記憶装置260、キャッシュメモリ270が追加されている。また、記憶媒体250に格納する圧縮データは、圧縮データ540の1つである。また、圧縮データ選択部280は存在しない。
以降、走行履歴データを圧縮して配信する際の処理の流れに沿って、実施例3を説明する。
実施例3における走行履歴データの圧縮処理は、実施例2と基本的に同様である。ただし、作成される圧縮データは、圧縮データ540の1つであり、このデータは、列方向データ圧縮装置200自身が備えるキャッシュメモリ270にとってもっとも解凍性能が高い圧縮データである。すなわち、仮にキャッシュメモリ270の容量が32KBであるなら、圧縮データ540の内容は図25に示した圧縮データと同様である。
また、列方向データ圧縮装置200と列方向データ解凍装置100の間の通信シーケンスについても、実施例2の図29と同様である。ただし、実施例3における列方向データ圧縮装置200では、列方向データ解凍装置100からの要求に対して、まず、列方向データ解凍装置100のキャッシュメモリ170の容量が、キャッシュメモリ270の容量に一致するかを調べる。
容量が一致すれば、圧縮データ540を送信し、一致しなければ、ブロックデータ解凍部293、および列データ解凍部294において圧縮データ540は解凍され、次に、ブロックデータ再圧縮部291、および列データ再圧縮部292において、列方向データ解凍装置100からの要求内容に従ってデータが再圧縮されて送信される。
ブロックデータ解凍部293の動作は、図15に示した列方向データ解凍装置100でのブロックデータ解凍処理と同様であり、列データ解凍部294の動作は、図16に示した列方向データ解凍装置100での列データ解凍処理と同様である。ブロックデータ再圧縮部291の動作は、図11に示したブロックデータ圧縮処理と同様であり、列データ再圧縮部292の動作は、図12に示した列データ圧縮処理と同様である。
以上の構成とすることにより、実施例3においては、実施例2のような複数の圧縮データを保持する必要がなく単一の圧縮データを保持すればよい。
なお、このような構成とする場合、圧縮データを一旦解凍して再圧縮する処理が加わるため、列方向データ圧縮装置200における処理時間が増加するが、これを削減するために、列データ解凍部294、および列データ再圧縮部292における圧縮解凍処理を、複数の処理装置を用いて列毎に並列に実行する構成としても良い。
100:列方向データ解凍装置、
110:アプリケーションソフト実行部、
120:ブロックデータ解凍部(列方向データ解凍装置)、
140:列データ解凍部(列方向データ解凍装置)、
150:記憶媒体(列方向データ解凍装置)、
160:主記憶装置(列方向データ解凍装置)、
170:キャッシュメモリ(列方向データ解凍装置)、
180:圧縮データ要求部、
200:列方向データ圧縮装置、
220:ブロックデータ圧縮部、
230:単位サイズ設定部、
240:列データ圧縮部、
250:記憶媒体(列方向データ圧縮装置)、
260:主記憶装置(列方向データ圧縮装置)、
270:キャッシュメモリ(列方向データ圧縮装置)、
280:圧縮データ選択部、
291:ブロックデータ再圧縮部、
292:列データ再圧縮部、
293:ブロックデータ解凍部(列方向データ圧縮装置)、
294:列データ解凍部(列方向データ圧縮装置)、
300:通信ネットワーク、
500:圧縮データ(実施例1)、
510:圧縮データ(実施例2、8KBキャッシュ用)、
520:圧縮データ(実施例2、16KBキャッシュ用)、
530:圧縮データ(実施例2、32KBキャッシュ用)、
540:圧縮データ(実施例3)、
600:元データ(実施例1)、
610:元データ(実施例2および実施例3)、
700:圧縮定義ファイル。
110:アプリケーションソフト実行部、
120:ブロックデータ解凍部(列方向データ解凍装置)、
140:列データ解凍部(列方向データ解凍装置)、
150:記憶媒体(列方向データ解凍装置)、
160:主記憶装置(列方向データ解凍装置)、
170:キャッシュメモリ(列方向データ解凍装置)、
180:圧縮データ要求部、
200:列方向データ圧縮装置、
220:ブロックデータ圧縮部、
230:単位サイズ設定部、
240:列データ圧縮部、
250:記憶媒体(列方向データ圧縮装置)、
260:主記憶装置(列方向データ圧縮装置)、
270:キャッシュメモリ(列方向データ圧縮装置)、
280:圧縮データ選択部、
291:ブロックデータ再圧縮部、
292:列データ再圧縮部、
293:ブロックデータ解凍部(列方向データ圧縮装置)、
294:列データ解凍部(列方向データ圧縮装置)、
300:通信ネットワーク、
500:圧縮データ(実施例1)、
510:圧縮データ(実施例2、8KBキャッシュ用)、
520:圧縮データ(実施例2、16KBキャッシュ用)、
530:圧縮データ(実施例2、32KBキャッシュ用)、
540:圧縮データ(実施例3)、
600:元データ(実施例1)、
610:元データ(実施例2および実施例3)、
700:圧縮定義ファイル。
Claims (17)
- 圧縮された複数の固定長レコードを含む圧縮データを解凍するデータ解凍装置であって、
前記圧縮データは、圧縮対象データが所定の圧縮対象ブロックサイズ単位で分割され、前記圧縮対象ブロック毎に圧縮された結果を含んだものであり、
前記圧縮対象ブロックサイズは、前記固定長レコードのサイズと、当該データ解凍装置の仕様情報と、に基づいて決定されるものである場合に、
前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて前記圧縮対象ブロックのサイズを判定し、
前記圧縮データから一以上の圧縮対象ブロックを取得し、
前記圧縮対象ブロックに含まれる、前記複数の固定長レコードの同一列データを列毎に圧縮した結果である圧縮列データの各々を解凍し、前記複数の固定長レコードを復元する列データ解凍部、を備えることを特徴とするデータ解凍装置。 - 請求項1に記載のデータ解凍装置であって、
さらに、ソフトウェアを実行するソフトウェア実行部を備え、
前記圧縮データは、前記圧縮対象ブロック毎に圧縮された結果であるサブブロックを一つ以上含んだブロックを一つ以上含んだものであり、
前記ソフトウェアが要求するデータを含む一つ以上の前記ブロック各々の解凍を制御するブロックデータ解凍制御部を含むことを特徴とするデータ解凍装置。 - 請求項1または2に記載のデータ解凍装置であって、
前記データ解凍装置の仕様情報とは、当該データ解凍装置が備えるキャッシュメモリの容量であり、
前記圧縮対象ブロックのサイズは、前記キャッシュメモリの容量に所定の比率を乗算した値を超えない、前記固定長レコードのサイズの最大の倍数であることを特徴とするデータ解凍装置。 - 請求項1から3のいずれか一項に記載のデータ解凍装置であって、
前記キャッシュメモリの容量に乗じる所定の比率とは0.5であることを特徴とするデータ解凍装置。 - 請求項1または2に記載のデータ解凍装置であって、
前記データ解凍装置の仕様情報とは、前記ソフトウェアが前記圧縮対象ブロックの解凍データを保持するために確保している主記憶装置の容量であり、
前記圧縮対象ブロックのサイズは、前記主記憶装置の容量を超えない、前記固定長レコードのサイズの最大の倍数であることを特徴とするデータ解凍装置。 - 請求項1または2に記載のデータ解凍装置であって、
前記データ解凍装置の仕様情報とは、当該データ解凍装置が備える通信装置が一度に送信可能なデータの最大サイズであり、
前記圧縮対象ブロックのサイズは、前記一度に送信可能なデータの最大サイズを超えない、前記固定長レコードのサイズの最大の倍数であることを特徴とするデータ解凍装置。 - 請求項1から6のいずれか一項に記載のデータ解凍装置であって、
通信網を介してデータ圧縮装置に、圧縮データの名称と、前記データ解凍装置の仕様情報を送信し、前記データ圧縮装置から、前記通知した情報に適合する圧縮データを受信する圧縮データ要求部を備えることを特徴とするデータ解凍装置。 - 請求項7に記載のデータ解凍装置であって、
前記圧縮データ要求部は、前記データ圧縮装置から、適合する圧縮データが存在しないことを通知された場合に、適合する圧縮データが存在しないことを示す警告画面を表示することを特徴とするデータ解凍装置。 - 複数の固定長レコードを含む圧縮対象データを圧縮するデータ圧縮装置であって、
前記固定長レコードの1レコードのサイズと、データ解凍装置の仕様情報と、の入力を受け付ける単位サイズ設定部と、
前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて圧縮対象ブロックのサイズを決定し、各々の前記圧縮対象ブロックに含まれる複数の前記固定長レコードの同一列データを列毎に圧縮して圧縮列データを作成し、各々の前記圧縮列データを含む圧縮データを作成する列データ圧縮部と、を備えることを特徴とするデータ圧縮装置。 - 請求項9に記載のデータ圧縮装置であって、
前記データ解凍装置の仕様情報とは、当該データ解凍装置が備える解凍装置キャッシュメモリの容量であり、
前記圧縮対象ブロックのサイズは、前記解凍装置キャッシュメモリの容量に所定の比率を乗算した値を超えない、前記固定長レコードのサイズの最大の倍数であることを特徴とするデータ圧縮装置。 - 請求項10に記載のデータ圧縮装置であって、
前記解凍装置キャッシュメモリの容量に乗じる所定の比率とは0.5であることを特徴とするデータ圧縮装置。 - 請求項9から11のいずれか一項に記載のデータ圧縮装置であって、
前記圧縮対象データを所定サイズの大きさのブロックに分割し、前記ブロック各々の圧縮を制御するブロックデータ圧縮部を備え、
前記ブロックデータ圧縮部は、前記圧縮対象データの各部分で異なる固定長レコードのレコード長を記載した圧縮定義ファイルを参照して、各々の前記ブロックの圧縮方法を決定し、
前記列データ圧縮部は、前記ブロックデータ圧縮部が圧縮方法を列圧縮と決定した前記ブロックを前記圧縮対象データとすることを特徴とするデータ圧縮装置。 - 請求項9から12のいずれか一項に記載のデータ圧縮装置であって、
前記単位サイズ設定部に入力された複数の前記仕様情報に基づき、前記列データ圧縮部が一つの前記圧縮対象データから作成した複数の前記圧縮データを記憶媒体に格納し、
さらに、通信網を介して前記データ解凍装置から、当該データ解凍装置の仕様情報を受信し、受信した前記仕様情報に適合する前記圧縮データを選択して前記データ解凍装置に送信する圧縮データ選択部を備えることを特徴とするデータ圧縮装置。 - 請求項9から13のいずれか一項に記載のデータ圧縮装置であって、
一つの前記圧縮対象データから作成された一つの圧縮データを記憶媒体に格納し、
通信網を介して前記データ解凍装置から受信した当該データ解凍装置の仕様情報が、前記圧縮データを作成する際に参照した仕様情報と異なっている場合に、前記圧縮データを解凍する解凍部と、
前記解凍部が出力する解凍されたデータを前記圧縮対象データとして、前記データ解凍装置から受信した当該データ解凍装置の仕様情報に基づき、再圧縮された前記圧縮データを、前記データ解凍装置へ送信することを特徴とするデータ圧縮装置。 - コンピューターを、圧縮された複数の固定長レコードを含む圧縮データを解凍する情報処理装置として機能させるためのプログラムであって、
前記圧縮データは、圧縮対象データが所定の圧縮対象ブロックサイズ単位で分割され、前記圧縮対象ブロック毎に圧縮された結果を含んだものであり、
前記圧縮対象ブロックサイズは、前記固定長レコードのサイズと、前記情報処理装置の仕様情報と、に基づいて決定されるものである場合に、
前記プログラムは、
前記固定長レコードのサイズと、前記情報処理装置の仕様情報と、に基づいて前記圧縮対象ブロックのサイズを判定するステップと、
前記圧縮データから一以上の圧縮対象ブロックを取得するステップと、
前記圧縮対象ブロックに含まれる、前記複数の固定長レコードの同一列データを列毎に圧縮した結果である圧縮列データの各々を解凍し、前記複数の固定長レコードを復元するステップと、
を前記コンピューターに実行させることを特徴とするプログラム。 - コンピューターを、複数の固定長レコードを含む圧縮対象データを圧縮する情報処理装置として機能させるためのプログラムであって、
前記コンピューターは、
ユーザーからの命令を受け付けるインターフェース装置を備えており、
前記プログラムは、
前記インターフェース装置を介して、前記固定長レコードの1レコードのサイズと、データ解凍装置の仕様情報と、の入力を受け付けるステップと、
前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて圧縮対象ブロックのサイズを決定するステップと、
前記圧縮対象データを一以上の前記圧縮対象ブロックに分割するステップと、
各々の前記圧縮対象ブロックに含まれる複数の前記固定長レコードの同一列データを列毎に圧縮して圧縮列データを作成するステップと、
各々前記圧縮列データを含む圧縮データを作成するステップと、
を前記コンピューターに実行させることを特徴とするプログラム。 - データ圧縮装置とデータ解凍装置が通信網を介して接続される圧縮データ配信システムであって、
前記データ圧縮装置は、
前記固定長レコードの1レコードのサイズと、前記データ解凍装置の仕様情報と、の入力を受け付ける単位サイズ設定部と、
前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて前記圧縮対象ブロックのサイズを決定し、前記圧縮対象データを一以上の前記圧縮対象ブロックに分割し、各々の前記圧縮対象ブロックに含まれる複数の前記固定長レコードの同一列データを列毎に圧縮して圧縮列データを作成し、各々の前記圧縮列データを含む圧縮データを作成する列データ圧縮部と、を備え、
前記データ解凍装置は、
前記圧縮データは、圧縮対象データが所定の圧縮対象ブロックサイズ単位で分割され、前記圧縮対象ブロック毎に圧縮された結果を含んだものであり、
前記圧縮対象ブロックサイズは、前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて決定されるものである場合に、
前記固定長レコードのサイズと、前記データ解凍装置の仕様情報と、に基づいて前記圧縮対象ブロックのサイズを判定し、
前記圧縮データから一以上の圧縮対象ブロックを取得し、
前記圧縮対象ブロックに含まれる、前記複数の固定長レコードの同一列データを列毎に圧縮した結果である圧縮列データの各々を解凍し、前記複数の固定長レコードを復元する列データ解凍部、を備えることを特徴とする圧縮データ配信システム。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/403,344 US10116325B2 (en) | 2012-05-25 | 2013-04-18 | Data compression/decompression device |
CN201380027389.2A CN104380267B (zh) | 2012-05-25 | 2013-04-18 | 数据解压/压缩装置 |
EP13794571.3A EP2857976A4 (en) | 2012-05-25 | 2013-04-18 | DEVICE FOR COMPRESSION / DECOMPRESSION OF DATA |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2012-119180 | 2012-05-25 | ||
JP2012119180A JP5826114B2 (ja) | 2012-05-25 | 2012-05-25 | データ解凍装置、データ圧縮装置、データの解凍プログラム、データの圧縮プログラム、及び、圧縮データ配信システム |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2013175909A1 true WO2013175909A1 (ja) | 2013-11-28 |
Family
ID=49623610
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2013/061552 WO2013175909A1 (ja) | 2012-05-25 | 2013-04-18 | データ解凍/圧縮装置 |
Country Status (5)
Country | Link |
---|---|
US (1) | US10116325B2 (ja) |
EP (1) | EP2857976A4 (ja) |
JP (1) | JP5826114B2 (ja) |
CN (1) | CN104380267B (ja) |
WO (1) | WO2013175909A1 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016194121A1 (ja) * | 2015-06-01 | 2016-12-08 | 株式会社日立製作所 | ストレージシステム、計算機装置、及び、重複排除デバイス |
WO2018021094A1 (ja) * | 2016-07-25 | 2018-02-01 | 株式会社高速屋 | データ圧縮符号化方法、復号化方法、その装置、及び、そのプログラム |
JP2018023083A (ja) * | 2017-01-20 | 2018-02-08 | 株式会社高速屋 | データ圧縮符号化方法、復号化方法、その装置、及び、そのプログラム |
Families Citing this family (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10296462B2 (en) | 2013-03-15 | 2019-05-21 | Oracle International Corporation | Method to accelerate queries using dynamically generated alternate data formats in flash cache |
US10642837B2 (en) * | 2013-03-15 | 2020-05-05 | Oracle International Corporation | Relocating derived cache during data rebalance to maintain application performance |
US10528590B2 (en) | 2014-09-26 | 2020-01-07 | Oracle International Corporation | Optimizing a query with extrema function using in-memory data summaries on the storage server |
JP6397995B2 (ja) * | 2015-04-13 | 2018-09-26 | 株式会社日立製作所 | データベース管理システム、データベースサーバ、及び、データベース管理方法 |
US10678788B2 (en) | 2015-10-22 | 2020-06-09 | Oracle International Corporation | Columnar caching in tiered storage |
CN106713394A (zh) * | 2015-11-16 | 2017-05-24 | 华为技术有限公司 | 一种数据传输方法和装置 |
JP6725120B2 (ja) * | 2016-06-24 | 2020-07-15 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | データ処理方法、記憶装置、ソリッドステートディスク及び記憶システム |
US10048868B2 (en) * | 2016-09-29 | 2018-08-14 | Intel Corporation | Replacement of a block with a compressed block to increase capacity of a memory-side cache |
WO2018096998A1 (ja) * | 2016-11-28 | 2018-05-31 | 株式会社ターボデータラボラトリー | データ圧縮装置、コンピュータプログラム及びデータ圧縮方法 |
US11281641B1 (en) * | 2017-05-23 | 2022-03-22 | Amazon Technologies, Inc. | Evaluating encoding history for late encoding binding of data |
US10475375B2 (en) * | 2017-06-09 | 2019-11-12 | Shenzhen China Star Optoelectronics Semiconductor Display Technology Co., Ltd. | Compression method and decompression method for compensation table of OLED display device |
US10402111B1 (en) * | 2017-08-14 | 2019-09-03 | Xilinx, Inc. | Systems and methods for data storage compression |
US11086876B2 (en) | 2017-09-29 | 2021-08-10 | Oracle International Corporation | Storing derived summaries on persistent memory of a storage device |
US10642602B2 (en) * | 2017-12-12 | 2020-05-05 | Nxp Usa, Inc. | NVM architecture with OTA support |
CN107943424A (zh) * | 2017-12-18 | 2018-04-20 | 苏州蜗牛数字科技股份有限公司 | 一种网络游戏中方块地形信息的压缩方法 |
US11507847B2 (en) | 2019-07-25 | 2022-11-22 | Raytheon Company | Gene expression programming |
US11321462B2 (en) | 2018-04-10 | 2022-05-03 | Raytheon Company | Device behavior anomaly detection |
US11436537B2 (en) | 2018-03-09 | 2022-09-06 | Raytheon Company | Machine learning technique selection and improvement |
US11340603B2 (en) | 2019-04-11 | 2022-05-24 | Raytheon Company | Behavior monitoring using convolutional data modeling |
WO2019199777A1 (en) | 2018-04-10 | 2019-10-17 | Raytheon Company | Encryption using spatial voting |
US11381599B2 (en) | 2018-04-10 | 2022-07-05 | Raytheon Company | Cyber chaff using spatial voting |
CN109582653B (zh) * | 2018-11-14 | 2020-12-08 | 网易(杭州)网络有限公司 | 文件的压缩、解压缩方法及设备 |
CN109710581B (zh) * | 2018-12-25 | 2023-05-30 | 四川巧夺天工信息安全智能设备有限公司 | 一种解压qcow镜像文件中压缩数据的方法 |
US10937465B2 (en) * | 2019-02-21 | 2021-03-02 | Raytheon Company | Anomaly detection with reduced memory overhead |
US11341235B2 (en) | 2019-02-21 | 2022-05-24 | Raytheon Company | Anomaly detection with adaptive auto grouping |
CN113424148A (zh) | 2019-03-15 | 2021-09-21 | 英特尔公司 | 用于检测跨分片访问、提供多分片推理缩放和提供最佳页迁移的多分片存储器管理 |
US11586554B2 (en) * | 2020-07-23 | 2023-02-21 | Arm Limited | Cache arrangements for data processing systems |
CN112054802B (zh) * | 2020-07-29 | 2023-10-13 | 北京市腾河电子技术有限公司 | 一种电力计量数据压缩、解压缩方法、装置及电子设备 |
CN112181869B (zh) * | 2020-09-11 | 2024-07-19 | ***股份有限公司 | 信息存储方法、装置、服务器及介质 |
US20220121397A1 (en) * | 2020-10-16 | 2022-04-21 | Western Digital Technologies, Inc. | Internal Compression Storage Devices |
CN112783462B (zh) * | 2021-01-19 | 2024-06-11 | 昆山联滔电子有限公司 | 一种数据传输的控制方法及装置 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4558302A (en) | 1983-06-20 | 1985-12-10 | Sperry Corporation | High speed data compression and decompression apparatus and method |
JP2001204001A (ja) * | 1999-10-29 | 2001-07-27 | Matsushita Electric Ind Co Ltd | 動画像配信システム,再生端末装置,及び配信装置 |
JP2006276981A (ja) * | 2005-03-28 | 2006-10-12 | Digital Electronics Corp | 送信装置、そのプログラムおよび記録媒体 |
JP2010165151A (ja) | 2009-01-15 | 2010-07-29 | Mitsubishi Electric Corp | データアクセス装置及びデータアクセスプログラム |
US7769729B2 (en) | 2007-05-21 | 2010-08-03 | Sap Ag | Block compression of tables with repeated values |
JP2011530234A (ja) * | 2008-07-31 | 2011-12-15 | マイクロソフト コーポレーション | 大規模なデータストレージのための効率的な列ベースデータの符号化 |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6275588B1 (en) * | 1998-11-12 | 2001-08-14 | I-Data International A/S | Apparatus and method for performing and controlling encryption/decryption for data to be transmitted on local area network |
US6959300B1 (en) * | 1998-12-10 | 2005-10-25 | At&T Corp. | Data compression method and apparatus |
JP4162184B2 (ja) * | 2001-11-14 | 2008-10-08 | 株式会社日立製作所 | データベース管理システムの実行情報を取得する手段を有する記憶装置 |
US7447839B2 (en) * | 2005-09-13 | 2008-11-04 | Yahoo! Inc. | System for a distributed column chunk data store |
JP5282460B2 (ja) | 2008-07-02 | 2013-09-04 | オンキヨー株式会社 | 信号入出力装置 |
US8832142B2 (en) * | 2010-08-30 | 2014-09-09 | Oracle International Corporation | Query and exadata support for hybrid columnar compressed data |
CN101841337B (zh) * | 2010-05-06 | 2013-04-24 | 华为终端有限公司 | 数据压缩和解压缩处理方法以及移动存储设备 |
US9325344B2 (en) * | 2010-12-03 | 2016-04-26 | International Business Machines Corporation | Encoding data stored in a column-oriented manner |
US8560508B2 (en) * | 2011-07-22 | 2013-10-15 | International Business Machines Corporation | Real-time compression of tabular data |
JP5259848B2 (ja) * | 2011-07-29 | 2013-08-07 | 株式会社東芝 | 再生制御装置及び再生制御方法 |
US8719271B2 (en) * | 2011-10-06 | 2014-05-06 | International Business Machines Corporation | Accelerating data profiling process |
CN102521363A (zh) * | 2011-12-15 | 2012-06-27 | 武汉达梦数据库有限公司 | 基于列分解的列存储数据库数值数据压缩方法 |
US8812564B2 (en) * | 2011-12-20 | 2014-08-19 | Sap Ag | Parallel uniqueness checks for partitioned tables |
US8868594B2 (en) * | 2011-12-23 | 2014-10-21 | Sap Ag | Split processing paths for a database calculation engine |
US8880510B2 (en) * | 2011-12-23 | 2014-11-04 | Sap Se | Unique value calculation in partitioned tables |
US8589451B1 (en) * | 2012-05-24 | 2013-11-19 | Sap Ag | Systems and methods for generating a common data model for relational and object oriented databases |
US9384204B2 (en) * | 2013-05-22 | 2016-07-05 | Amazon Technologies, Inc. | Efficient data compression and analysis as a service |
US9244935B2 (en) * | 2013-06-14 | 2016-01-26 | International Business Machines Corporation | Data encoding and processing columnar data |
US10311154B2 (en) * | 2013-09-21 | 2019-06-04 | Oracle International Corporation | Combined row and columnar storage for in-memory databases for OLTP and analytics workloads |
-
2012
- 2012-05-25 JP JP2012119180A patent/JP5826114B2/ja not_active Expired - Fee Related
-
2013
- 2013-04-18 US US14/403,344 patent/US10116325B2/en active Active
- 2013-04-18 CN CN201380027389.2A patent/CN104380267B/zh active Active
- 2013-04-18 EP EP13794571.3A patent/EP2857976A4/en not_active Withdrawn
- 2013-04-18 WO PCT/JP2013/061552 patent/WO2013175909A1/ja active Application Filing
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4558302A (en) | 1983-06-20 | 1985-12-10 | Sperry Corporation | High speed data compression and decompression apparatus and method |
US4558302B1 (ja) | 1983-06-20 | 1994-01-04 | Unisys Corp | |
JP2001204001A (ja) * | 1999-10-29 | 2001-07-27 | Matsushita Electric Ind Co Ltd | 動画像配信システム,再生端末装置,及び配信装置 |
JP2006276981A (ja) * | 2005-03-28 | 2006-10-12 | Digital Electronics Corp | 送信装置、そのプログラムおよび記録媒体 |
US7769729B2 (en) | 2007-05-21 | 2010-08-03 | Sap Ag | Block compression of tables with repeated values |
JP2011530234A (ja) * | 2008-07-31 | 2011-12-15 | マイクロソフト コーポレーション | 大規模なデータストレージのための効率的な列ベースデータの符号化 |
JP2010165151A (ja) | 2009-01-15 | 2010-07-29 | Mitsubishi Electric Corp | データアクセス装置及びデータアクセスプログラム |
Non-Patent Citations (2)
Title |
---|
B.R. IYER: "Data Compression Support in Databases", PROCEEDINGS OF THE 20TH INTERNATIONAL CONFERENCE ON VERY LARGE DATA BASES (VLDB94), (UNITED STATES, 1994, pages 695 - 704, XP002754967 |
See also references of EP2857976A4 |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016194121A1 (ja) * | 2015-06-01 | 2016-12-08 | 株式会社日立製作所 | ストレージシステム、計算機装置、及び、重複排除デバイス |
WO2018021094A1 (ja) * | 2016-07-25 | 2018-02-01 | 株式会社高速屋 | データ圧縮符号化方法、復号化方法、その装置、及び、そのプログラム |
JP2018022933A (ja) * | 2016-07-25 | 2018-02-08 | 株式会社高速屋 | データ圧縮符号化方法、復号化方法、その装置、及び、そのプログラム |
CN109478893A (zh) * | 2016-07-25 | 2019-03-15 | 株式会社高速屋 | 数据压缩编码方法、解码方法、其装置及其程序 |
US10547324B2 (en) | 2016-07-25 | 2020-01-28 | KOUSOKUYA, Inc. | Data compression coding method, apparatus therefor, and program therefor |
EP3771104A1 (en) | 2016-07-25 | 2021-01-27 | Kousokuya, Inc. | Data compression coding method, decoding method, apparatus for the methods, and program for the methods |
JP2018023083A (ja) * | 2017-01-20 | 2018-02-08 | 株式会社高速屋 | データ圧縮符号化方法、復号化方法、その装置、及び、そのプログラム |
Also Published As
Publication number | Publication date |
---|---|
CN104380267A (zh) | 2015-02-25 |
EP2857976A1 (en) | 2015-04-08 |
EP2857976A4 (en) | 2016-04-13 |
JP2013246598A (ja) | 2013-12-09 |
US10116325B2 (en) | 2018-10-30 |
US20150100556A1 (en) | 2015-04-09 |
CN104380267B (zh) | 2017-05-17 |
JP5826114B2 (ja) | 2015-12-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5826114B2 (ja) | データ解凍装置、データ圧縮装置、データの解凍プログラム、データの圧縮プログラム、及び、圧縮データ配信システム | |
CN104040542B (zh) | 用于在易失性存储器内保持关系型数据的列向量的技术 | |
US10187081B1 (en) | Dictionary preload for data compression | |
CN112953550B (zh) | 数据压缩的方法、电子设备及存储介质 | |
US20160321282A1 (en) | Extracting method, information processing method, computer product, extracting apparatus, and information processing apparatus | |
JP6009676B2 (ja) | データ圧縮装置およびデータ伸張装置 | |
US9665590B2 (en) | Bitmap compression for fast searches and updates | |
CN105191144A (zh) | 压缩装置、压缩方法、解压装置、解压方法以及信息处理*** | |
CN115438114B (zh) | 存储格式转换方法、***、装置、电子设备及存储介质 | |
JP5656593B2 (ja) | 符号化データを復号する装置及び方法 | |
CN112544038A (zh) | 存储***数据压缩的方法、装置、设备及可读存储介质 | |
CN101469989B (zh) | 一种手机网络导航中导航数据的压缩方法 | |
KR20240078422A (ko) | 인코딩된 데이터에 대한 조건부 트랜스코딩 | |
JP5549177B2 (ja) | 圧縮プログラム、方法及び装置、並びに解凍プログラム、方法及び装置 | |
US9916335B2 (en) | Row, table, and index decompression | |
JPH10261969A (ja) | データ圧縮方法および装置 | |
US20130173564A1 (en) | System and method for data compression using multiple encoding tables | |
Govinda et al. | Storage optimization in cloud environment using compression algorithm | |
WO2017186049A1 (zh) | 信息处理方法和装置 | |
JP2006302082A (ja) | 文字列検索装置 | |
CN101930451A (zh) | 用于存储高效地搜索至少一个询问数据元素的方法和装置 | |
US11971856B2 (en) | Efficient database query evaluation | |
US7375657B2 (en) | Method and system for performing streaming of encoded data | |
CN113849705A (zh) | 大体量数据检索方法、***和存储介质 | |
CN114416350A (zh) | 一种解压方法、装置、可读存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 13794571 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 14403344 Country of ref document: US Ref document number: 2013794571 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |