Database management apparatus and method capable of unified processing of relational data, graph data and vector data

Abstract

A database management device and a method capable of integrated processing of relational data, graph data, and vector data are disclosed. The database management device includes a relational storage for storing relational data including a plurality of tables, a graph storage for storing graph data including vertices and edges connecting the vertices, a vector storage for storing vector data, and an integration operator that performs graph search, join, mapping, or vector similarity search according to the storage location of operands. Attribute data of each vertex or each edge of the graph data is stored in a table of the relational storage, and the vector storage stores vector data for attribute data existing in a column defined as a vector column among the columns of the tables of the relational storage.

Description

Technology Field

[0001] Embodiments of the present invention relate to a database management system (DBMS), and more specifically, to a database management device and method capable of processing queries for relational data, graph data, and vector data in an integrated manner. Background Technology

[0002] Due to technological advancements and the expansion of the digital environment, vast amounts of data are being accumulated across various industrial sectors. In particular, large volumes of data are continuously accumulating in fields such as social network services, finance, e-commerce, biotechnology, and AI services, leading to an increasing need for data analysis technologies to utilize this data effectively. Most industries store and manage data in a structured form within relational databases (RDBs). Relational databases provide a standardized, table-based data storage method that stores attribute information of individual data and relationships between data in a table format. Consequently, there is a growing need for technologies capable of effectively analyzing data within relational databases. In response to this need, graph analysis technology has been developed to extract data from relational databases in the form of graphs and analyze the extracted graphs. Graph analysis technology can effectively analyze complex relationships between data through graph exploration and perform analysis of complex patterns within highly interconnected data.

[0003] However, current graph analysis technologies have limitations in that they fail to provide sufficient performance in terms of response time, throughput, and graph size for property graph processing. In particular, when processing interactive queries that require immediate user feedback, current graph analysis technologies struggle with the immediate execution of queries involving complex property graph patterns. For instance, when providing personalized trending feeds on social media, detecting fraud patterns in financial transactions, or offering customized product recommendations in e-commerce through interactive queries, current graph analysis technologies require an increased number of join operations between relational database tables. Consequently, query processing performance degrades, and there is a problem where the graph size is limited by memory capacity.

[0004] Meanwhile, Retrieval-Augmented Generation (RAG) technology is being used to enhance the factuality and reasoning capabilities of Large Language Models (LLMs). RAG is a technology that searches for the information necessary for an LLM to generate answers in external repositories or search systems. RAG is generally implemented as a vector-centric search. RAG provides LLMs with search results obtained from unstructured text based on embedding vector similarity, but it has limitations in utilizing graph search results. The problem to be solved

[0005] The technical problem that the embodiments of the present invention aim to solve is to provide a database management device and a method capable of processing queries for relational data, graph data, and vector data in an integrated manner. means of solving the problem

[0006] An example of a database management device according to an embodiment of the present invention for achieving the above technical objectives comprises: a relational storage for storing relational data including a plurality of tables; a graph storage for storing graph data including vertices and edges connecting the vertices; a vector storage for storing vector data; and a query processing framework configured to process an integrated query for data stored in the relational storage, the graph storage, and the vector storage; wherein the query processing framework comprises an integration operator that performs a graph search operation, a lookup or join operation, a mapping operation, or a vector similarity search operation depending on the data type or data storage location of the operands.

[0007] An example of a database management method according to an embodiment of the present invention for achieving the above technical objectives comprises: a step of storing relational data including a plurality of tables in a relational storage; a step of storing graph data including vertices and edges connecting the vertices in a graph storage; a step of storing vector data for attribute data existing in a column defined as a vector column among the columns of the tables in the relational storage in a vector storage; and a step of performing a query using an aggregation operator that performs a graph search operation, a lookup or join operation, a mapping operation, or a vector similarity search operation according to the storage location of the operands. Effects of the invention

[0008] According to an embodiment of the present invention, queries for relational data, graph data, and vector data can be processed by integrating them using an integration operator. In one embodiment, a conventional vector-centric search RAG can be extended to a RAG for integrated search of vector, graph, and relational data. Brief explanation of the drawing

[0009] FIG. 1 is a drawing illustrating an example of a database management device including a plurality of storage units. FIG. 2 is a drawing illustrating an example of a database management device using an integrated query. FIG. 3 is a drawing illustrating a first embodiment of a database management device according to an embodiment of the present invention, FIG. 4 is a diagram illustrating an example of relational data of a relational storage according to an embodiment of the present invention. FIG. 5 is a diagram illustrating an example of graph data of a graph storage according to an embodiment of the present invention. FIG. 6 is a diagram illustrating an example of vector data of a vector repository in an embodiment of the present invention. FIG. 7 is a drawing illustrating an example of a storage format for graph data according to an embodiment of the present invention. FIG. 8 is a drawing illustrating an example of an integrating operator according to an embodiment of the present invention. FIG. 9 is a drawing illustrating a second embodiment of a database management device according to an embodiment of the present invention. FIG. 10 is a drawing illustrating an example of a query operation structure according to an embodiment of the present invention. FIG. 11 is a drawing illustrating an example of a query plan according to an embodiment of the present invention. FIG. 12 is a flowchart illustrating an example of a database management method according to an embodiment of the present invention, FIG. 13 is a diagram illustrating an example of a method for performing RAG using a database management device according to an embodiment of the present invention, and, FIG. 14 is a diagram illustrating an example of a simulation result of a database management device according to an embodiment of the present invention. Specific details for implementing the invention

