Database Acceleration Method and Device using In-Storage Processing

KR103018113B1Active Publication Date: 2026-09-09IND ACADEMIC COOP FOUND YONSEI UNIV
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
KR1020250123505
Authority / Receiving Office
KR · KR
Patent Type
Patents
Current Assignee / Owner
Filing Date
2025-09-01
Publication Date
2026-09-09
Estimated Expiration
2045-09-01

Smart Images

  • Figure 112025100342078-PAT00002_ABST
    Figure 112025100342078-PAT00002_ABST
Patent Text Reader

Abstract

The present disclosure provides a database acceleration method and apparatus that can significantly improve query processing speed by performing acceleration by a host processor in a database comprising a storage device having an internal processor and a storage module and a host processor and memory, comprising: a step of determining whether data included in each column having data of the same format in a data table stored in the storage module is numeric data or text data; a step of converting the data included in the column into metadata of a specified number of bits by encoding differently depending on whether it is numeric data or text data; a step of obtaining a row vector by combining the converted metadata in the data table on a row-by-row basis and creating a meta table including the obtained row vector; and a step of converting the query into a meta query in a manner according to the method of converting into metadata when a query is authorized, by comparing a plurality of row vectors and the authorized query and processing them in parallel.
Need to check novelty before this filing date? Find Prior Art

Description

Technology Field

[0001] The disclosed embodiments relate to a database acceleration method and apparatus, and more specifically, to a database acceleration method and apparatus utilizing a storage device including an internal processor. Background Technology

[0002] The most critical operation of large-scale data analysis is to read a large amount of data stored on a storage device, check the relationship between the read data and the authorized query, and obtain data that matches the query by filtering out irrelevant data, that is, non-matching data.

[0003] Figure 1 is a diagram illustrating the difference in operation between a conventional database and a database with an ISP applied.

[0004] As illustrated in (a) of Figure 1, in conventional databases, a host processor, such as a CPU, interprets queries based on user commands and reads large amounts of data stored in a storage device through memory, such as DRAM, and excludes data irrelevant to the interpreted query. Therefore, since a large amount of data must be read to process a query, it requires significant CPU cycles, memory capacity, and channel bandwidth for data transfer. In particular, since host processors, such as CPUs, are mostly designed to efficiently process long and complex commands, it is highly inefficient for a host processor to process queries consisting of relatively very simple commands. This results in problems such as long query latency and high energy consumption. In other words, there are limitations to improving the efficiency of the database.

[0005] To overcome these limitations, In-Storage Processing (ISP) has been proposed, which includes an internal processor within the storage device to reduce the workload that the host processor must handle.

[0006] As shown in Figure 1 (b), in a database with an ISP applied, the internal processor of the storage device receives a query from the host processor and first filters and removes data irrelevant to the query from the large amount of data stored in the storage device. Then, the remaining filtered data is transmitted to the host processor, and the host processor receives and processes only a small amount of the filtered data. Therefore, since the internal processor prioritizes processing queries requiring simple filtering, the amount of data to be transmitted to the host processor is significantly reduced, and as the number of queries that the host processor needs to process is reduced, the query processing speed and energy efficiency of the database are improved.

[0007] However, the internal processor implemented within the storage device to perform ISP consists of circuits such as a Field Programmable Gate Array (FPGA), which are relatively simple compared to the host processor. Consequently, it has limitations in that it is difficult to process complex or very large number of queries simultaneously. In some cases, the host processor may synthesize and transmit multiple queries so that the internal processor can effectively process multiple queries; however, as the number of queries increases, the time required for synthesis also increases, and since the number of queries that can be synthesized is limited by the performance of the internal processor, there are limitations to performance improvement.

[0008] Furthermore, data is stored in storage devices in a wide variety of formats, and internal processors must sequentially check and distinguish between these diverse data types in order to process each separated piece of data. Consequently, low-performance internal processors not only consume significant resources just to differentiate the large volume of data stored in storage but also struggle to perform parallel operations, making it difficult to improve processing speed.

