Integration device, integration method, and integration program

Abstract

To integrate a plurality of databases so as to avoid collision.SOLUTION: An integration device creates a virtual volume for each of databases and mounts the created virtual volume on storage positional information, acquires a DB name and the storage positional information from a first table of each of a plurality of devices, changes the DB name, associates the changed DB name and the storage positional information for each of the databases and generates a first integration table, acquires a schema name, a table name and a DB area ID from a second table of each of the plurality of devices, changes the schema name, associates the changed schema name, the table name, the changed DB name, the DB area ID for each of the databases and generates a second integration table, acquires the DB area ID and a relative file path of a file from a third table of each of the plurality of devices, associates the changed DB name, the table name, the changed DB name, and the DB area ID for each of the databases, and generates a third integration table.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The present invention relates to an apparatus, a method, and a program for integrating databases. [Background technology]

[0002] Patent Document 1 discloses a method for acquiring and storing information in multiple databases on a database storage system. Multiple point-in-time copies are acquired for each database. The point-in-time copies acquire data that has changed in the database since the previous point-in-time copy was acquired. A virtual database (VDB) is created by creating a file set in a data storage system. Each file in the file set created for the VDB is linked to a database block in the database storage system that is associated with the point-in-time copy of the source database. The file set associated with the VDB is mounted on a database server so that reading and writing to the file set are possible. A workflow based on a VDB enables efficient implementation of various database-based usage scenarios, such as testing and development, backup and recovery, and data warehouse construction.

[0003] Patent Document 2 describes techniques and solutions for storing and processing metadata, including instantiating database artifacts in a target system based on metadata for database artifacts maintained in a source system. The target system can query the source system for metadata related to the database artifacts in the source system. The target system can instantiate the database artifacts based on such metadata. The database artifacts in the target system are linked to the corresponding database artifacts in the source system. For example, the database artifacts in the target system are linked to the corresponding database artifacts in the source system by associating them with APIs that can be used to retrieve data or metadata for the corresponding database artifacts in the source system from the source system. The target system uses the corresponding APIs to retrieve additional data or metadata for the database artifacts in the target system.

[0004] Patent document 3 discloses a method for performing decision support in an environment including a data storage system and a plurality of host processors, at least some of which are connected to the data storage system, wherein the data storage system stores a working database, the method including the steps of continuously updating the working database through a selected one of the plurality of host processors, generating a copy of the working database while the working database is being continuously updated, using the copy of the database to generate a support copy of the working database, and using the support copy of the working database through another one of the plurality of host processors, wherein the steps of generating a copy of the working database while the working database is being continuously updated, using the copy of the database to generate a support copy of the database, and using the support copy for the purpose of implementing decision support functions through a different one of the plurality of host processors.

[0005] Patent Document 4 discloses a system and method for processing multiple data storage and retrieval management or manifest files in a virtual data storage system. Multiple separate management / manifest files used to track data management information stored on data storage devices are merged into a single management / manifest file, which is then used to manage the input or import of data, such as logical volumes, from one or more physical media. This single management / manifest file can be used, for example, in a media import operation to import media cartridges or devices into a media library, such as a data storage library.

[0006] Patent document 5 describes a method for receiving a client data access request directed to a first data container served by a first federation member. Data in the first requested data container may be used to resolve a context identifier and identify a volume location database (VLDB) associated with a second federation member serving a second data container. A lookup request may then be sent to the VLDB to identify one or more locations of the second data container. The client's original data access request is responded to with the identified one or more locations of the second data container.

[0007] The DBMS server device, virtualization switch device, and storage device in Patent Document 6 each hold a portion of the data mapping information that starts from a specific DB table accessed by a job, passes through the logical volume that stores this table, and reaches the physical disk device that stores the data on the volume in a distributed manner. The management server device acquires this portion of information from each device and aggregates the data mapping information for each job. When a failure occurs in any device or mechanism on the data mapping path, the data mapping information is referenced to identify the jobs affected by the failure. The management server device also controls the execution of these jobs.

[0008] The method and system of Patent Document 7 retrieves data from a multitenant database system having a relational data store and a non-relational data store, receives a request identifying data to be retrieved from the multitenant database system, retrieves one or more locations of the data to be retrieved based on the request, and generates a database query identifying a plurality of data elements to be retrieved based on the request, where the plurality of data elements includes one or more data elements residing in the non-relational data store and one or more other data elements residing in the relational data store, and executes the database query against the multitenant database system to retrieve the data.

[0009] Non-Patent Document 1 discloses the Denodo Virtual DataPort, an intermediary function that provides a structured and integrated view of data from all data sources present in the system, and is composed of a three-layer architecture consisting of a physical layer (wrapper), a logical layer, and a user layer.

[0010] Non-Patent Document 2 discloses the physical layer of Non-Patent Document 1. The physical layer is a wrapper for various data sources, extracts data (including metadata) from the source, converts it into a Virtual DataPort format, and returns the result to the user layer.

[0011] Non-Patent Document 3 discloses the logical layer of Non-Patent Document 1. The logical layer corresponds to the federation function of a DBMS. Metadata acquired via the physical layer is managed in the logical layer. The logical layer is also capable of pushing down processing and has a data caching function.

[0012] Non-Patent Document 4 discloses the user layer of Non-Patent Document 1. The user layer is an interface between the client application and the Virtual DataPort.

[0013] Non-Patent Document 5 discloses a transparent query function for files on cloud storage and data on DBMS (SQL, NoSQL). When the data source is a file on cloud storage, Dremio performs data conversion, making it possible to access the data in a unified format from the client. When the data source is a DBMS, a query is executed on the data source side to obtain the data, and then Dremio performs data conversion, making it possible to access the data in a unified format from the client. [Prior art documents] [Patent documents]

[0014] [Patent Document 1] International Publication No. WO2011 / 049839 [Patent Document 2] U.S. Patent No. 1,156,1976 [Patent Document 3] U.S. Patent No. 5,852,715 [Patent Document 4] U.S. Patent No. 7,925,680 [Patent Document 5] U.S. Patent No. 7,933,921 [Patent Document 6] Japanese Patent Application Laid-Open No. 2004-295811 [Patent Document 7] Japanese Patent Application Laid-Open No. 2015-146201 [Non-patent literature]