[0010] Hereinafter, a database management device and a method according to an embodiment of the present invention will be examined in detail with reference to the attached drawings.

[0011] FIG. 1 is a drawing illustrating an example of a database management device including a plurality of storage units.

[0012] Referring to FIG. 1, the database management device (100) includes a relational store, a graph store, a vector store, a relational DBMS, a graph DBMS, and a vector DBMS. The database management device (100) is implemented by simply integrating each store and each DBMS that retain the characteristics of the native system. This method is called 'out-of-DB integration of native system'.

[0013] The database management device (100) receives relational queries, graph queries, and vector queries for a relational DBMS, a graph DBMS, and a vector DBMS, respectively. For example, the relational DBMS performs relational queries by referencing a relational store, the graph DBMS performs graph queries by referencing a graph store, and the vector DBMS performs vector queries by referencing a vector store. That is, each DBMS performs a search of each store individually.

[0014] The RAG application sends individual queries to each DBMS for the RAG and receives the results. The RAG application integrates the results received from each DBMS and provides them to the LLM. However, since the context length of the LLM is generally limited, the RAG application can only provide a predetermined number of results to the LLM. Because searches in each repository are performed separately (i.e., multi-tum retrieval), it is impossible to know in advance how many search results each DBMS will output. Therefore, each DBMS generates more intermediate results than is actually needed. The RAG application requires a process to filter a predetermined number of results from the intermediate results generated by each DBMS, sorting them in order of relevance.

[0015] Therefore, the database management device (100) of the present embodiment generates more intermediate results than necessary and performs unnecessary data transmission, resulting in inefficient use of resources. In addition, the database management device (100) of the present embodiment requires implementing and managing a DBMS for each storage separately along with multiple storages, so high operating costs are incurred.

[0016] Figure 2 is a diagram illustrating an example of a database management device using an integrated query.

[0017] Referring to FIG. 2, the database management device (200) includes a relational storage and a relational DBMS. The relational DBMS processes an integrated query including relational queries, graph queries, and vector queries. While the embodiment of FIG. 1 transmits relational queries, graph queries, and vector queries to their respective DBMSs and aggregates the results of their execution, the embodiment of FIG. 2 transmits a query (hereinafter referred to as a 'unified query') in which each query (relational query, graph query, and vector query) for relational data, graph data, and vector data is integrated to the relational DBMS. This structure is called 'in-DB non-native integration'.

[0018] In one embodiment, the integrated query can be implemented as a Structured Query Language (SQL) extended query. Table 1 is an example of a SQL extended query.

[0019]

[0020] Referring to Table 1, the integrated query may include SQL / PGQ (SQL with Property Graph Queries) syntax for graph pattern matching in addition to the general query, and may include "<->" operators for vector similarity search. In addition to this, the integrated query can be implemented in various forms that include queries such as graph pattern matching or vector similarity together with existing SQL, and is not limited to the present embodiment. However, for the convenience of explanation below, it is assumed that the integrated query is given as in Table 1.

[0021] In the embodiment of FIG. 2, the relational DBMS performs an integrated query. In other words, the relational DBMS integrates and performs graph matching, vector similarity search, and filtering of relational data together (i.e., single-turn retrieval). Therefore, the relational DBMS can produce a certain number of results as shown in "LIMIT 5" of Table 2, and can avoid producing unnecessary intermediate results as shown in FIG. 1.

[0022] However, in this embodiment, since the data is stored as relational data in a relational store, the relational DBMS cannot perform the integration query as is. For example, the relational DBMS must translate the graph traversal included in the integration query into sequences of relational joins. Additionally, vector data must be stored in the relational store as a general array type. As a result, significant overhead occurs in graph traversal and vector search.

[0023] FIG. 3 is a drawing illustrating a first embodiment of a database management device according to an embodiment of the present invention.

[0024] Referring to FIG. 3, a database management device (hereinafter referred to as the 'DB management device') (300) includes a relational storage (310), a graph storage (320), a vector storage (330), and a unified operator (340). The database management device (300) of this embodiment is referred to as an 'in-DB native integration' structure.