[0009] To solve this problem, a method has been proposed in which data is first converted to have the same size through preprocessing, and then the converted data is stored in a storage device. In this case, the internal processor can easily distinguish the data stored in the storage, which can significantly improve processing speed and enable parallel computation. However, in order to convert the data to have the same size, all data must be zero-padded based on the data in the format with the largest size, which causes a problem of significant waste in storage and memory. The problem to be solved

[0010] The objective of the disclosed embodiments is to provide a database acceleration method and apparatus capable of significantly improving query processing speed by separately generating and storing metadata describing data stored in various formats on a storage device through pre-processing, and processing a query based on the stored metadata.

[0011] The objective of the disclosed embodiments is to provide a database acceleration method and apparatus capable of generating metadata by encoding data stored in a storage device in a table format consisting of rows and columns differently depending on whether the data is text data or numeric data by column, storing the metadata generated on a row-by-row basis as a row vector, and, when a query is authorized, comparing a plurality of row vectors with the authorized query to perform parallel processing. means of solving the problem

[0012] A database acceleration method according to an embodiment is an acceleration method performed by a host processor in a database comprising a storage device having an internal processor and a storage module, a host processor, and memory, and comprises: a step of determining whether data included in each column having data of the same format in a data table stored in the storage module is numeric data or text data; a step of converting the data included in the column into metadata of a specified number of bits by encoding differently depending on whether it is numeric data or text data; a step of obtaining a row vector by combining the converted metadata in the data table on a row-by-row basis and creating a meta table including the obtained row vector; and a step of converting the query into a meta query in a manner according to the method of converting into metadata when a query is authorized.

[0013] The step of converting to the above metadata can be performed by, if the data is numeric, dividing the numeric range according to the numeric data included in the column into a specified number of numeric partitions and converting each numeric data included in the column into numeric metadata by one-hot encoding according to the divided numeric partitions, and if the data is text, mapping each word of the text data included in the column to one of the specified number of text partitions and checking the text partition to which each word of the text data included in the column is mapped and encoding, thereby converting the text data into text metadata.

[0014] In the step of converting to the above metadata, if the number of words of text data included in the column exceeds the number of text partitions, each word can be duplicated by sequentially circulating through multiple text partitions.

[0015] The step of converting into the above metadata can check the frequency of occurrence of each word of the text data included in the column and sequentially map each word to a plurality of text partitions according to the checked frequency of occurrence.

[0016] The step of converting into the above metadata can sequentially map each word of the text data included in the column to a plurality of text partitions according to the order of occurrence.

[0017] The step of generating the above meta table may generate a meta ISP table composed of meta raw data including the row vector and length information of the row vector corresponding to the row vector, and store it in the storage module.

[0018] The step of generating the above meta table may generate a meta DB table composed of meta DB data containing encoding information indicating a method of converting data of each column of the data table into metadata, and store it in the storage module.

[0019] The step of converting into the above meta query can convert the query into the above meta query using the meta DB data included in the above meta DB table and transmit the above meta query to the internal processor.

[0020] The step of converting to the above meta query involves the internal processor determining a row vector that matches the meta query among the row vectors stored in the meta table, and transmitting the data of the row corresponding to the determined row vector in the data table, and then comparing the transmitted data of the row with the query to detect the data that matches the query.

[0021] The above database acceleration method may further include the step of converting the authorized new data into metadata and updating the meta table to include the converted metadata when new data included in the data table is authorized.

[0022] According to an embodiment, the database acceleration device is a device comprising a storage device having an internal processor and a storage module, a host processor, and memory, wherein the host processor performs the steps of: determining whether the data included in each column having data of the same format in a data table stored in the storage module is numeric data or text data; encoding the data included in the column differently depending on whether it is numeric data or text data and converting it into metadata with a specified number of bits; combining the converted metadata in the data table on a row-by-row basis to obtain a row vector and creating a meta table including the obtained row vector; and, when a query is authorized, converting the query into a meta query in a manner according to the method of converting into metadata. Effects of the invention

[0023] Accordingly, the database acceleration method and device according to the embodiment can significantly improve the query processing speed by generating metadata by encoding data stored in a storage device in a table format consisting of rows and columns differently depending on whether it is text data or numeric data by column, storing the metadata generated on a row-by-row basis as a row vector, and then, when a query is authorized, comparing a plurality of row vectors with the authorized query and processing them in parallel. Brief explanation of the drawing