[0015] [Non-Patent Document 1] Denodo Community, Home / User Manual / Virtual DataPort Administration Guide / General Architecture, https: / / community.denodo.com / docs / html / browse / 8.0 / jp / vdp / administration / general_architecture / general_architecture, retrieved February 21, 2024 [Non-patent document 2] Denodo Community, Home / User Manual / Virtual DataPort Administration Guide / General Architecture / Physical Layer, https: / / community.denodo.com / docs / html / browse / 8.0 / jp / vdp / administration / general_architecture / physical_layer / physical_layer, retrieved February 21, 2024 [Non-patent document 3] Denodo Community, Home / User Manual / Virtual DataPort Administration Guide / General Architecture / Logical Layer, https: / / community.denodo.com / docs / html / browse / 8.0 / jp / vdp / administration / general_architecture / logical_layer / logical_layer, retrieved February 21, 2024 [Non-patent document 4] Denodo Community, Home / User Manual / Virtual DataPort Administration Guide / General Architecture / User Layer, https: / / community.denodo.com / docs / html / browse / 8.0 / jp / vdp / administration / general_architecture / user_layer / user_layer, retrieved February 21, 2024 [Non-Patent Document 5] Dremio Architecture Guide, DremioArchitectureGuide.pdf, retrieved February 21, 2024 Summary of the Invention [Problem to be solved by the invention]

[0016] In the technology of Patent Document 1, when integrating databases, data is collected and integrated via the database server of the business database system, which increases the load on the database server and raises concerns about a decrease in the performance of the business database system.

[0017] The technology in Patent Document 2 requires a framework for extracting and converting metadata on the source system side, which requires modifications to the source system. In addition, since metadata and data acquisition must be performed on the source system, the CPU load on the source system increases.

[0018] Patent Document 3 discloses copying of database volumes by storage, but does not disclose integration of volumes.

[0019] The techniques in Non-Patent Documents 1 to 4 require data conversion processing in the physical layer, which reduces performance, and also increase the load on the data source side because queries are executed on the data source side.

[0020] The technology in Non-Patent Document 5 requires data conversion processing in Dremio, which reduces performance. When the data source is a DBMS, the processing is performed on the data source side, which increases the load on the data source side.

[0021] When databases that are not intended to be integrated are copied and integrated using the virtual volume function of a storage device, the IDs (file IDs, table IDs, etc.) of different objects held in each database may end up being the same. In such cases, it is necessary to identify which database a certain ID originates from. In Patent Document 4, if there are duplicate IDs, the newer one takes priority. In Patent Document 7, data is acquired via a tenant DBMS, which requires data conversion each time.

[0022] The present invention aims to integrate multiple databases in a way that avoids conflicts. [Means for solving the problem]

[0023] An integrated device according to one aspect of the invention disclosed in the present application comprises a processor that executes a program and a memory that stores the program, and is capable of communicating with a plurality of devices, each having a database, wherein each of the plurality of devices has a first table, a second table, and a third table, wherein the first table has a DB name that is the name of the database and storage location information of the database within the device, the second table has a schema name that is the name of a schema that manages one or more tables within the device, a table name that is the name of the table, and a DB area ID that uniquely identifies a DB area that is a storage area for a file in the database, and the third table has the DB area ID and a relative file path of the file, and the processor performs a mount process that creates a virtual volume for each of the databases and mounts it on the storage location information, and a mount process that mounts the virtual volume for each of the plurality of devices on the storage location information. a first generation process for acquiring the DB name and the storage location information from one table, changing the DB name so that it is different for each database, and generating a first integrated table by associating the changed DB name with the storage location information for each database; a second generation process for acquiring the schema name, the table name, and the DB area ID from the second table of each of the plurality of devices, changing the schema name so that it is different for each database, and generating a second integrated table by associating the changed schema name, the table name, the changed DB name, and the DB area ID for each database; and a third generation process for acquiring the DB area ID and the relative file path of the file from the third table of each of the plurality of devices, and generating a third integrated table by associating the changed DB name, the table name, the changed DB name, and the DB area ID for each database. [Effects of the Invention]

[0024] According to the exemplary embodiment of the present invention, it is possible to integrate multiple databases so as to avoid conflicts. Objects, configurations and advantages other than those described above will become apparent from the following description of the embodiment. [Brief explanation of the drawings]

[0025] [Figure 1] FIG. 1 is a block diagram showing a first example of a system configuration of a virtual integrated system. [Figure 2] FIG. 2 is a block diagram showing a second system configuration example of the virtual integrated system. [Figure 3] FIG. 3 is a block diagram showing a system configuration example 3 of a virtual integrated system. [Figure 4] FIG. 4 is an explanatory diagram illustrating an example of the data structure of a database volume. [Figure 5] FIG. 5 is an explanatory diagram showing an example of embedding a DB area ID. [Figure 6] FIG. 6 is an explanatory diagram illustrating an example of virtual DB integration. [Figure 7] FIG. 7 is an explanatory diagram illustrating a first example of table conversion by virtual DB integration. [Figure 8] FIG. 8 is a flowchart illustrating a first example of a virtual integration process procedure. [Figure 9] FIG. 9 is a flowchart showing a first example of a query execution processing procedure. [Figure 10] FIG. 10 is a flowchart showing the zero copy process. [Figure 11] FIG. 11 is an explanatory diagram illustrating a second example of table conversion by virtual DB integration. [Figure 12] FIG. 12 is a flowchart illustrating a second example of the virtual integration process. [Figure 13] FIG. 13 is a flowchart illustrating a second example of a query execution process procedure. [Figure 14] FIG. 14 is an explanatory diagram illustrating a third example of table conversion by virtual DB integration. DETAILED DESCRIPTION OF THE INVENTION

[0026] <System configuration example> First, an example of the system configuration of a virtual integrated system will be described with reference to FIGS.

[0027] (Figure 1 On-premise configuration) 1 is a block diagram showing a system configuration example 1 (on-premise 10) of a virtual integrated system. The virtual integrated system 100 is an on-premise configuration having a first server 101, a first storage 102, a second server 103, and a second storage 104. The first server 101, the first storage 102, the second server 103, and the second storage 104 are communicatively connected by a bus 105.