[0025] The DB management device (300) may be implemented as a computing device including a processor, various storage media including memory, and input / output devices. For example, the DB management device (300) may be implemented as a PC (Personal Computer), a data server, or a portable device. Each operation of the DB management device (300) described in this embodiment may be implemented as software (program), loaded onto a storage medium such as memory, and then performed by a processor.

[0026] The relational storage (310), graph storage (320), and vector storage (330) may be implemented as non-volatile mass storage media (e.g., HDD (Hard Disk Drive), SSD (Solid-State Drive), etc.). Alternatively, the relational storage (310), graph storage (320), and vector storage (330) may be implemented as disk storage devices suitable for OLTP (Online Transaction Processing). Alternatively, the relational storage (310), graph storage (320), and vector storage (330) may be implemented as NVMe SSD, PCIe SSE, SATA SSD, SSD configured with RADI, storage array-based SSD, etc. Alternatively, the relational storage (310), graph storage (320), and vector storage (330) may be implemented as memory. Alternatively, the relational storage (310), graph storage (320), and vector storage (330) may each be implemented as different types of storage media.

[0027] A relational storage (310) stores relational data. The relational data includes at least one table. Each table may include at least one attribute data, as in the example of FIG. 4. In one embodiment, the relational storage (310) may be implemented as a general relational database (RDB). Alternatively, the relational storage (310) may be implemented as a PostgreSQL table. In addition to this, various existing types of relational data may be applied to this embodiment.

[0028] The graph storage (320) stores graph data (i.e., graph topology) including vertices and edges. The graph stored in the graph storage (320) may be an attribute graph containing properties for vertices and / or edges. Graph data may manage graph topology using an adjacency-list. An example of graph data is illustrated in FIG. 5.

[0029] In one embodiment, the graph storage (320) may store a set of vertices, a set of edges, pointer information indicating connections between vertices and / or edges, and pointer information indicating connections between a vertex or edge and an attribute table of the relational storage (110). The graph storage (320) may store graph data in various formats. In one embodiment, the graph storage (320) may store graph topology in the format of vertex records and edge records. Examples of vertex records and edge records are illustrated in FIG. 7.

[0030] The vertices and edges constituting the graph data are associated with tables in the relational storage (310). In one embodiment, some of the tables in the relational storage (310) may be represented as vertices of the graph data, and all or part of the remainder of the tables may be represented as edges of the graph data. Additionally, attribute data of each vertex of the graph data and / or attribute data of each edge may be stored in at least one table in the relational storage (310). For example, the relational storage (310) may include vertex tables that store attribute data for each vertex of the graph data and attribute tables that store attribute data for each edge.

[0031] The vector storage (330) stores vector data. In one embodiment, the vector storage (330) stores vector data for attribute data existing in a column defined as a vector column in a table of the relational storage (310). Vector data can be generated using an embedding model. An example of vector data is illustrated in FIG. 6.

[0032] In one embodiment, the DB management device (300) may include an indexing mechanism for each repository (310, 320, 330) according to data representation. For example, to accelerate attribute-based filtering and access to graph elements (vertices, edges, etc.), the relational repository (310) and the graph repository (320) may support a B-tree index. Additionally, the DB management device (100) may support at least one index including HNSW (Hierarchical Navigable Small Worlds), IVF (Inverted File Index), Vamana, etc., for Approximate Nearest Neighbor (ANN) search for vector data in the vector repository (330).

[0033] The aggregation operator (340) is an operator defined to perform a graph traversal operation, a lookup / join operation, a mapping operation, or a vector similarity search operation depending on the data type or data storage location of the operands. The aggregation operator (130) may be a binary operator that receives two operands. The aggregation operator is discussed again in FIG. 8.

[0034] The query may be a query for relational data stored in the relational storage (310) (relational query), a query for graph data stored in the graph storage (320) (graph query), a query for vector data stored in the vector storage (vector query), or a query that is a combination of relational data, graph data, and vector data (integrated query). An example of an integrated query is listed in Table 1. This embodiment is described assuming that the query is an integrated query.

[0035] In one embodiment, the DB management device (300) includes a query processing framework that processes integrated queries for data stored in a relational storage (310), a graph storage (320), and a vector storage (330), and the query processing framework may include an integration operator. For example, the DB management device (300) can perform operations such as graph exploration, vector similarity search, mapping, and lookup / join within the same execution framework based on the integration operator (340). In other words, the DB management device (300) integrates and executes queries for relational data, graph data, and vector data within a single framework and provides the results.

[0036] In another embodiment, the DB management device (300) analyzes a query and generates a query operation structure (i.e., an operator graph) based on an integrated operator, and performs the query by referencing the relational storage (310), graph storage (320), and vector storage (330) together according to the query operation structure, and outputs the result of the query execution. Since operations on graph, vector, and relational data are performed within a single framework, an optimal sequence combination of operations for performing an integrated query can be generated. The method of generating a query operation structure based on an integrated operator (340) and performing a query is examined again in FIGS. 10 and FIGS. 11.