[0024] Figure 1 is a diagram illustrating the difference in operation between a conventional database and a database with an ISP applied. FIG. 2 is a diagram illustrating the schematic configuration and operation of a database to which an ISP is applied according to one embodiment. FIGS. 3 and 4 are diagrams illustrating the difference in how the internal processor of a conventional database and a database of one embodiment process queries. FIG. 5 illustrates a database acceleration method according to one embodiment. Specific details for implementing the invention

[0025] Hereinafter, specific embodiments according to embodiments of the present disclosure will be described with reference to the drawings. The following detailed description is provided to facilitate a comprehensive understanding of the methods, apparatuses, and / or systems described herein. However, this is merely illustrative and the present invention is not limited thereto.

[0026] In describing the embodiments of the present disclosure, detailed descriptions of known technology related to the present invention are omitted if it is determined that such detailed descriptions would unnecessarily obscure the essence of the embodiments. Furthermore, terms described below are defined with consideration of their functions in the present invention, and these may vary depending on the intentions or practices of the user or operator. Therefore, such definitions should be based on the content throughout this specification. Terms used in the detailed description are intended merely to describe specific embodiments and should not be limiting. Unless explicitly stated otherwise, expressions in the singular form include the meaning of the plural form. In this description, expressions such as “include” or “compose” are intended to refer to certain characteristics, numbers, steps, actions, elements, parts thereof, or combinations thereof, and should not be interpreted to exclude the existence or possibility of one or more other characteristics, numbers, steps, actions, elements, parts thereof, or combinations thereof other than those described. Additionally, terms such as “...part,” “...unit,” “module,” and “block” described in the specification refer to a unit that processes at least one function or operation, and this may be implemented in hardware, software, or a combination of hardware and software.

[0027] FIG. 2 is a diagram illustrating the schematic configuration and operation of a database to which an ISP is applied according to one embodiment.

[0028] Referring to FIG. 2, a database of one embodiment includes a host processor (10), main memory (20), and a storage device (30). Since a database with an ISP applied is assumed here, the storage device (30) may include an internal processing module (35) along with a storage module (31). The storage module (31) may include a storage controller (32) and a storage block (33). Here, it is assumed that the storage device (30) is implemented as a smart SSD based on a solid-state drive (SSD) composed of NAND flash memory. Accordingly, FIG. 2 shows that the storage controller (32) of the storage module (31) is implemented as an SSD controller and the storage block (33) is implemented as NAND flash memory, but the storage module (31) may be implemented with a different configuration. The internal processing module (35) may include an internal processor (36) and an internal memory (37) for performing operations within the storage device (30). The internal processor (36) can be implemented as an FPGA, etc., and the internal memory (37) can be implemented as a DRAM, etc.

[0029] First, the host processor (10) performs pre-processing to convert each data of the data table (DB table) stored in the storage device (30) into metadata, and stores the converted metadata in the storage device (30). The host processor (10) can periodically or in an idle state read and encode the data of the data table (DB table) stored in the storage device (30) to convert it into metadata, and can also convert new data into metadata when it is stored in the storage device (30). When new data is authorized, the host processor (10) may convert only the new data into metadata, but in some cases, it may also convert previously stored data back into metadata.

[0030] The host processor (10) can convert data into metadata by separating it by each column having data of the same format in the data table (DB table), and can convert it into metadata by encoding it with different encoding methods depending on whether the data in each column is numeric data or text data. Then, the host processor (10) can obtain a row vector by separating and combining the metadata converted by each column in the data table (DB table) again by row in the data table (DB table). At this time, the host processor (10) can obtain meta-row data by further including length information of the row vector and each metadata included in the row vector.

[0031] Additionally, when the host processor (10) converts into metadata, it may also generate auxiliary metadata that explains the method of conversion into metadata so that the internal processor (36) of the storage device (30) can effectively analyze the metadata. Here, the metadata that explains the data itself stored in the storage device (30) is called Meta ISP data, and the auxiliary metadata that explains the method of conversion into metadata for the internal processor (36) is called Meta DB data.