[0028] The first server 101 has a processor 111 and a memory 112. The processor 111 controls the first server 101. The memory 112 serves as a working area for the processor 111. The memory 112 is a non-transitory or temporary recording medium. The memory 112 stores an integrated DB management table 113, an integrated DB object / DB area management table 114, an integrated DB area management table 115, an integrated DB buffer management table 116, an integrated master information generation module 117, and a data search module 118.

[0029] The integrated master information generation module 117 is a program that causes the processor 111 to execute an integrated master generation process. Through the integrated master generation process, an integrated DB management table 113, an integrated DB object / DB area management table 114, an integrated DB area management table 115, and an integrated DB buffer management table 116 are generated in the memory 112. The data search module 118 is a program that causes the processor 111 to execute a data search process.

[0030] The first storage 102 stores a virtual volume 121, integrated master information 122, and a data acquisition module 120. The virtual volume 121 stores snapshots from the second storage 104. The integrated master information 122 includes an integrated DB object / DB area management table 114, an integrated DB area management table 115, and an integrated DB buffer management table 116, all generated by the first server 101. The integrated master information 122 also includes a file-virtual volume correspondence management table 123. The data acquisition module 120 is a program that causes the processor 111 or a processor (not shown) in the first storage 102 to acquire data from the second storage 104.

[0031] The second server 103 has a processor 131 and a memory 132. The processor 131 controls the second server 103. The memory 132 serves as a working area for the processor 131. The memory 132 is a non-transitory or temporary recording medium. The memory 132 stores a DBMS (Database Management System) 133. The DBMS 133 is a program that causes the processor 131 to manage the database in the database volume 141 and to operate the database in response to requests from external software.

[0032] The second storage 104 stores a database volume 141 and a snapshot volume 142. The database volume 141 stores files. The database volume 141 also stores a DB management table 151, an object DB area management table 152, a DB area management table 153, and a DB buffer management table 154. The snapshot volume 142 stores snapshots, which are copies of the database. The snapshots are generated by the DBMS 133.

[0033] The virtual integrated system 100 quickly constructs a cross-site search environment for databases at each site having a second server 103 and a second storage 104, and suppresses the impact on operations at the site when analysis is performed.

[0034] The second server 103 and the second storage 104 are deployed at each base. If the virtual integrated system 100 is implemented in, for example, a manufacturer, the base is a manufacturing factory. In the second storage 104 at each base, a manufacturing DB with the same data structure is stored in the database volume 141. Also, if the virtual integrated system 100 is implemented in, for example, a medical institution, the base may be a hospital or a nursing care facility. A receipt DB is stored in the database volume 141 of the second storage 104 at the hospital, and a nursing care DB with a data structure different from the receipt DB is stored in the second storage 104 at the nursing care facility.

[0035] In either case, the virtually integrated system 100 can virtually integrate databases between bases.

[0036] In the following description, when a process is described using a program as the subject, it means that the processor 111, 131 or a device in which the processor 111, 131 is implemented is executing a program that realizes the function of the module.

[0037] (Figure 2 Cloud Configuration 1) 2 is a block diagram showing a system configuration example 2 (cloud 20) of the virtual integrated system 100. Cloud configuration 1 is a configuration example in which the virtual integrated system 100 is implemented on a cloud. Therefore, the first server 101 and the second server 103 are each constructed as virtual servers on the cloud system 200. In addition, the first storage 102 and the second storage 104 are constructed as cloud storages on the cloud system 200.

[0038] (Fig. 3 Cloud Configuration 2) 3 is a block diagram showing a system configuration example 3 (cloud 30) of the virtual integrated system 100. Cloud configuration 2 is a configuration example in which the first server 101 and the first storage 102 of the virtual integrated system 100 are implemented on the cloud 30. Therefore, the first server 101 and the first storage 102, and the second server 103 and the second storage 104 are communicably connected via a network 305 such as the Internet, a LAN (Local Area Network), or a WAN (Wide Area Network).

[0039] <Figure 4 Data structure of database volume 141> 4 is an explanatory diagram showing an example of the data structure of the database volume 141. The database volume 141 has, as its data structure, a DB directory 401, a table (object) 402, a DB area 403, a DB buffer 404, and a relative file path 405.

[0040] The DB directory 401 is information indicating the storage location of a database within the database volume 141. The table (object) 402 is a table of a relational database, and stores data obtained at a base (for example, data detected by a sensor installed in factory equipment or patient diagnosis information). The DB area 403 is made up of one or more files. The DB buffer 404 is a buffer area that temporarily stores files within the DB area 403. The relative file path 405 is information indicating the storage location of a file within the DB area 403. When the DB directory 401 and the relative file path 405 are combined, an absolute path is formed.

[0041] <Figure 5 Embedding DB area ID> Figure 5 is an explanatory diagram showing an example of embedding a DB area ID. Here, a B-tree index will be used as an example. The DB area ID is identification information that uniquely identifies the DB area 403. The DB area ID is embedded as a row ID along with a page ID and slot ID. Here, an example row ID is {10,100,3}. The DB area ID, page ID, and slot ID are identification numbers in ascending order starting from 1. "10" is the DB area ID, "100" is the page ID, and "3" is the slot ID. By referencing with the row ID, it is possible to access the slot with slot ID:3 on the page with page ID:100 in the DB area 403 identified by DB area ID:10.

[0042] <Figure 6 Virtual DB integration> Fig. 6 is an explanatory diagram showing an example of virtual DB integration. Fig. 6 shows an example of integrating database volumes 141 of two sets of the second server 103 and the second storage 104. Note that branch numbers are added to the reference numerals of the configuration in Fig. 4 to distinguish them from the configuration in Fig. 4.

[0043] Integrated DB 600 is created in first storage 102. Integrated DB 600 has sub-DB 601 and sub-DB 2. Sub-DB 601 includes DB directory 401-1, DB area 403-1, and relative file path 405-1. Sub-DB 602 includes DB directory 401-2, DB area 403-2, and relative file path 405-2. Tables (objects) 402-1 and 402-2 and DB buffers 404-1 and 404-2 are located outside sub-DB 601 and sub-DB 602.