[0037] FIG. 4 is a diagram illustrating an example of relational data in a relational storage according to an embodiment of the present invention, FIG. 5 is a diagram illustrating an example of graph data in a graph storage according to an embodiment of the present invention, and FIG. 6 is a diagram illustrating an example of vector data in a vector storage according to an embodiment of the present invention.

[0038] Referring to FIG. 4, relational data stored in a relational storage includes at least one table. The types and number of tables stored in the relational storage can be defined in various ways depending on the embodiment. For convenience of explanation, this embodiment shows only one table related to 'beekeeping'.

[0039] In one embodiment, relational data may include structured tables, such as a relational database. Each table may include rows and columns, and may include an identifier (or primary key) and at least one attribute data. In another embodiment, each table may further include a foreign key. A row represents a single data item and may correspond to an entity and a tuple within the table. A column represents a specific attribute of the data. An identifier (or key) is a value used to uniquely identify each row. Relational data may include a set of interrelated tables. For example, in a relational store, each table is an independent unit of data, but they may be connected to one another using foreign keys, etc.

[0040] In the example of Fig. 4, the table contains three attribute data: 'entity', 'timestamp', and 'chunk'. Additionally, the table contains tuples of 'beekeeper', 'colony', 'Honey', and 'Queen' in each row. An identifier (ID) (or key) is assigned to each row.

[0041] Referring to FIG. 5, graph data stored in a graph storage includes a graph topology containing vertices and edges. An edge is a line connecting two vertices. In one embodiment, the graph data may be data of an attribute graph containing properties for vertices or edges.

[0042] A relational store stores attribute data using a table, and a graph store can store the connection relationships between each attribute data stored in the relational store as a graph topology. The graph of this embodiment is an example in which each element (Beekeeper, Colony, Hive, Honey, Queen) of the table in FIG. 4 is represented as a vertex.

[0043] Graph data may include identifiers (IDs) and labels for each vertex and edge, connection relationship data (pointers, etc.) between graph elements (vertices or edges), and connection relationship data between graph elements and a relational database. The identifiers (IDs) of vertices and edges may be the same value as the identifier (ID) of the table corresponding to the relational storage or values ​​that map to each other. A label refers to a label assigned to the table corresponding to a vertex or edge. For example, if the label 'beekeeping' is assigned to the table in FIG. 4, the label of each vertex in FIG. 5 becomes 'beekeeping'. Graph data may be stored in the graph storage in various formats. For example, graph data may be stored in a vertex record and edge record format such as FIG. 7.

[0044] Referring to Fig. 6, the vector data stored in the vector store is a vector value for a chunk. A chunk is attribute data existing in a column defined as a vector column among the columns of the tables in the relational store.

[0045] For example, if the 'chunk' column in the table of Fig. 4 is defined as a vector column, the vector storage stores vector data for attribute data (i.e., chunk1, chunk2, chunk3, etc.) existing in the 'chunk' column of Fig. 4. Vector data can be generated through an embedding model. Since the method of generating vector data for chunks through an embedding model is already a widely known method, further explanation regarding it is omitted.

[0046] Each vector data stored in the vector store can be assigned an identifier. The identifier for each vector data can be the same as the identifier of a row in the corresponding table in the relational store. In other words, each row in the relational store maintains a one-to-one correspondence with each vector data.

[0047] The vector storage can store vector data in a vector-specific storage structure and assign an ANN index. Various existing vector-specific storage structures may be applied to this embodiment and are not limited to specific examples. Furthermore, various types of indexes may be used in the vector storage and are not limited to ANN indexes.

[0048] FIG. 7 is a diagram illustrating an example of a storage format for graph data according to an embodiment of the present invention.

[0049] Referring to FIG. 7, graph data (700) includes vertex records (700) and edge records (750). Vertex records (700) and edge records (750) may exist by label. For example, if there are three types of tables in a relational store, namely User, Post, and Comment tables, and three types of labels (400) such as 'User, Post, Comment' exist as graph vertices, then vertex records for the User label, vertex records for the Post label, and vertex records for the Comment label exist, respectively. Additionally, if two types of labels (410) are defined as graph edges, edge records exist for each label.

[0050] The vertex record (700) includes a vertex identifier field (704), a label field (706), an output edge pointer field (708), an input edge pointer field (710), and an attribute-tuple pointer field (712) pointing to the location of a relational store where attribute data of the vertex is stored (i.e., a tuple of the corresponding table). In another embodiment, the vertex record (700) may further include a header field (702).

[0051] The vertex identifier field (704) stores the identifier of each vertex. The label field (706) indicates which label (e.g., the label of the User table, the label of the Post table, the label of the Comment table) the vertex data belongs to for the vertex record (700). The header field (702) may include information distinguishing whether the record is a vertex record or an edge record.