[0032] A detailed method for generating meta ISP data and meta DB data by encoding the read data by the host processor (10) will be described later.

[0033] When a query is authorized, the host processor (10) encodes the authorized query based on meta DB data to convert it into a meta query and transmits the generated meta query to the internal processing module (35). Here, the host processor (10) converts the query into a meta query so that the internal processor (36) can filter data unrelated to the query based on the converted meta ISP data rather than the data.

[0034] When the internal processor (36) transmits data filtered according to a meta query, the host processor (10) can detect data that matches the query by comparing the transmitted data with the query.

[0035] At least one data table (DB table) is stored in the storage module (31). Here, the data table may consist of multiple data separated into rows and columns, and data of the same format is stored in each column of the data table. In most databases, data is stored in a table format consisting of multiple data separated into rows and columns, and each column of the table consists of data of the same format. For example, in the case of a table where user information is stored, each user is separated by row, and individual information items of the user, such as user ID, name, age, address, etc., are separated by column. Therefore, each column of the table may consist of data of the same format.

[0036] In one embodiment, the storage module (31) may store together a meta ISP table (M-ISP) containing meta ISP data and a meta DB table (M-DB) composed of meta DB data by the host processor (10). Here, the meta ISP table (M-ISP) and the meta DB table (M-DB) may be created and stored as pairs by matching each data table (DB table). That is, the meta ISP table (M-ISP) and the meta DB table (M-DB) may be created in the same number as the data table (DB table). The meta ISP table (M-ISP) includes a row vector in which data stored in row units in the data table (DB table) is converted. In this case, if the length information of each metadata included in the row vector is obtained together to obtain meta row data, the meta ISP table (M-ISP) may be composed of meta row data.

[0037] In other words, the meta-row data constituting a row in the Meta ISP Table (M-ISP) represents the metadata stored for each row of the Data Table (DB table). In this case, the row vector or meta-row data stored in the Meta ISP Table (M-ISP) can be stored in a row in the same order as each row in the Data Table (DB table). However, as this is merely an example, the data of each row in the Data Table (DB table) and the corresponding row vector or meta-row data in the Meta ISP Table (M-ISP) may be stored in different rows; in this case, matching information between the rows of the Data Table (DB table) and the rows of the Meta ISP Table (M-ISP) may be additionally included in the meta-row data. Here, the explanation assumes that the rows stored in the Data Table (DB table) and the Meta ISP Table (M-ISP) are matched with each other.

[0038] When a meta query encoded from a host processor (10) is received, the internal processor (36) reads the meta ISP data contained in the meta ISP table (M-ISP) and compares the read meta ISP data with the meta query to determine the meta ISP data corresponding to the meta query. At this time, the internal processor (36) reads the meta ISP data in units of meta row data rather than individual meta ISP data, and distinguishes the meta ISP data constituting the row vector from the read meta row data and compares it with the meta query to determine the row vector corresponding to the meta query.

[0039] Then, data of a row corresponding to a determined row vector in a data table (DB table) is selected, and the data of the selected row is transmitted to the host processor (10). That is, in one embodiment, the internal processor (36) compares with a meta query on a row vector basis, and can select row-unit data of a data table (DB table) corresponding to the meta query based on the comparison result.

[0040] The following describes how a host processor (10) encodes data to generate meta ISP data and meta DB data.

[0041] The host processor (10) selects data from a data table (DB table) on a column-by-column basis and determines whether the data included in the selected column is numeric data or text data. If the data included in the selected column is numeric data, it searches for the minimum and maximum values ​​among the numbers represented by all numeric data to set a numeric range. For example, if the minimum value is 4 and the maximum value is 1000, the numeric range can be set to 1 to 1024. Then, the set numeric range is divided into a specified number of numeric partitions. For example, if the numeric data is to be converted into 32-bit meta ISP data, the set numeric range can be divided into 32 numeric partitions. At this time, the sub-number range of each partition can have a size obtained by dividing the numeric range by the number of partitions (1024 / 32 = 32), and the sub-ranges of 1 to 32, 33 to 64, …, 993 can be assigned to the first to 32nd numeric partitions, respectively.