[0044] <Figure 7 Table conversion example 1> Fig. 7 is an explanatory diagram showing Example 1 of table conversion by virtual DB integration. Fig. 7 illustrates an example of integrating two sets of database volumes 141 of the second server 103 and the second storage 104. In Fig. 7, the symbols of the tables in the second storage 104 in Fig. 1 are assigned branch numbers to distinguish the tables, but if no distinction is required, the tables will be described without the branch numbers.

[0045] 1, the database volumes 141 and the like of the two sets of second server 103 and second storage 104 are assigned sub-numbers in the same manner as in FIG. 7, such as second servers 103-1 and 103-2, and second storages 104-1 and 104-2.

[0046] (DB management table 151) The DB management table 151 is a table for managing databases in the database volume 141, and has fields of DB name 711 and DB directory 401. The DB name 711 is the name of a database. Specifically, for example, "DB1" which is the DB name 711 in the DB management table 151-1 is the name of the database in the second storage 104-1, and "DB1" which is the DB name 711 in the DB management table 151-2 is the name of the database in the second storage 104-2.

[0047] (Object DB area management table 152) The object / DB area management table 152 is a table that manages tables (objects) 402 and DB areas 403, and has the following fields: schema name 721, table name 722, and DB area ID 723. The schema name 721 is a group name of one or more tables (objects) 402. The table name 722 is the name of the table (object) 402. The DB area ID 723 is identification information that uniquely identifies the DB area 403.

[0048] (DB area management table 153) The DB area management table 153 is a table for managing DB areas, and has a DB area ID 723 and a relative file path 405 as fields.

[0049] (DB buffer management table 154) The DB buffer management table 154 is a table for managing the DB buffer 404, and has as fields a DB buffer name 741 and a DB area ID 723. The DB buffer name 741 is the name of the DB buffer 404.

[0050] 7, the DB management tables 151-1 and 151-2, object DB area management tables 152-1 and 152-2, DB area management tables 153-1 and 153-2, and DB buffer management tables 154-1 and 154-2 all have the same data structure and the same field values. Therefore, when virtually integrating these tables, they must be distinguished.

[0051] (Integrated DB management table 113) The integrated DB management table 113 is a table that virtually integrates the DB management tables 151-1 and 151-2. The integrated DB management table 113 has the fields sub-DB name 751 and DB directory 401. The sub-DB name 751 is the name of the sub-DB. In the example of Figure 6, "SDB1" is the sub-DB name 751 of the sub-DB 601, and "SDB2" is the sub-DB name 751 of the sub-DB 602.

[0052] In the integrated DB management table 113, sub-DB names 751 are set to distinguish between DB names 711. "SDB1" is the name of the sub-DB 601, and corresponds to "DB1", which is the DB name 711 in the DB management table 151-1. "SDB2" is the name of the sub-DB 602, and corresponds to "DB1", which is the DB name 711 in the DB management table 151-2.

[0053] Furthermore, in the integrated DB management table 113, in order to distinguish between the DB directories 401 of the sub-DBs 601 and 602, the value of the DB directory 401 of the sub-DB 601 is changed from " / mnt / db" to " / mnt / db1" in the DB management table 151-1. " / mnt / db1" specifies the virtual volume 121-1 corresponding to the database volume 141-1 of the second storage 104-1.

[0054] Similarly, the value of the DB directory 401 of the sub-DB 602 is changed from " / mnt / db" to " / mnt / db2" in the DB management table 151-2. " / mnt / db2" specifies the virtual volume 121-2 corresponding to the database volume 141-2 of the second storage 104-2 that stores the DB management table 151-2.

[0055] (Integrated DB object / DB area management table 114) The integrated DB object / DB area management table 114 is a table that virtually integrates the object / DB area management tables 152-1 and 152-2. The integrated DB object / DB area management table 114 has the following fields: a post-change schema name 752, a table name 722, a sub-DB name 751, and a DB area ID 723. The post-change schema name 752 is the name changed from the schema name 721.

[0056] In the integrated DB object and DB area management table 114, in order to distinguish between the schema names 721, the value "TPCH" of the schema name 721 in the object and DB area management table 152-1 is changed to the changed schema name 752 "TPCH1." Similarly, the value "TPCH" of the schema name 721 in the object and DB area management table 152-2 is changed to the changed schema name 752 "TPCH2."

[0057] Furthermore, since the integrated DB object and DB area management table 114 has a sub-DB name 751 , the table name 722 and DB area ID 723 that can be distinguished in the sub-DB are not distinguished for each object and DB area management table 152 .

[0058] (Integrated DB area management table 115) The integrated DB area management table 115 has the following fields: sub-DB name 751, DB area ID 723, and relative file path 405.

[0059] (Integrated DB buffer management table 116) The integrated DB buffer management table 116 has the following fields: a changed DB buffer name 753, a sub DB name 751, and a DB area ID 723. The changed DB buffer name 753 is a name changed from the DB buffer name 741. In order to distinguish the changed DB buffer name 753 in the integrated DB buffer management table 116, the value "BUF1" of the DB area ID 723 in the DB buffer management table 154-1 is changed to the changed DB buffer name 753 "BUF1," and the value "BUF1" of the DB area ID 723 in the DB buffer management table 154-2 is changed to the changed DB buffer name 753 "BUF2."

[0060] <Figure 8 Integrated master information generation process 1> 8 is a flowchart showing virtual integration processing procedure example 1. The integrated master information 122 includes an integrated DB management table 113, an integrated DB object / DB area management table 114, an integrated DB area management table 115, and an integrated DB buffer management table .

[0061] It is assumed that the user input information 800 specifies the DB directory 401 ( / mnt / db1, / mnt / db2), sub-DB name 751 (SDB1, SDB2), changed schema name 752 (TPCH1, TPCH2), and changed DB buffer name 753 (BUF1, BUF2).

[0062] (Step S801) The data acquisition module 120 acquires a snapshot of the snapshot volume 142 .