[0052] The output edge pointer stored in the output edge pointer field (708) is a pointer (i.e., an address) pointing to an edge pointing outward from the vertex, and the input edge pointer stored in the input edge pointer field (710) is a pointer pointing to an edge pointing outward to the vertex. In one embodiment, when there are multiple output edges of the same label at a vertex, only a pointer to one of the multiple output edges of the same label (e.g., the most recently inserted output edge) may be stored in the vertex record (700). For example, if there are multiple output edges for a first label at a vertex, the output edge pointer of one of the multiple output edges of the first label is stored in the output edge pointer field (708) of the vertex record. In another example, if there are both an output edge for a first label and an output edge for a second label at a vertex, the output edge pointer of the first label and the output edge pointer of the second label are respectively stored in the output edge pointer field (708) of the vertex record.

[0053] Additionally, if there are multiple input edges with the same label at a vertex, the input edge pointer field (710) of the vertex record may store a pointer to any one of the multiple input edges with the same label (e.g., the most recently inserted input edge). If there are both an input edge for the first label and an input edge for the second label at a vertex, the input edge pointer for the first label and the input edge pointer for the second label are respectively stored in the input edge pointer field (710) of the vertex record.

[0054] The edge record (750) stores an edge identifier field (754), a label field (756), a source vertex pointer field (758), a destination vertex pointer field (760), an adjacent output edge pointer field (762), an adjacent input edge pointer field (764), and an attribute-tuple pointer (768) pointing to the location of a relational store where attribute data of the edge is stored (i.e., a tuple of the corresponding table). In another embodiment, the edge record (750) may further include a header field (752).

[0055] The edge identifier field (754) is an identifier that distinguishes each edge. The label field (756) indicates which label (i.e., which table) the edge data belongs to for the edge record (550). The header field (752) may include information such as distinguishing whether the record is a vertex record or an edge record.

[0056] The source vertex pointer (758) and the destination vertex pointer (760) are pointers pointing to the source vertex and destination vertex of an edge. The adjacent output edge pointer (762) is a pointer pointing to an adjacent edge output from the source vertex of the source vertex pointer (758), and the adjacent input edge pointer (764) is a pointer pointing to an adjacent edge input to the destination vertex of the destination vertex pointer (760). In other words, the adjacent output edge pointer (762) of the edge record (750) is data regarding the adjacent edge output along with the corresponding edge, and the adjacent input edge pointer (764) is data regarding the adjacent edge input along with the corresponding edge.

[0057] FIG. 8 is a diagram illustrating an example of an integrated operator according to an embodiment of the present invention.

[0058] Referring to FIG. 8, the aggregation operator (810) performs at least one operation (820) among a graph search operation, a lookup / join operation, a mapping operation, or a vector similarity search operation depending on the type or storage location of the operand (800). In one embodiment, the aggregation operator (810) may be a binary operator that takes two operands (H1, H2) (800) as input.

[0059] If both the first operand (H1) and the second operand (H2) are data or graph elements of a graph store, the integration operator (810) performs a graph search operation. If both the first operand (H1) and the second operand (H2) are data or relational data of a relational store, the integration operator (810) performs a join operation of the two data. If both the first operand (H1) and the second operand (H2) are data or vector data of a vector store, the integration operator (810) performs a vector similarity search.

[0060] If the first operand (H1) is data or relational data in a relational store and the second operand (H2) is data or graph element in a graph store, the integration operator (810) performs a mapping operation between the data (or relational data) in the relational store and the data (or graph element) in the graph store.

[0061] If the first operand (H1) is data or relational data in a relational store and the second operand (H2) is data or vector data in a vector store, the integration operator (810) performs a mapping operation between the data (or relational data) in the relational store and the data (or vector data) in the vector store.

[0062] If the first operand (H1) is data or a graph element of a graph store and the second operand (H2) is data or a vector data of a vector store, the integration operator (810) performs a mapping operation between the data (or graph element) of the graph store and the data (or vector data) of the vector store.

[0063] The DB management device (300) of FIG. 3 utilizes an integration operator (810) capable of performing graph exploration, attribute lookup / join, mapping, and vector similarity search depending on the data type (graph data, vector data, relational data) or storage location of the operands, so there is no need to perform a data conversion process as in FIG. 2. Since the DB management device (300) processes graph exploration, join, mapping, and vector similarity search using a single integration operator (810) without unnecessary data conversion processes, it can improve query processing performance for complex queries. In addition, by using the integration operator, it is possible to identify and perform the optimal order of operations suitable for the characteristics of the operands. The method for identifying the optimal order of operations will be examined again in FIG. 10 and FIG. 11.

[0064] FIG. 9 is a drawing illustrating a second embodiment of a database management device according to an embodiment of the present invention.