[0042] And the host processor (10) determines a sub-range containing sub-range numeric data assigned to a plurality of numeric partitions, and by assigning a value of 1 to the bit value of the position for the numeric partition of the determined sub-range in the meta-ISP data and assigning a value of 0 to the remaining bit values, the meta-ISP data in which the numeric data is one-hot encoded can be obtained. For example, if the numeric data has a value of 30, the 32-bit meta-ISP data is “1000…0000 (2) It can be converted to “, and if the numeric data has a value of 1022, the 32-bit meta ISP data is “0000…0001 (2) It can be converted to ”.

[0043] Meanwhile, if the data included in the selected column is text data, a specified number of text partitions are set. Here, it is assumed that the text data is converted into 32-bit meta ISP data, and in this case, the text partitions can also be set to 32. Then, the host processor (10) maps all words included in the text data of the column to one of the set multiple text partitions. At this time, if the number of words in the text data exceeds the number of text partitions, the host processor (10) can map each word to the multiple text partitions sequentially and redundantly. That is, multiple words can be redundantly mapped to each text partition.

[0044] For example, 32 words such as Apple, grape, strawberry, carrot, …, pineapple are sequentially mapped to 32 text partitions (P1 to P32) (Apple (P1), grape (P2), strawberry (P3), carrot (P4), …, pineapple (P32)), and then, 32 words such as is, delicious, …, sour can be sequentially duplicated mapped to 32 text partitions (P1 to P32) again (is (P1), delicious (P2), …, sour (P32)).

[0045] Here, the host processor (10) can simply map each word to multiple text partitions sequentially and redundantly according to the order of occurrence. However, the host processor (10) may first check the frequency of occurrence of each word in the text data included in the selected column, and map each word to multiple text partitions sequentially and redundantly according to the checked frequency of occurrence.

[0046] And if the text data is “Apple is delicious”, the host processor (10) assigns 1 to the bit of the position according to the text partition to which each word of the text data is mapped, so that “Apple (P1) is (P1) delicious (P2)” is “1100….0000 (2) It can be converted into 32-bit metadata ISP data of ”. And if the text data is “Pineapple is sour”, since it is “Pineapple (P32) is (P1) sour (P32)”, it is “1000… .0001 (2) It can be converted into 32-bit meta ISP data.

[0047] The host processor (10) stores the meta ISP data converted for each column in the meta ISP table (M-ISP). At this time, the host processor (10) stores the meta ISP data converted from the data located in one row of the data table (DB table) in one row of the meta ISP table (M-ISP) to form a row vector. At this time, the row vector may be stored in a row of the meta ISP table (M-ISP) at the same location as the row of the data table (DB table). Also, it is not necessary to add a separate separator to distinguish the meta ISP data included in the row vector from one another. That is, multiple meta ISP data included in the row vector are not separately distinguished. Instead, the host processor (10) may generate meta row data in which information regarding the length of the row vector and the length of each of the multiple meta ISP data included in the row vector is added to the row vector, and store it in the meta ISP table (M-ISP). This is to enable the internal processor (36) to distinguish and process the meta ISP data even when it receives a raw vector in which the meta ISP data is not distinguished.

[0048] However, if the length of each of the multiple meta ISP data included in the raw vector is pre-set or has an equal length, information regarding the length of each meta ISP data in the meta raw data may be omitted. In addition, if the length of the raw vector itself is pre-set, the host processor (10) may also omit the length of the raw vector. That is, only the raw vector may be stored in the meta ISP table (M-ISP).

[0049] Meanwhile, the host processor (10) stores the conversion methods of multiple meta ISP data, which are converted differently according to the data type of each column of the data table (DB table), in the meta DB table (M-DB). Specifically, if the data of the column is numeric data, the host processor (10) can store the sub-ranges assigned to each of the multiple numeric partitions as meta DB data. And if the data of the column is text data, it can store the words mapped to each of the multiple text partitions as meta DB data.

[0050] Accordingly, when a condition query based on numbers is granted, the host processor (10) checks the number partition containing the number set in the condition query, similar to the conversion method of meta ISP data, and generates a meta query by changing the query according to the identified number partition. Then, when a condition query based on words, etc. is granted, the host processor checks the text partition containing the word set in the condition query, similar to the conversion method of meta ISP data, and generates a meta query by changing the query according to the identified text partition. Then, the generated meta query is transmitted to the internal processor (36).