[0063] (Step S802) The integrated master information generation module 117 creates a virtual volume 121 for a database volume corresponding to the snapshot volume 142 from which the snapshot was acquired. The integrated master information generation module 117 also assigns a file descriptor to the virtual volume 121. The integrated master information generation module 117 sequentially assigns file descriptors to the virtual volumes 121 in ascending order starting from 1.

[0064] (Step S803) The integrated master information generation module 117 mounts the virtual volume 121 on the DB directory 401 specified in the user input information 800. Specifically, for example, the integrated master information generation module 117 mounts the virtual volume 121-1 on the DB directory 401 ( / mnt / db1) and mounts the virtual volume 121-2 on the DB directory 401 ( / mnt / db2). The integrated master information generation module 117 associates the file descriptor 910 obtained in step S802 with the virtual volume name 1001, which is the name of the virtual volume 121, to generate a file-virtual volume correspondence management table 123.

[0065] (Step S804) The integrated master information generation module 117 registers the sub-DB names 751 (SDB1, SDB2) and DB directories 401 ( / mnt / db1, / mnt / db2) in the integrated DB management table 113. In this way, the integrated DB management table 113 is generated in the integrated master information 122.

[0066] (Step S805) The integrated master information generation module 117 acquires the pre-change schema name 721 (TPCH), table name 722 (LINEITEM), and DB area ID 723 (10) from the object DB area management tables 152-1 and 152-2 of the database volumes 141-1 and 141-2.

[0067] (Step S806) The integrated master information generation module 117 sets the post-change schema name 752 (TPCH1, TPCH2) corresponding to the pre-change schema name 721 (TPCH), the sub-DB names 751 (SDB1, SDB2), the table name 722 (LINEITEM) acquired in step S805, and the DB area ID 723 (10) in the integrated DB object / DB area management table 114. In this way, the integrated DB object / DB area management table 114 is generated in the integrated master information 122.

[0068] (Step S807) The integrated master information generation module 117 acquires the DB area ID 723 (10) and the relative file path (area10) from the DB area management tables 153-1 and 153-2 of the database volumes 141-1 and 141-2.

[0069] (Step S808) The integrated master information generation module 117 sets the sub-DB name 751, the DB area ID 723(10) acquired in step S807, and the relative file path (area10) in the integrated DB area management table 115. In this way, the integrated DB area management table 115 is generated in the integrated master information 122.

[0070] (Step S809) The integrated master information generating module 117 acquires the pre-change DB buffer name 741 and DB area ID 723 from the DB buffer management tables 154-1 and 154-2 of the database volumes 141-1 and 141-2.

[0071] (Step S810) The integrated master information generation module 117 sets the post-change DB buffer name 753 (BUF1, BUF2) corresponding to the pre-change DB buffer name 741 (BUF1, BUF1), the sub-DB name 751 (SDB1, SDB2), and the DB area ID (10) in the integrated DB buffer management table 116. In this way, the integrated DB buffer management table 116 is generated in the integrated master information 122.

[0072] <Figure 9 Query execution process> 9 is a flowchart showing query execution processing procedure example 1. It is assumed that the query 900 is given a post-change schema name 752 (here, for example, "TPCH1") and a table name 722 (LINEITEM).

[0073] (Step S901) The data search module 118 determines whether or not DB area information has been acquired. Since it has not been acquired the first time (step S901: No), the process proceeds to step S902, where the data search module 118 executes name resolution (sub-DB resolution). If it has been acquired (step S901: Yes), there is no need to perform name resolution (sub-DB resolution) again, so the process proceeds to step S909.

[0074] (Step S902) The data search module 118 searches the integrated DB object / DB area management table 114 using the post-change schema name 752 (TPCH1) and table name 722 (LINEITEM) as keys, and obtains the sub-DB name 751 and DB area ID 723. In this example, "SDB1" is obtained as the sub-DB name 751, and "10" is obtained as the DB area ID 723.

[0075] (Step S903) The data search module 118 searches the integrated DB management table 113 using the sub-DB name 751 acquired in step S902 as a key, and acquires the DB directory 401. In this example, since the sub-DB name 751 is "SDB1", " / mnt / db1" is acquired as the DB directory 401.

[0076] (Step S904) The data search module 118 searches the integrated DB area management table 115 using the sub DB name 751 and DB area ID 723 as keys, and acquires the relative file path 405. In this example, "area10" is acquired as the relative file path 405.

[0077] (Step S905) The data search module 118 generates an absolute file path by combining the DB directory 401 and the relative file path 405, and opens the file specified by the absolute file path. In this example, the DB directory 401 is " / mnt / db1" and the relative file path 405 is "area10", so the absolute file path " / mnt / db1 / area10" is generated.

[0078] (Step S906) The data retrieval module 118 stores DB area information 911 in the execution context 901. In this example, by opening the file in step S905, "1" is obtained from the file as the file descriptor 910. The file descriptor 910 is identification information that uniquely identifies a file. The data retrieval module 118 stores DB area information 911 that associates "SDB1" as the sub DB name 751, "10" as the DB area ID 723, and "1" as the file descriptor 910.

[0079] (Step S907) The data search module 118 searches the integrated DB buffer management table 116 using the sub DB name 751 and DB area ID 723 as keys, and obtains the post-change DB buffer name 753. In this example, since the sub DB name 751 is "SDB1" and the DB area ID 723 is "10", "BUF1" is obtained as the post-change DB buffer name 753.

[0080] (Step S908) The data retrieval module 118 stores DB buffer information 912. The DB buffer information 912 is information that associates the sub DB name 751, the DB area ID 723, and the changed DB buffer name 753 acquired in step S907. In this example, the sub DB name 751, "SDB1," the DB area ID 723, "10," and the changed DB buffer name 753, "BUF1," are associated and stored in the DB buffer information 912.

[0081] By the processing of steps S902 to S908, name resolution (sub-DB resolution) is completed.

[0082] (Step S909) The data search module 118 determines whether or not the previous row ID is present. If the previous row ID is held (step S909: Yes), the process proceeds to step S911. If the previous row ID is not held (step S909: No), the process proceeds to step S910. If this is the first time (name resolution is executed), the process proceeds to step S910.