[0065] Referring to FIG. 9, the DB management device (900) includes a query plan section (910), a query processing framework (915), an aggregation operator (920), a vector operator (930), a graph operator (932), a relational operator (934), a relational storage (940), a graph storage (950), and a vector storage (960). Since the configuration of the aggregation operator (920), the relational storage (940), the graph storage (950), and the vector storage (960) is the same as that of the first embodiment of FIG. 3, further description is omitted.

[0066] The query plan unit (910) analyzes the query and extracts the structure of multiple operations required for query execution. An example of a query operation structure is illustrated in FIG. 10. In one embodiment, the query plan unit (910) may perform operations such as interpreting the query and generating an intermediate representation (IR), and defining a query operation structure based on the generated intermediate representation. An intermediate representation may be a structured data format that represents operands, operators, and operation relationships included in the query. For example, if the integrated query in Table 1 is analyzed to identify operands, operators, and operation relationships, and then represented as a query operation structure in a graph, it is as shown in FIG. 10. Various existing query analysis techniques may be used to generate the query operation structure and are not limited to specific examples.

[0067] In another embodiment, the query plan unit (910) can generate a query plan that defines the optimal order relationship of multiple operations required to execute a query. An example of a query plan is illustrated in FIG. 11. The query plan unit (910) can generate multiple subplans that include various order relationships of multiple operations for executing a query and determine the optimal subplan among the subplans that minimizes the cost of computing resources.

[0068] The query processing framework (915) can perform a combined query on data stored in a relational store (940), a graph store (950), and a vector store (960) using a combined operator (920), a vector operator (930), a graph operator (932), and a relational operator (934). The vector operator (930), the graph operator (932), and the relational operator (934) may be existing operators for each store (940, 950, 960).

[0069] In one embodiment, the query processing framework (915) may perform a vector similarity search using a vector operator (930), perform a search operation on graph data using a graph operator (932), and perform a join operation on relational data using a relational operator (934). If the query includes only vector operations, only search operations between vertices or edges of a graph, or only operations between attribute tables of relational data, the query processing framework (220) may perform searches on each repository using a vector operator (930), a graph operator (932), or a relational operator (934). If the query includes an integrated query for vector data, graph data, and relational data, the query processing framework (915) may integrate and process various queries within a single framework using an integration operator (920).

[0070] FIG. 10 is a drawing illustrating an example of a query operation structure according to an embodiment of the present invention, and FIG. 11 is a drawing illustrating an example of a query plan according to an embodiment of the present invention.

[0071] Referring to FIG. 10, the DB management device (900) generates a query operation structure for executing a query. For example, when the DB management device (900) receives the integrated query of Table 1, it can analyze the integrated query to extract operands, operators, operation relationships, etc., and generate a query operation structure.

[0072] Referring to FIG. 11, the DB management device (900) can generate multiple subplans including various sequence combinations of multiple operations required for query execution, and determine an optimal query plan among the multiple subplans based on computing resource costs.

[0073] In one embodiment, the DB management device (900) can generate a subplan by combining the order of operations from a lower degree to a higher degree. Here, the degree refers to the total number of vertices included in the operation.

[0074] First, the DB management device (900) calculates the cost for various first-order (i.e., one vertex) operations based on the query operation structure. The DB management device (900) calculates the cost required to access and read each vertex record, each edge record, each table, and the cost required for vector similarity checks. Here, the cost may be the CPU operation cost, disk I / O, etc. required for the operation. The method for calculating the cost may be defined in advance.

[0075] When the DB management device (900) completes the cost calculation for the first-order operation, it calculates the cost for various combinations of second-order operations in the query operation structure (Fig. 10). The second-order operation is an operation involving two vertices. The second-order operation may be a graph search, join, mapping, or vector similarity search using an integration operator. For example, in the query operation structure of Fig. 10, the second-order operations may be the first operation (Op1), the second operation (Op2), the third operation (Op3), and the fourth operation (Op4), respectively.

[0076] When the cost calculation for a second-order operation is completed, the DB management device (900) generates various combinations of third-order operations and calculates the cost. The third-order operations can be various combinations such as {Op1-Op2}, {Op1-Op3}, etc. In this way, the DB management device (900) can calculate multiple subplans and the cost of each subplan by combining the entire operation of the query operation structure in various orders.

[0077] The embodiment of FIG. 12 illustrates a case where the order of operations from Operation 1 (Op1) to Operation 4 (Op4) is optimal for a query plan. Operations 1 (Op1) to Operation 4 (Op4) are all defined as aggregation operators. Each symbol of the aggregation operator in this embodiment is defined in FIG. 8. The DB management device (900) performs each operation according to the order of operations defined in the query plan.

[0078] The first operation (Op1) is an operation that maps the E1 vector to the E1 vertices in order of proximity to 'question' according to the "ORDER BY" operation.

[0079] The second operation (Op2) is an operation that searches for the R edge from vertex E1.

[0080] The third operation (Op3) is the operation of searching for vertex E2 on edge R.