[0051] As described above, the internal processor (36) reads a plurality of row vectors from the meta ISP table (M-ISP) and compares each of the read plurality of row vectors with an authorized meta query to detect a row vector that matches the meta query. At this time, if the internal processor (36) has meta row data stored in the meta ISP table (M-ISP) that includes information about the length of the row vector and the length of each of the plurality of meta ISP data included in the row vector along with the row vector, the internal processor (36) can receive the meta row data to distinguish the row vector, distinguish the plurality of meta ISP data from the distinguished row vector, and then compare them with the meta query.

[0052] In other words, since the length of the row vector and the length of each meta ISP data can be checked in advance, it is very easy to distinguish between the meta ISP data corresponding to each column and the row vector corresponding to the row, thereby enabling efficient processing of meta queries. Furthermore, since multiple row vectors can be compared with the meta query simultaneously, parallel processing is possible, which can significantly improve query processing performance.

[0053] To verify this, refer to FIGS. 3 and FIGS. 4. In a database where an ISP utilizing the existing preprocessing of FIG. 3 is applied, data from a data table (DB table) is read during the preprocessing process. The data read at this time may include a row delimiter (\n) for distinguishing rows and a column delimiter (|) for distinguishing data by column. Accordingly, the host processor (10) searches for the row delimiter (\n) and the column delimiter (|) to distinguish and detect each piece of data, and temporarily buffers each separated piece of data. Then, each buffered piece of data is copied, shifted to match the maximum size of the data, and zero-padded so that all data have the same size, and is stored again. Subsequently, when a query is authorized, the internal processor (36) receives the query, performs operations such as filtering the authorized query and the resized data, and transmits the data according to the result of the operation to the host processor (10).

[0054] At this time, the size of the data table (DB table) stored in the storage module (31) becomes very large compared to the size of the actual data stored. In particular, since large-scale data is stored in the database, this zero padding becomes a major waste factor in the storage capacity of the database.

[0055] In contrast, in one embodiment, as illustrated in FIG. 4, a meta ISP table (M-SIP) is separately stored in a storage module (31) and the row vectors converted to represent data in row units of a data table (DB table) are stored separately, so the internal processor (36) can read multiple row vectors from the meta ISP table (M-SIP). When a meta query converted from a query is applied, the applied meta query is compared in units of row vectors to identify the row vectors that match the meta query, and a row of the data table (DB table) corresponding to the row vector is selected. Then, the data of the selected row is transmitted to the host processor (10). At this time, multiple row vectors can be compared with the meta query in parallel and simultaneously, and multiple meta queries can be compared with the meta query in parallel with multiple row vectors and simultaneously. Thus, data can be filtered at high speed and transmitted to the host processor (10).

[0056] As mentioned above, in a database using conventional preprocessing, the size of each piece of data increases, resulting in significant waste of storage capacity. In contrast, in one embodiment, although a separate meta ISP table (M-SIP) and a meta DB table (M-DB) are additionally stored in the storage module (31) in addition to the data table (DB table), the size of the meta ISP table (M-SIP) and the meta DB table (M-DB) is very small, and this does not increase significantly even when there is a very large amount of data stored in the data table (DB table). Therefore, the query processing speed can be improved while reducing waste of storage capacity.

[0057] In the illustrated embodiments, each component may have different functions and capabilities in addition to those described above and may include additional components not described. Additionally, in one embodiment, each component may be implemented using one or more physically separated devices, or by one or more processors or a combination of one or more processors and software, and may not be clearly distinguished in specific operation as in the illustrated examples.

[0058] And the database acceleration device illustrated in FIG. 2 may be implemented in a logic circuit by hardware, firmware, software, or a combination thereof, or may be implemented using a general-purpose or specific-purpose computer. The device may be implemented using a hardwired device, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc. Additionally, the device may be implemented as a system-on-chip (SoC) including one or more processors and controllers.