[0083] (Step S910) The data search module 118 sets the page ID to "0" and proceeds to step S912.

[0084] (Step S911) The data search module 118 obtains a page ID from the previous row ID. For example, as shown in Figure 5, if the previous row ID is {10, 100, 3}, the data search module 118 obtains "100" as the page ID. Then, the process proceeds to step S912.

[0085] (Step S912) The data search module 118 determines whether the page ID is smaller than the maximum number of pages. If the page ID is smaller than the maximum number of pages (step S912: Yes), the process proceeds to step S913. If the page ID is not smaller than the maximum number of pages (step S912: No), the query execution ends.

[0086] (Step S913) The data search module 118 determines whether the page specified by the page ID is cached in the DB buffer 404 specified in the DB buffer information 912. In this example, it determines whether the page is cached in BUF1. If the page is cached (step S913: Yes), the process proceeds to step S916. If the page is not cached (step S913: No), the process proceeds to step S914.

[0087] (Step S914) The data search module 118 secures a free entry in the DB buffer 404, and proceeds to step S915. In this example, a free entry is secured in BUF1.

[0088] (Step S915) The data retrieval module 118 identifies the sub DB name 751 and DB area ID 723 corresponding to the file descriptor 910 in the DB area information 911. In this example, the sub DB name 751 is "SDB1," which corresponds to the sub DB 601. The DB area ID 723 is "10." Therefore, the data retrieval module 118 accesses the file of the DB area 403-1 in the sub DB 601, whose DB area ID 723 is "10." By distinguishing the databases by the sub DB name in this way, conflicts in the DB area ID 723 are avoided and the correct file can be accessed without changing the DB area ID 723. The data retrieval module 118 then reads the page identified by the page ID from the file. The read page is stored in the free entry in the DB buffer 404 allocated in step S914. This read process is a zero-copy process. The zero-copy process will be described later with reference to FIG. 10.

[0089] (Step S916) The data search module 118 determines whether or not the read target row exists in the read page. If the previous row ID exists in step S909, the read target row is the row ID, and if the previous row ID does not exist in step S909, the read target row is the first row of the page. If the read target row exists, the process proceeds to step S918. If the read target row does not exist, the process proceeds to step S917.

[0090] (Step S917) Since the read target row does not exist in the read page, the data search module 118 increments the page ID and returns to step S912.

[0091] (Step S918) Since the read target row exists in the read page, the data search module 118 reads the value of the row, acquires the row ID, and ends the process. The acquired row ID becomes the previous row ID in step S909.

[0092] <Figure 10 Zero copy processing> 10 is a flowchart showing the zero copy process. The zero copy process is a process executed in step S915 of FIG. 9, and is a process for replicating a snapshot in the snapshot volume 142 of the second storage 104 to the virtual volume 121 of the first storage 102. The zero copy process is executed by the data search module 118 and the data acquisition module 120.

[0093] The data search module 118 reads a page specified by a page ID from a file specified by a file descriptor 910 based on input information 1010. A specific description will be given below. The input information 1010 includes the file descriptor 910, a read position, and a read length.

[0094] Furthermore, in the zero copy process, reference is made to the file-virtual volume correspondence management table 123. The file-virtual volume correspondence management table 123 has a file descriptor 910 and a virtual volume name 1001.

[0095] (Step S1011) The data search module 118 refers to the file-virtual volume correspondence management table 123 and converts the read position within the file specified by the file descriptor 910 into a read position in the virtual volume 121. Specifically, for example, when file descriptor "1", read position "100", and read length "30" are given as input information 1010, the file and virtual volume 121 have a one-to-one correspondence, so the data search module 118 identifies the virtual volume name 1001 "Virtual Vol1" that corresponds to the file descriptor "1". The read position "100" and read length "10" are used as is.

[0096] (Step S1012) The data search module 118 issues a read request to the virtual volume 121 identified by the conversion in step S1011. The read request includes the virtual volume name 1001 "Virtual Vol1", the read position "100", and the read length "10".

[0097] (Step S1013) The data search module 118 copies the read data to the free entry in the DB buffer 404 secured in step S914.

[0098] (Step S1021) The data acquisition module 120 acquires input information 1020 from the data search module 118 and determines whether the data has been read in response to the read request in step S1012. The input information 1020 is the "virtual volume name, read position, and read length" included in the read request.

[0099] Specifically, for example, the data acquisition module 120 stores a list of "virtual volume name, read position, read length" that have already been read in the first storage 102, compares this list with the "virtual volume name, read position, read length" included in the read request, and determines that the data has been read if the range specified by the read position and read length in the virtual volume included in the read request is already included in the list. If the data has been read (step S1021: Yes), the process proceeds to step S1023. If the data has not been read (step S1021: No), the process proceeds to step S1022.

[0100] (Step S1022) The data acquisition module 120 reads data from the snapshot volume 142 of the second storage 104 .

[0101] (Step S1023) The data acquisition module 120 copies the data that has been read in step S1021 or that has been read in step S1022 to an area that the data acquisition module 120 has prepared in the first storage 102. In step S1013, the data search module 118 copies the data that has been read here to a free entry in the DB buffer 404 that has been secured in step S914.

[0102] <Figure 11 Table conversion example 2> Fig. 11 is an explanatory diagram showing a second example of table conversion by virtual DB integration. Fig. 11 shows an example of table conversion when the database formats differ between the second storages 104-1 and 104-2. Differences from Fig. 7 will be described.

[0103] (Integrated DB management table 113) The integrated DB management table 113 has fields for sub-DB name 751, DB directory 401, and conversion process 1100. The conversion process 1100 specifies a program for converting the database format. If a change program is registered in the conversion process 1100 of the integrated DB management table 113, the first server 101 will apply the conversion program.

[0104] In the example of Figure 11, "conversion program 1" is specified in the conversion process 1100 in the entry for SDB1, and "NULL" is specified in the conversion process 1100 in the entry for SDB2, i.e., no conversion program is specified. A conversion program is a program that converts a database format. Specifically, for example, "conversion program 1" is a program that converts the database format of second storage 104-1 to the database format of second storage 104-2.