[0081] The fourth operation (Op4) maps the E2 attribute at the E2 vertex and processes the filtering condition.

[0082] In one embodiment, the DB management device (900) can perform a query using a volcano-based execution model (i.e., an iterator model). For example, a vector similarity search can generate candidates progressively through an 'open / next / close' interface, and additional candidates can be generated through next() calls as needed by the upper operator. At least one of the vector similarity search, graph traversal, lookup / join, and mapping operations is connected in a pipeline, and even when combined with filter conditions, it can produce k accurate results for the result set after filtering.

[0083] The DB management device (900) can perform intermediate results such as vector similarity search, graph search, lookup / join, and mapping operations based on an iterator model in a pipeline form that directly transmits intermediate results between operators without materializing them. In other words, in the query plan of FIG. 11, the DB management device (900) can perform intermediate results of the first operation (Op1) directly to the operator of the second operation (Op1) without a materialization process of temporarily storing the intermediate results of the first operation (Op1) on a disk, and can also transmit the intermediate results of the second operation (Op2) to the next operator without a materialization process.

[0084] FIG. 12 is a flowchart illustrating an example of a database management method according to an embodiment of the present invention.

[0085] Referring to FIG. 12, a DB management device (300, 900) stores relational data including a plurality of tables in a relational storage, stores graph data including vertices and edges connecting the vertices in a graph storage, and stores vector data for attribute data existing in a column defined as a vector column among the columns of the tables in the relational storage in a vector storage (S1200). In one embodiment, some of the plurality of tables in the relational storage may be represented as vertices of the graph data, and all or part of the remainder of the plurality of tables may be represented as edges of the graph data. Additionally, attribute data of vertices and / or edges may be stored in the relational storage.

[0086] The DB management device (300, 900) performs a query using an aggregation operator that performs graph search, lookup / join, mapping, or vector similarity search according to the storage location of the operands (S1210). An example of an aggregation operator is illustrated in FIG. 8. In one embodiment, the DB management device (300, 900) performs at least one of a graph search operation, a lookup or join operation, a mapping operation, and a vector similarity search operation in a pipeline manner using the aggregation operator, and can output a predefined number of results for a result set.

[0087] In another embodiment, the DB management device (300, 900) can analyze a query to generate a query operation structure and generate a query plan that optimizes the order relationship of multiple operations included in the query operation structure. The DB management device (300, 900) can perform operations according to the order defined in the query plan. Examples of a query operation structure and a query plan are illustrated in FIGS. 10 and FIGS. 11.

[0088] FIG. 13 is a diagram illustrating an example of a method for performing RAG using a database management device according to an embodiment of the present invention.

[0089] Referring to FIG. 13, the RAG device is connected to the DB management device (300, 900) of FIG. 3 or 9. The RAG device can provide various RAG modes and various database systems. For example, the RAG device can provide a 'Vector RAG' mode that performs conventional vector-based RAG and an 'Omni RAG' mode that enables integrated searching of vector, graph, and relational data using the DB management device (300, 900) of the present embodiment.

[0090] The RAG device receives a selection of a RAG mode (Vector RAG mode or Omni RAG mode) from the user (①). This embodiment is described assuming that Omni RAG mode is selected.

[0091] The RAG device receives a knowledge domain (e.g., agriculture, computer science, law, mixed fields, etc.) from the user (②). The RAG device receives a selection from the user of an LLM to be used for generating an answer (③). When the user enters a question (④), the RAG device requests and receives data necessary for generating an LLM answer from the DB management device (300, 900) and provides it to the LLM, and the LLM generates and outputs an answer (⑤).

[0092] The RAG device can display the results provided by the DB management device (300, 900) in various forms (⑥). For example, the RAG device can display the search results as a graph of vertices and edges (6.1), as relational data (6.2), or in chunks (6.3).

[0093] FIG. 14 is a diagram illustrating an example of a simulation result of a database management device according to an embodiment of the present invention.

[0094] Referring to Fig. 14, the results of an evaluation using four datasets (Agriculture, Law, Computer Science (CS), and Mixed) of the UltraDomain benchmark are illustrated. The DB management device according to an embodiment of the present invention is named 'AkasicDB'. AkasicDB was compared with the 'PGVector+AGE', 'Milvus+Neo4j', and 'Neo4j Vector' systems. Here, 'PGVector+AGE' refers to an 'in-DB non-native integration' system based on PostgreSQL provided through the extension of vector and graph functions, and 'Milvus+Neo4j' refers to an 'of-DB integration' system in which relational data with keys and attributes is stored in Neo4j, graph data is managed by Neo4j, and vector data is managed by Milvus. 'Neo4j Vector' refers to an 'in-DB non-native integration' system that uses a fixed query plan. In the 'Neo4j Vector' system, graph traversal and filtering are performed first in Neo4j, and then vector search is performed through vector expansion.