[0059] In addition, the database acceleration device may be installed in the form of software, hardware, or a combination thereof on a computing device or server equipped with hardware elements. A computing device or server may refer to various devices that include, in whole or in part, communication devices such as communication modems for communicating with various devices or wired / wireless communication networks, memory for storing data for executing programs, and microprocessors for executing programs to perform calculations and commands.

[0060] FIG. 5 illustrates a database acceleration method according to one embodiment.

[0061] Referring to FIG. 5, a database acceleration method of one embodiment involves a host processor (10) distinguishing data in each column that has the same format in a data table (DB table) stored in a storage module (31) (51). Then, it is determined whether the data contained in each column is numeric data or text data (52). Then, if the distinguished data is numeric data, the numeric range according to the numeric data contained in the column is divided into a specified number of numeric partitions (53). Then, each numeric data contained in the column is converted into numeric metadata by one-hot encoding according to the divided numeric partitions (54). However, if it is text data rather than numeric data, all words of the text data contained in the column are mapped to one of the specified number of text partitions (55). Then, the text data is converted into text metadata by checking the text partition to which each word of each text data contained in the column is mapped and encoding (56). Here, the numeric metadata and text metadata are combined and referred to as meta ISP data.

[0062] When the data of each column of a data table (DB table) is converted into text metadata, the converted metadata is combined row by row to obtain a row vector, and a meta ISP table (M-ISP) containing the obtained row vector is created (57). At the same time, a meta DB table (M-DB) consisting of meta DB data containing encoding information indicating the method of converting the data of each column into meta ISP data can be created (58).

[0063] Subsequently, when a query is input, the method of converting data into meta ISP data using meta DB data stored in the meta DB table (M-DB) is checked, and the query is encoded according to the checked method to convert it into a meta query and transmitted to an internal processor (36) provided in the storage device (30) (59). Accordingly, the internal processor (36) reads multiple row vectors from the meta ISP table (M-ISP), determines a row vector among the read row vectors that matches the meta query, and determines whether data of the row corresponding to the determined row vector is transmitted from the data table (DB table) and received (60). When the data of the row is received, the received row data and the query are compared to detect data that matches the query (61).

[0064] Although FIG. 5 describes each process as being executed sequentially, this is merely an illustrative description, and a person skilled in the art can apply various modifications and variations by changing the order described in FIG. 5, executing one or more processes in parallel, or adding other processes, within the scope of not departing from the essential characteristics of the embodiment of the present invention.

[0065] And in the illustrated embodiments, each component may have different functions and capabilities in addition to those described below, and may include additional components in addition to those described below.

[0066] Although the present invention has been described in detail above through representative embodiments, those skilled in the art will understand that various modifications and equivalent alternative embodiments are possible therefrom. Accordingly, the true technical scope of protection of the present invention should be determined by the technical spirit of the appended claims.

Claims