[0105] <Figure 12 Integrated master information generation process 2> Fig. 12 is a flowchart showing a virtual integration process procedure example 2. Fig. 12 shows the process of generating integrated master information 122 by the table conversion of Fig. 11. The differences from Fig. 8 will be explained. User input information 1200 is information in which a conversion program is added to user input information 800.

[0106] (Step S1204) The integrated master information generation module 117 registers the sub-DB names 751 (SDB1, SDB2), DB directories 401 ( / mnt / db1, / mnt / db2), and conversion programs in the integrated DB management table 113. In this way, the integrated DB management table 113 is generated in the integrated master information 122.

[0107] <Figure 13 Query execution process> 13 is a flowchart showing a query execution processing procedure example 2. Differences from FIG. 9 will be described.

[0108] (Step S1303) The data search module 118 searches the integrated DB management table 113 using the sub-DB name 751 acquired in step S902 as a key, and acquires the DB directory 401 and the conversion process 1100. In this example, since the sub-DB name 751 is "SDB1", " / mnt / db1" is acquired as the DB directory 401, and "conversion program 1" is acquired as the conversion process 1100.

[0109] (Step S1306) The data search module 118 stores the DB area information 911 and the conversion process 1100 in the execution context 901. In this example, when the file is opened in step S905, "1" is obtained from the file as the file descriptor 910. The file descriptor 910 is identification information that uniquely identifies a file. The data search module 118 stores the DB area information 911 that associates the sub DB name 751 "SDB1," the DB area ID 723 "10," and the file descriptor 910 "1."

[0110] (Step S1319) The data search module 118 determines whether or not the conversion process 1100 exists in the execution context 901. If the conversion process 1100 exists (step S1319: Yes), the process proceeds to step S1320. If the conversion process 1100 does not exist (step S1319: No), the query execution ends.

[0111] (Step S1320) The data search module 118 converts the data (the row value read in step S918) using the conversion program acquired as the conversion process 1100.

[0112] <Figure 14 Table conversion example 3> Fig. 14 is an explanatory diagram showing a third example of table conversion by virtual DB integration. Fig. 14 shows an example of conversion between different databases. Differences from Fig. 7 will be explained.

[0113] (DB management table 151) In the DB management table 151-1, the DB name 711 is "Receipt DB" and the DB directory 401 is " / mnt / receptdb." On the other hand, in the DB management table 151-2, the DB name 711 is "Nursing care DB" and the DB directory 401 is " / mnt / kaigodb."

[0114] (Object DB area management table 152) In the object / DB area management table 152-1, the schema name 721 is "Medical Care," the table name 722 is "Examination," and the DB area ID 723 is "10." On the other hand, in the object / DB area management table 152-2, the schema name 721 is "Nursing Care," the table name 722 is "Care Plan," and the DB area ID 723 is "10."

[0115] (Integrated DB management table 113) In the integrated DB management table 113, the receipt DB has the sub-DB name 751 "SDB1" and its DB directory 401 " / mnt / receptdb" is registered, while the nursing care DB has the sub-DB name 751 "SDB2" and its DB directory 401 " / mnt / kaigodb" is registered.

[0116] (Integrated DB object / DB area management table 114) In the integrated DB object / DB area management table 114, the changed DB buffer name 753 corresponding to the sub-DB name 751 "SDB1" is "Medical" and the table name 722 is "Examination," and the schema name 721 corresponding to the sub-DB name 751 "SDB2" is "Nursing Care" and the table name 722 is "Care Plan." In this way, virtual integration is possible even between different databases.

[0117] In this way, according to this embodiment, it is possible to integrate multiple databases in a way that avoids conflicts in the DB area IDs 403.

[0118] The present invention is not limited to the above-described embodiments, and includes various modifications and equivalent configurations within the spirit and scope of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to configurations including all of the described configurations. Furthermore, part of the configuration of one embodiment may be replaced with the configuration of another embodiment. Furthermore, the configuration of another embodiment may be added to the configuration of one embodiment. Furthermore, part of the configuration of each embodiment may be added to, deleted from, or replaced with other configurations.

[0119] Furthermore, the aforementioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole in hardware, for example by designing them as integrated circuits, or may be realized in software by a processor interpreting and executing a program that realizes each function.

[0120] Information such as programs, tables, files, etc. that realize each function can be stored in storage devices such as memory, hard disks, SSDs (Solid State Drives), or recording media such as IC (Integrated Circuit) cards, SD cards, and DVDs (Digital Versatile Discs).

[0121] In addition, the control lines and information lines shown are those that are considered necessary for explanation, and do not necessarily represent all the control lines and information lines that are necessary for implementation. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]

[0122] 100 Virtual Integrated System 101 First Server 102 First Storage 103 Second Server 104 Second Storage 111 processors 112 memory 113 Integrated DB Management Table 114 Integrated Object DB Area Management Table 115 Integrated DB area management table 116 Integrated DB buffer management table 117 Integrated Master Information Generation Module 118 Data Search Module 120 Data Acquisition Module 121 Virtual Volumes 122 Integrated Master Information 123 File-Virtual Volume Correspondence Management Table 141 database volumes 142 snapshot volumes 151 DB management table 152 Object DB area management table 153 DB area management table 154 DB buffer management table 401 DB Directory 403 DB Area 404 DB Buffer 405 Relative File Path 711 DB name 721 Schema Name 722 table name 741 DB buffer name 751 Sub DB Name 752 Schema name after change 753 DB buffer name after change 800 User-entered information 900 queries 901 Execution Context 910 file descriptors 912 DB buffer information 1100 Conversion Processing 1200 User-entered information

Claims