[0095] In this simulation, latency was measured using TTFT (Time-to-first-token), which includes search and creation times. The upper part of the table in Fig. 14 shows the answer quality of the 'vector RAG' and 'Omni RAG' in Fig. 13 using the winning ration evaluated by an LLM as a judge. 'vector RAG' refers to a conventional vector-centric search RAG, and 'Omni RAG' refers to a RAG based on integrated search of vector, graph, and relational data based on the DB management device (300, 900) of this embodiment. For all datasets, it can be seen that OmniRAG exhibits 4–28% higher performance compared to VectorRAG. The lower part of the table in Fig. 14 shows system efficiency. It can be seen that AkasicDB achieves the lowest search time for all datasets.

[0096] The present invention can also be implemented as computer-readable program code on a computer-readable recording medium. A computer-readable recording medium includes all types of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. Additionally, computer-readable recording media can be distributed across networked computer systems, allowing computer-readable code to be stored and executed in a distributed manner.

[0097] The present invention has been described above with reference to its preferred embodiments. Those skilled in the art will understand that the present invention may be embodied in modified forms without departing from the essential characteristics of the invention. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the invention is defined by the claims, not by the foregoing description, and all variations within the scope of the claims should be interpreted as being included in the invention.

Claims

Claim 1 A database management device comprising: a relational storage for storing relational data including a plurality of tables; a graph storage for storing graph data including vertices and edges connecting the vertices; a vector storage for storing vector data; and a query processing framework configured to process integrated queries on data stored in the relational storage, the graph storage, and the vector storage; wherein the query processing framework comprises an integration operator that performs a graph search operation, a lookup or join operation, a mapping operation, or a vector similarity search operation depending on the data type or data storage location of the operands. Claim 2 A database management device according to claim 1, wherein attribute data of each vertex or each edge of the graph data is stored in a table of the relational storage, and the vector storage stores vector data for attribute data existing in a column defined as a vector column in the table of the relational storage. Claim 3 A database management device according to claim 1, characterized in that some of the plurality of tables of the relational storage are represented as vertices of the graph data, and all or part of the remainder of the plurality of tables are represented as edges of the graph data. Claim 4 A database management device according to claim 1, wherein the integration operator performs a graph search operation if both the first operand and the second operand are data or graph elements of the graph storage, performs a lookup or join operation if both the first operand and the second operand are data or relational data of the relational storage, performs a vector similarity search operation if both the first operand and the second operand are data or vector data of the vector storage, and performs a mapping operation if the data types or data storages of the first operand and the second operand are different from each other. Claim 5 A database management device according to claim 1, wherein the query processing framework performs integrated queries on the relational store, the graph store, and the vector store based on the integration operator. Claim 6 A database management device according to claim 1, wherein the graph storage comprises: a vertex record including, for each vertex, an output edge pointer, an input edge pointer, and an attribute-tuple pointer pointing to the location of the relational storage where attribute data of the corresponding vertex is stored; and an edge record storing, for each edge, a source vertex pointer, a destination vertex pointer, an adjacent output edge pointer, an adjacent input edge pointer, and an attribute-tuple pointer pointing to the location of the relational storage where attribute data of the corresponding edge is stored. Claim 7 A database management device according to claim 1, wherein the query processing framework performs at least one of a graph search operation, a lookup or join operation, a mapping operation, and a vector similarity search operation in a pipeline manner using the integration operator, and outputs a predefined number of results for a result set. Claim 8 A database management method characterized by comprising: a step of storing relational data including a plurality of tables in a relational storage; a step of storing graph data including vertices and edges connecting the vertices in a graph storage; a step of storing vector data for attribute data existing in a column defined as a vector column in a table of the relational storage in a vector storage; and a step of performing a query using an aggregation operator that performs a graph search operation, a lookup or join operation, a mapping operation, or a vector similarity search operation depending on the data type or storage location of the operands. Claim 9 A database management method according to claim 8, wherein the step of performing the query comprises: performing at least one of a graph search operation, a lookup or join operation, a mapping operation, and a vector similarity search operation in a pipeline manner using the aggregation operator, and outputting a predefined number of results for a result set. Claim 10 A database method according to claim 8, wherein the step of performing the query comprises: a step of performing a graph search operation if both the first operand and the second operand are data or graph elements of the graph store; a step of performing a lookup / join operation if both the first operand and the second operand are data or relational data of the relational store; a step of performing a vector similarity search if both the first operand and the second operand are data or vector data of the vector store; and a step of performing a mapping operation if the data types or data stores of the first operand and the second operand are different from each other. Claim 11 A database management method according to claim 8, characterized in that some of the plurality of tables of the relational storage are represented as vertices of the graph data, and all or part of the remainder of the plurality of tables are represented as edges of the graph data. Claim 12 A computer-readable recording medium storing a computer program for performing the method described in paragraph 8.

Images