Claim 1 A database acceleration method performed by a host processor in a database comprising a storage device having an internal processor and a storage module, a host processor, and memory, the method comprising: a step of determining whether data included in each column having data of the same format in a data table stored in the storage module is numeric data or text data; a step of converting the data included in the column into metadata of a specified number of bits by encoding differently depending on whether it is numeric data or text data; a step of obtaining a row vector by combining the converted metadata in the data table on a row-by-row basis and creating a meta table including the obtained row vector; a step of converting the query into a meta query in a manner according to the method of converting into metadata when a query is authorized; a step of transmitting the converted meta query to the internal processor; and a step in which the internal processor determines a row vector that matches the meta query among the row vectors stored in the meta table, and when the data of the row corresponding to the determined row vector in the data table is transmitted to the host processor, the host processor compares the transmitted data of the row with the query to detect data that matches the query. Claim 2 A database acceleration method according to claim 1, wherein the step of converting to metadata comprises, if the data is numeric data, dividing a numeric range according to the numeric data included in the column into a specified number of numeric partitions and converting each numeric data included in the column into numeric metadata by one-hot encoding according to the divided numeric partitions, and if the data is text data, mapping each word of the text data included in the column to one of the specified number of text partitions and verifying the text partition to which each word of the text data included in the column is mapped and encoding, thereby converting text data into text metadata. Claim 3 In paragraph 2, the step of converting to metadata is a database acceleration method that, if the number of words of text data included in the column exceeds the number of text partitions, sequentially cycles and duplicates each word across a plurality of text partitions. Claim 4 In paragraph 2, the step of converting into metadata is a database acceleration method that checks the frequency of occurrence of each word of text data included in the column and sequentially maps each word to a plurality of text partitions according to the checked frequency of occurrence. Claim 5 In paragraph 2, the step of converting into metadata is a database acceleration method that sequentially maps each word of the text data included in the column to a plurality of text partitions according to the order of occurrence. Claim 6 A database acceleration method according to claim 1, wherein the step of generating the meta table generates a meta ISP table composed of meta raw data including the row vector and length information of the row vector corresponding to the row vector, and stores it in the storage module. Claim 7 In claim 6, the step of generating the meta table is a database acceleration method comprising generating a meta DB table composed of meta DB data including encoding information indicating a method of converting data of each column of the data table into metadata, and storing it in the storage module. Claim 8 In claim 7, the step of converting into a meta query is a database acceleration method that converts the query into a meta query using the meta DB data included in the meta DB table. Claim 9 delete Claim 10 A database acceleration method according to claim 1, further comprising the step of converting the authorized new data into metadata and updating the meta table to include the converted metadata when new data included in the data table is authorized. Claim 11 A database acceleration device comprising a storage device having an internal processor and a storage module, a host processor, and memory, wherein the host processor performs the steps of: determining whether data included in each column having data of the same format in a data table stored in the storage module is numeric data or text data; encoding the data included in the column differently depending on whether it is numeric data or text data and converting it into metadata of a specified number of bits; combining the metadata converted in the data table on a row-by-row basis to obtain a row vector and creating a meta table including the obtained row vector; when a query is authorized, converting the query into a meta query in a manner according to the method of converting into metadata; transmitting the converted meta query to the internal processor; and when the internal processor determines a row vector that matches the meta query among the row vectors stored in the meta table and transmits the data of the row corresponding to the determined row vector in the data table to the host processor, comparing the transmitted data of the row with the query to detect data that matches the query. Claim 12 A database acceleration device according to claim 11, wherein the host processor, if the data is numeric, divides a numeric range according to the numeric data included in the column into a specified number of numeric partitions and converts each numeric data included in the column into numeric metadata by one-hot encoding according to the divided numeric partitions, and if the data is text, maps each word of the text data included in the column to one of the specified number of text partitions and converts the text data into text metadata by checking the text partition to which each word of the text data included in the column is mapped and encoding it. Claim 13 In claim 12, the host processor is a database acceleration device that sequentially cycles and duplicates each word among a plurality of text partitions when the number of words of text data included in the column exceeds the number of text partitions. Claim 14 In claim 12, the host processor is a database acceleration device that checks the frequency of occurrence of each word of text data included in the column and sequentially maps each word to a plurality of text partitions according to the checked frequency of occurrence. Claim 15 In claim 12, the host processor is a database acceleration device that sequentially maps each word of the text data included in the column to a plurality of text partitions according to the order of appearance. Claim 16 In claim 11, the database acceleration device wherein the host processor generates a meta ISP table, which is composed of meta raw data including the row vector and length information of the row vector, as the meta table and stores it in the storage module. Claim 17 In claim 16, the database acceleration device wherein the host processor creates a meta DB table as an additional meta table, which is composed of meta DB data including encoding information indicating a method of converting data of each column of the data table into metadata, and stores it in the storage module. Claim 18 In claim 17, the host processor is a database acceleration device that converts the query into the meta query using the meta DB data included in the meta DB table. Claim 19 delete Claim 20 In claim 11, the database acceleration device wherein the host processor converts the authorized new data into metadata when new data included in the data table is authorized, and updates the meta table to include the converted metadata.

Citation Information

Patent Citations

  • Programmable conversion hardware

    KR1020210029662A

  • Electronic device and operating method for the same

    KR1020210098247A

  • Method and System for updating file in a Filesystem

    KR1020240111560A

  • Device and method for searching video

    KR1020250112370A

  • Data storage device having internal hardware filter, and data processing system having the data storage device

    KR102251811B1