1. An integrated device having a processor that executes a program and a memory that stores the program, and capable of communicating with a plurality of devices each having a database, each of the plurality of devices has a first table, a second table, and a third table; the first table includes a DB name that is the name of the database and storage location information of the database within the device; the second table has a schema name that is the name of a schema that manages one or more tables in the device, a table name that is the name of the table, and a DB area ID that uniquely identifies a DB area that is a storage area for files in the database, the third table has the DB area ID and the relative file path of the file; The processor: a mounting process for creating a virtual volume for each of the databases and mounting it on the storage location information; a first generation process of acquiring the DB name and the storage location information from the first table of each of the plurality of devices, changing the DB name so that it is different for each of the databases, and associating the changed DB name with the storage location information for each of the databases to generate a first integrated table; a second generation process for acquiring the schema name, the table name, and the DB area ID from the second table of each of the plurality of devices, changing the schema name so that it is different for each of the databases, and generating a second integrated table by associating the changed schema name, the table name, the changed DB name, and the DB area ID for each of the databases; a third generation process for acquiring the DB area ID and the relative file path of the file from the third table of each of the plurality of devices, and generating a third integrated table by associating the changed DB name, the table name, the changed DB name, and the DB area ID for each database; An integrated device characterized by performing the above.

2. 10. The integrated device of claim 1, an input process for receiving an input of a query including the changed schema name and the table name; a first acquisition process for searching the second integrated table based on the query input by the input process to acquire the changed DB name and the DB area ID; a second acquisition process for searching the first integrated table based on the changed DB name acquired by the first acquisition process to acquire the storage location information; a third acquisition process for searching the third integrated table based on the changed DB name and the DB area ID acquired by the first acquisition process to acquire the relative file path; an open process that generates an absolute file path based on the storage location information acquired by the second acquisition process and the relative file path acquired by the third acquisition process, and opens a specific file identified by the absolute file path; a fifth generation process for generating DB area information by associating the changed DB name, the DB area ID, and a file descriptor of the specific file opened by the open process; a search process for searching for the specific file from the DB area identified by the DB area ID in a virtual volume corresponding to the database identified by the changed DB name, based on the DB area information generated by the fifth generation process; An integrated device characterized by performing the above.

3. 3. The integrated device of claim 2, The processor: Execute a determination process to determine whether the DB area information has been generated; The processor: If the DB area information has not been generated by the determination process, the first acquisition process, the second acquisition process, the third acquisition process, the open process, and the fifth generation process are executed, and if the DB area information has been generated by the determination process, the first acquisition process, the second acquisition process, the third acquisition process, the open process, and the fifth generation process are not executed. An integrated device characterized by:

4. 3. The integrated device of claim 2, In the first generation process, the processor generates the first integrated table by associating, for each database, the changed DB name, the storage location information, and a conversion process that can define a conversion program for converting data from the first tables of each of the plurality of devices; In the search process, if the conversion program is defined for the changed DB name, the processor converts the data in the specific file using the conversion program. An integrated device characterized by:

5. 10. The integrated device of claim 1, a fourth table having a DB buffer name, which is the name of a DB buffer that serves as a buffer area for the DB area, and the DB area ID; The processor: a fourth generation process for acquiring the DB buffer name and the DB area ID from the fourth table of each of the plurality of devices, changing the DB buffer name so that it is different for each of the databases, and generating a fourth integrated table by associating the changed DB buffer name, the table name, the changed DB name, and the DB area ID for each of the databases; An integrated device characterized by performing the above.

6. 3. The integrated device of claim 2, a fourth table having a DB buffer name, which is the name of a DB buffer that serves as a buffer area for the DB area, and the DB area ID; The processor: a fourth generation process for acquiring the DB buffer name and the DB area ID from the fourth table of each of the plurality of devices, changing the DB buffer name so that it is different for each of the databases, and generating a fourth integrated table by associating the changed DB buffer name, the table name, the changed DB name, and the DB area ID for each of the databases; a fourth acquisition process of searching the fourth integrated table based on the changed DB name and the DB area ID to acquire the changed DB buffer name; a sixth generation process for generating DB buffer information by associating the changed DB name, the DB area ID, and the changed DB buffer name; An integrated device characterized by performing the above.

7. An integration method executed by an integration device having a processor that executes a program and a memory that stores the program, and capable of communicating with a plurality of devices each having a database, the method comprising: each of the plurality of devices has a first table, a second table, and a third table; the first table includes a DB name that is the name of the database and storage location information of the database within the device; the second table has a schema name that is the name of a schema that manages one or more tables in the device, a table name that is the name of the table, and a DB area ID that uniquely identifies a DB area that is a storage area for files in the database, the third table has the DB area ID and the relative file path of the file; The processor: a mounting process for creating a virtual volume for each of the databases and mounting it on the storage location information; a first generation process of acquiring the DB name and the storage location information from the first table of each of the plurality of devices, changing the DB name so that it is different for each of the databases, and associating the changed DB name with the storage location information for each of the databases to generate a first integrated table; a second generation process for acquiring the schema name, the table name, and the DB area ID from the second table of each of the plurality of devices, changing the schema name so that it is different for each of the databases, and generating a second integrated table by associating the changed schema name, the table name, the changed DB name, and the DB area ID for each of the databases; a third generation process for acquiring the DB area ID and the relative file path of the file from the third table of each of the plurality of devices, and generating a third integrated table by associating the changed DB name, the table name, the changed DB name, and the DB area ID for each database; An integration method comprising:

8. An integration program that causes a processor to execute an integration process for integrating databases in a plurality of devices, each of the plurality of devices has a first table, a second table, and a third table; the first table includes a DB name that is the name of the database and storage location information of the database within the device; the second table has a schema name that is the name of a schema that manages one or more tables in the device, a table name that is the name of the table, and a DB area ID that uniquely identifies a DB area that is a storage area for files in the database, the third table has the DB area ID and the relative file path of the file; the processor, a mounting process for creating a virtual volume for each of the databases and mounting it on the storage location information; a first generation process of acquiring the DB name and the storage location information from the first table of each of the plurality of devices, changing the DB name so that it is different for each of the databases, and associating the changed DB name with the storage location information for each of the databases to generate a first integrated table; a second generation process for acquiring the schema name, the table name, and the DB area ID from the second table of each of the plurality of devices, changing the schema name so that it is different for each of the databases, and generating a second integrated table by associating the changed schema name, the table name, the changed DB name, and the DB area ID for each of the databases; a third generation process for acquiring the DB area ID and the relative file path of the file from the third table of each of the plurality of devices, and generating a third integrated table by associating the changed DB name, the table name, the changed DB name, and the DB area ID for each database; An integrated program characterized by executing the above.

Images