KR102174957B1 - Transaction control method to synchronize DML statements in relational database to NoSQL database - Google Patents

Abstract

An embodiment of the present invention discloses a transaction control method for synchronizing DML statements of a relational database to a NoSQL database. The disclosed transaction control method is a method in which a synchronization proxy server synchronizes transaction DML data of a source RDBMS to a NoSQL DBMS, wherein the synchronization proxy server adds the meta information of the source RDBMS, Sync_iid and Sync_uid columns for recovery history, and A preparatory step of creating a storage and a data structure for controlling the data, and performing an initialization operation of a synchronization operation by creating a storage and a data structure for loading into the replication NoSQL DBMS; A transaction control step of internally managing and processing a transaction of a source RDBMS by changing the DML of INSERT and UPDATE in order for the synchronization proxy server to receive the packet from the network and analyze it, and to process a NoSQL data conversion failure; A NoSQL conversion step of processing a corresponding NoSQL conversion after the synchronization proxy server completes transmission of the transaction-committed data to the client; And a NoSQL loading step of loading the DML NoSQL data converted in the NoSQL conversion step into a replica NoSQL DBMS.

Description

Transaction control method to synchronize DML statements in relational database to NoSQL database}

The present invention relates to a synchronization technology for heterogeneous database systems, and more particularly, to store data in fixed format of schema and columns of RDBMS in a NoSQL database when replicating transaction change data of RDBMS to NoSQL database. It relates to the control method.

In general, the database system (DBMS) is a relational database (RDBMS) mainly used to store data because stable data management through transactions was an important issue. However, with the emergence of web 2.0 environments and big data in recent years, RDBMS faced the challenge of'increasing the cost required to process data'. In other words, as the amount of data and traffic increases exponentially, when using a relational database designed to run on a single machine, the cost of improving the performance of the equipment (Scale-up: vertical expansion) increases exponentially.

In order to solve this problem, unlike RDBMS, by giving up some of the features of the distributed computing system, which are the features of the existing RDBMS, consistency and availability, but ensuring partition tolerance, Scale- Out), a technology called NoSQL (Not Only SQL) appeared.

However, because NoSQL gave up some of the consistency and validity, there was a problem that it could not provide a transaction with ACID (Atomicity: atomicity, Consistenty: consistency, Isolation: isolation, Durability: persistence) characteristics.

In order to solve this problem, the'NoSQL-based transaction management method and system' announced in Korean Patent Office Registered Patent Publication (B1) as registration number 10-1755276 is accessed using an interface provided by the database. It manages the domain, which is a virtual database that manages the relationship information of the virtual key that can access the data using the interface provided by the transaction management system and managed within the transaction management system in response to the physical key and the physical key. A domain management unit, a matching block management unit that manages a matching block having as data a key matching map that stores a plurality of virtual keys managed in each domain and a physical key relationship corresponding thereto, and a unit of work in any one domain. A transaction execution unit that performs an operation according to a transaction, which is a set of operations, and stores a plurality of virtual keys used to perform a transaction including at least one of data addition and change operations, and a physical key relationship corresponding thereto. It consists of a work key management unit that manages the work key map, and a deletion key management unit that manages a list of deletion keys, which is information about virtual keys that are deleted according to the execution of a transaction.

The above registered patent provides a transaction function that supports data consistency for multiple keys by allowing users to access through a domain, which is a virtual DBMS that manages virtual keys based on NoSQL. There is a problem that cannot be applied to replicate and synchronize by converting the original RDBMS data to a NoSQL DBMS.

The object of the present invention is to solve this problem because completely different data from the original can be replicated when replicating transaction-modified data from an RDBMS to a NoSQL database, and to convert data in a fixed format of the schema and columns of the RDBMS to a NoSQL database with a free format. To store, it provides a transaction control method for synchronizing DML (Data Manipulation Language) statements of a relational database to a NoSQL database.

An embodiment of the present invention discloses a transaction control method for synchronizing DML statements of a relational database to a NoSQL database.

The disclosed transaction control method is a method in which a synchronization proxy server synchronizes transaction DML data of an RDBMS to a NoSQL DBMS, wherein the synchronization proxy server adds meta information of the RDBMS, sync_iid and sync_uid columns for recovery history, and controls transactions. A preparatory step of creating a storage and a data structure for loading, creating a storage and data structure for loading into a NoSQL DBMS, and performing an initialization operation of a synchronization operation; A transaction control step of internally managing and processing a transaction of an RDBMS by changing the DML of INSERT and UPDATE in order for the synchronization proxy server to receive the packet from the network and analyze it, and to process a NoSQL data conversion failure; A NoSQL conversion step of processing a corresponding NoSQL conversion after the synchronization proxy server completes transmission of the transaction-committed data to the client; And a NoSQL loading step of loading the DML NoSQL data converted in the NoSQL conversion step into a NoSQL DBMS.

The preparation steps include adding Sync_iid and Sync_uid columns for meta information of the source RDBMS and recovery history, creating a storage and data structure for controlling the transaction of the source RDBMS, and a storage for loading into the replica NoSQL DBM. Creating a data structure.

In addition, in the transaction control step, the synchronization proxy server collects and analyzes the packet of the source RDBMS from the network, and if it is a new session, a session key is generated and stored in the session unit transaction management data storage (TR-SESSION-MAP). Steps, determining whether it is a data manipulation language (DML) if it is not a new session, and processing a partial rollback, commit, or rollback if it is not a data manipulation language (DML), and INSERT In the case of data manipulation language (DML), the Sync_iid column is added to the received packet, and the step of changing to an extended packet with Table.sync_iid added to the value (VALUE), and in the case of UPDATE data manipulation language (DML), the Sync_uid column is added to the received packet. The steps of adding and changing to an extended packet with Table.sync_uid added to the value (VALUE), and if the RDBMS transaction data storage (RDB-TR-DATA) is not allocated, the RDBMS transaction data storage (RDB-TR-DATA) Allocating an area and creating a reference value to access the allocated area of the RDBMS transaction data store (RDB-TR-DATA) in the session unit transaction management data store (TR-SESSION-MAP), and the RDBMS transaction data store (RDB- TR-DATA) storing the corresponding DML data and a Sync_iid or Sync_uid value according to the DML type together in an allocation area of the DML, and then transmitting the extended packet to the source RDBMS.

In the NoSQL conversion step, when a transaction data processing signal is received from the transaction controller, the transaction data is read one by one from the RDBMS transaction data storage (RDB-TR-DATA), and if the read transaction data is INSERT, the NoSQL INSERT statement converter Execute the INSERT NoSQL conversion procedure by calling and updating the Sync-iid value of the ROW data of the converted source RDBMS to the Table.commit_iid value.If the read transaction data is UPDATE, call the NoSQL UPDATE statement converter and UPDATE Perform the NoSQL conversion procedure, update the sync-uid value of the converted source RDBMS ROW data to the Table.commit_uid value, and if the read transaction data is DELETE, call the NoSQL DELETE statement converter and perform the DELETE NoSQL conversion procedure. Including the step of performing, and if the read transaction data is the end (End), it may further include the step of transmitting a loading signal to the NoSQL loader.

According to an embodiment of the present invention, when replicating transaction change data of an RDBMS to a NoSQL database, data in a fixed data format of the schema and columns of the RDBMS are converted to a NoSQL database with a free form, and the DML statements of the relational database are converted to a NoSQL database. There is an effect that can be synchronized with.

1 is a schematic diagram showing the overall configuration of a synchronization system for heterogeneous databases according to an embodiment of the present invention;
2 is a flow chart showing an entire procedure for synchronizing DML sentences of a relational database to a NoSQL database according to an embodiment of the present invention;
3A and 3B are flowcharts showing detailed procedures of the preparation step shown in FIG. 2;
4A and 4B are flow charts showing detailed procedures of the transaction control step shown in FIG. 2;
5 is a flow chart showing a detailed procedure of the NoSQL conversion step shown in FIG. 2;
6 is a flow chart showing the INSERT NoSQL conversion procedure shown in FIG. 5;
7 is a flow chart showing the UPDATE NoSQL conversion procedure shown in FIG. 5;
8 is a flow chart showing the DELETE NoSQL conversion procedure shown in FIG. 5;
9 is a flow chart showing a processing procedure when a NoSQL conversion fails according to an embodiment of the present invention;
10 is a flow chart showing a detailed procedure of the NoSQL loading step shown in FIG. 2;
11 is an example in which a source RDBMS is converted to a NoSQL document according to an embodiment of the present invention.

The present invention and the technical problem achieved by the implementation of the present invention will become more apparent by the preferred embodiments of the present invention described below. The following examples are merely illustrative for explaining the present invention, and are not intended to limit the scope of the present invention.

1 is a schematic diagram showing the overall configuration of a synchronization system for heterogeneous databases according to an embodiment of the present invention, and data of a relational database (RDBMS) 30 as a source database and data of a replication target NoSQL DBMS 40 Is to synchronize.

Referring to FIG. 1, the RDBMS DML generation client 10 is RDBMS type business PCs and servers, and when an RDBMS DML transaction occurs, it requests the synchronization proxy server 20 to reflect or cancel the transaction (S1). Here, DML (Data Manipulation Language) is a series of commands used to search, store, modify, and delete data in a database. In an embodiment of the present invention, INSERT, UPDATE, and DELETE are described as examples.

The synchronization proxy server 20 includes a preparation module 22, a transaction controller 24, a NoSQL converter 26, and a NoSQL loader 28, and analyzes the DML transaction packet generated by the client 10 when it is received. If it is INSERT or UPDATE data, Sync_id data is added and then transmitted to the source RDBMS (30) (S2). Here, Sync_id is an identifier for distinguishing DML transactions for data replication in an embodiment of the present invention, and is indicated as Sync_iid for INSERT and Sync_uid for UPDATE.

When the transaction completion result is received from the source RDBMS 30 (S3), the result is transmitted to the client 10 (S4), and the DML transaction data is converted into NoSQL data and stored in the NoSQL DBMS 40 (S5). Thus, the data of the source RDBMS 30 and the replication target NoSQL DBMS 40 are synchronized. Here, a proxy server is a computer or application program that allows a client to indirectly access other network services through itself, and functions to perform communication by proxy as a relay between the server and the client.

The source RDBMS 30 is a traditional relational database that provides ACID (atomic, coherent, isolated, persistent) transactions. Relational databases include Oracle, DB2, MSsql, and MySQL. Here, atomicity is the ability to ensure that transactions related to the transaction are partially executed and not interrupted, and consistency means that when a transaction successfully completes execution, it is always maintained in a consistent database state. , Isolation means that the operation of other transactions cannot be intervened when performing a transaction, and Durability means that successfully executed transactions must be reflected forever. Typically, all transactions remain in the log and can be returned to the state before system failure, and transactions can be considered a commit state only after everything is stored in the log.

The replication target NoSQL DBMS 40 is a replication DBMS that replicates the source RDBMS 30, and is a non-relational DBMS designed differently from the relational database management system (RDBMS) that is the source DBMS. NoSQL optimizes key values for simple search and additional work in a distributed environment without a schema like a table-column, and has excellent latency and throughput. And it has a feature of horizontal expandability that can be expanded on a large scale. For example, NoSQL Document Store is sometimes called a document-oriented database, and the table schema is not static but flexible, so each record can have a different schema. In general, records are stored using documents such as JSON, so unlike RDBS, it is easy to save or find a tree-type structure. Representative DBs of the NoSQL Document Store method include MongoDB, Amazone's DynamoDB, and CouchBase.

The process of synchronizing the source RDBMS 30 and the replication target NoSQL DBMS 40 according to the embodiment of the present invention basically operates in a proxy server mode. That is, the synchronization proxy server 20 copies the DML (INSERT, UPDATE) packet while relaying the network packet of the source RDBMS 30, modifies the packet, and transmits the extended packet to the source RDBMS 30. In addition, when the transaction of the source RDBMS 30 is completed, the synchronization proxy server 20 converts the stored DML transaction data to the document storage data format of the NoSQL DBMS 40 and stores it in the replication target NoSQL DBMS 40.

FIG. 2 is a flow chart showing an entire procedure for synchronizing DML sentences of a relational database to a NoSQL database according to an embodiment of the present invention.

Referring to FIG. 2, the preparation step S11 is a step of performing an initialization operation for a synchronization operation, and a sync_id (sync-iid or sync_uid) column in a DML packet for meta information of the source RDBMS 30 and a recovery history Add, create a storage and data structure for controlling transactions as shown in Table 1 below, and create a storage and data structure for loading into the NoSQL DBMS 40 to be replicated.

Storage identifier Storage function RDB-META-MAP RDBMS table meta information storage RDB-TR-DATA RDBMS transaction data store RDB-SYNC-MAP Storage of target table synchronization information of RDBMS TR-SESSION-MAP Session-level transaction management data storage NoSQL-TR-DATA NoSQL's replicated data store

The transaction control step (S12) is a step that internally manages and processes the transaction of the source RDBMS 30 after receiving and analyzing a packet from the network using a proxy server method.In order to handle NoSQL data conversion failures, such as INSERT, UPDATE, etc. The extension packet with the Sync_id column added to the DML packet is transmitted to the source RDBMS 30. In addition, a trigger that saves the Sync-iid column when deleting a record is created for recovery in case of a DELETE conversion failure. Here, a transaction is a set of operations for performing one logical function in the database, and becomes a unit of work. During a transaction operation, rollback is an operation that returns the database modifications completed to invalidate the transaction due to an error occurring during the transaction.Commit is the transaction processing is normally terminated and the changes made by the transaction are restored. This operation is reflected in the database.

The NoSQL conversion step (S13) is a step that processes the NoSQL conversion after the transaction's committed data is transferred to the client 10, and the transaction DML of the RDBMS is applied to the INSERT NoSQL Document Store, UPDATE NoSQL Document Store, It is converted to DELETE NoSQL Document Store storage method.

The NoSQL loading step (S14) is a step of loading the DML NoSQL data converted in the NoSQL conversion step (S13) into the replication target NoSQL DBMS (40).

3A and 3B are flowcharts illustrating detailed procedures of the preparation step S11 shown in FIG. 2. In the preparation step S11, an initialization operation for a synchronization operation is basically performed. Basically, the initialization work for synchronization between the source RDBMS 30 and the replication target NoSQL DBMS 40 is performed. Firstly, sync_iid and sync_uid columns are added for meta information of the source RDBMS (30) and recovery history, secondly, a repository and data structure to control transactions of the source RDBMS (30) are created, and thirdly, a NoSQL DBMS to be replicated Create a repository and data structure for loading into (40).

3A and 3B, the synchronization proxy server 20 fetches a list of database tables (items) and table information to be replicated from the replication target NoSQL DBMS 40 (S101).

Then, based on the replication target information obtained by the synchronization proxy server 20, the meta information of the RDBMS is obtained from the source RDBMS 30 and stored in the RDBMS meta information storage (RDB-META-MAP) (S102). In general, the meta information storage (RDB-META-MAP) is stored in the form of a hash memory for quick access.

In addition, for INSERT and UPDATE recovery, Sync_iid and Sync_uid columns are added for each replication target table of the source RDMBS 30, and the default value is set to 0. For DELETE recovery, a trigger for storing the Sync-iid column is created when the record is deleted (S103).

Next, the NoSQL converter 26 that converts RDBMS functions, operators, and conditional statements into NoSQL functions, operators, and conditional statements is loaded, and the NoSQL tables to be replicated are synchronized based on the RDBMS meta information (S104, S105).

Next, load the data conversion engine module according to the type of NoSQL DBMS to be replicated, such as the Mongo DB Document JSON conversion module or DynamoDB Document JSON conversion module, and store the RDBMS transaction data (RDB-TR-DATA) in memory and disk. It is created in (S106, S107).

Then, a storage (TR-SESSION-MAP) for managing transactions in session units is created, and a NoSQL replicated data storage (NoSQL-TR-DATA) is created to store the final NoSQL converted replication data (S108, S109). ).

And after creating the target table synchronization information storage (RDB-SYNC-MAP) of the RDBMS, the last synchronization information (sync_id) of the target table of the RDBMS is retrieved and stored in the synchronization information storage (RDB-SYNC-MAP). If not, a key value is created with'KEY = TABLE name + sync_id' (S110).

Subsequently, the transaction controller 24, the NoSQL converter 26, the NoSQL loader 28, and the like are created and started (S111).

4A and 4B are flowcharts illustrating detailed procedures of the transaction control step S12 shown in FIG. 2. The transaction control step (S12) is to internally manage and process the transaction of the source RDBMS 30 after the synchronization proxy server 20 receives the packet from the network and analyzes it.In order to handle NoSQL data conversion failure, INSERT, UPDATE DML The packet is changed and transmitted to the source RDBMS 30.

4A and 4B, the synchronization proxy server 20 collects packets of the RDBMS 30 from the network in a proxy mode, and analyzes the collected packets (S201, S202).

As a result of the analysis, it is determined whether it is a new session, and if it is a new session, a session key is generated and stored in the session-unit transaction management data storage (TR-SESSION-MAP), and then the packet collected in proxy server mode is transmitted to the source RDBMS 30 Do (S203 to S205).

If it is not a new session, it determines whether it is a data manipulation language (DML), and if it is not DML, it determines whether it is a partial rollback, and if it is a partial rollback, it is located in the corresponding location of the RDBMS transaction data store (RDB-TR-DATA). After processing the rollback marking, the packet collected in the proxy server mode is transmitted to the source RDBMS 30 (S206 to S208).

If it is not a partial rollback or a commit (COMMIT), if there is a partial rollback, if there is a partial rollback, the rollback data is deleted from the RDBMS transaction data store (RDB-TR-DATA), and then the session is sent to the NoSQL converter (26). Transmit processing signal including key and RDB-TR-DATA reference value, delete RDB-TR-DATA reference value from session unit transaction management data store (TR-SESSION-MAP), and source the collected packet in proxy server mode It is transmitted to the RDBMS 30 (S209 to S212).

Determining whether it is a commit (COMMIT) and determining whether it is not a commit (COMMIT) or a rollback (Roll Back), and if a rollback (Roll Back), deletes all data in the RDBMS transaction data storage location (RDB-TR-DATA) of the session And, after deleting the RDB-TR-DATA reference value from the session unit transaction management data storage (TR-SESSION-MAP), the packet collected in the proxy server mode is transmitted to the source RDBMS 30 (S213 to S215).

On the other hand, if it is DML in step S206 of determining whether it is a data manipulation language (DML), as shown in FIG. 4B, it is determined whether it is INSERT, and if it is INSERT, a Sync_iid column is added to the received packet, and Table.sync_iid is added to the value Is changed to the added expansion packet (S216, S217).

It determines whether it is UPDATE or INSERT, and if it is UPDATE, the Sync_uid column is added to the received packet, and the value is changed to an extended packet with Table.sync_uid added to the value (S218, S219).

After it is not an UPDATE or the received packet is changed to an extended packet, the value of Table.sync-iid or Table.sync_uid according to DML is increased by 1 (S220).

Next, it is determined whether the RDBMS transaction data storage (RDB-TR-DATA) is allocated, and if RDB-TR-DATA is not allocated, the storage of the RDB-TR-DATA area is allocated, and the session-unit transaction management data storage (TR- SESSION-MAP) creates a reference value (index) to access the allocated area of the RDBMS transaction data storage (RDB-TR-DATA) (S221, S222).

In addition, after storing the corresponding DML data and the Sync_iid or Sync_uid value according to the DML type in the allocated data area of the RDBMS transaction data storage (RDB-TR-DATA) together, the changed extended packet is transmitted to the source RDBMS 30 (S223).

5 is a flow chart showing a detailed procedure of the NoSQL conversion step shown in FIG. 2, FIG. 6 is a flow chart showing the INSERT NoSQL conversion process shown in FIG. 5, and FIG. 7 is a UPDATE NoSQL conversion process shown in FIG. FIG. 8 is a flow chart showing a DELETE NoSQL conversion procedure shown in FIG. 5, and FIG. 9 is a flow chart showing a conversion failure processing procedure shown in FIG. 5. The NoSQL conversion step (S13) is performed by the NoSQL converter 26 after data for which the transaction data processing is committed in the source RDBMS 30 is transferred to the client. The conversion process is to convert INSERT, UPDATE, DELETE RDBMS data into INSERT, UPDATE, DELETE NoSQL Document store format.

5, the NoSQL converter 26 waits for a conversion processing signal from the transaction controller 24 and, when a transaction data processing signal is received, reads the corresponding transaction data one by one from the RDBMS transaction data storage (RDB-TR-DATA). Comes (S301, S302).

If the read transaction data is INSERT, the NoSQL INSERT statement converter is called, the INSERT NoSQL conversion procedure is performed as shown in FIG. 6, and the Sync-iid value of the ROW data of the converted RDBMS is updated to the Table.commit_iid value (S305 ~S307).

Referring to FIG. 6, when Sync_iid is less than commit_iid, the NoSQL INSERT statement converter returns since data has already been processed, and when Sync_iid is greater than commit_iid, SQL parses and analyzes to generate a SQL statement tree (S401, S402). Then, table information is extracted, and if it is a View table, the actual table name is used (S403). Meta information of the table is retrieved from the source RDBMS meta information storage (RDB-META-MAP) (S404).

Subsequently, from parsing analysis and meta information, it checks whether the SQL statement (function, procedure, view) can be converted into a NoSQL document, and if it can be converted, meta information is extracted from the INSERT query (S405, S406).

Then, data is extracted from the INSERT query or bind format, and based on the extracted meta information and the extracted data, the document data in the form of storing the NoSQL DBMS to be copied is created (S407, S408). For example, if the NoSQL DBMS 40 to be replicated is Mongo DB, the extracted meta information and the extracted data are created as Mongo DB Documnet data, and if the NoSQL DBMS 40 to be replicated is Dynamo DB, the extracted meta information and the extracted data are Dynamo DB Creates with Documnet data.

Then, the generated NoSQL Document data is stored as a session key value in a NoSQL replicated data storage (NoSQL-TR-DATA) (S409).

On the other hand, if the SQL statement (function, procedure, view) cannot be converted to a NoSQL document, the conversion failure handler is called to pass parameters such as table, insert, and Sync-iid, and the conversion failure handler is shown in FIG. As described above, the conversion failure processing procedure is performed (S410).

Referring back to FIG. 5, if the read transaction data is UPDATE, a NoSQL UPDATE sentence converter is called, the UPDATE NoSQL conversion procedure is performed as shown in FIG. 7, and the Sync-uid value of the ROW data of the converted RDBMS is table It is updated to the value of .commit_uid (S308 to S310).

Referring to FIG. 7, when Sync_uid is smaller than commit_uid, the NoSQL UPDATE statement converter returns data that has already been processed, and when Sync_uid is greater than commit_uid, SQL parses and analyzes to generate SQL syntax trees (S501, S502). Then, table information is extracted, and if it is a view table, the actual table name is used (S503). Meta information of the table is retrieved from the RDBMS meta information storage (RDB-META-MAP) (S504).

Then, from parsing analysis and meta information, it checks whether the SQL statement (function, procedure, view) can be converted into a NoSQL document, and if it can be converted, meta information is extracted from the SET clause and the WHERE clause (S505, S506).

Then, data is extracted from the UPDATE query or bind format, and based on the extracted meta-information and the extracted data, the document data of the NoSQL DBMS storage format to be replicated is created (S507, S508). For example, if the NoSQL DBMS 40 to be replicated is Mongo DB, the extracted meta information and the extracted data are created as Mongo DB Documnet data, and if the NoSQL DBMS 40 to be replicated is Dynamo DB, the extracted meta information and the extracted data are Dynamo DB Creates with Documnet data.

Then, the created NoSQL Document data is stored in the NoSQL replicated data store (NoSQL-TR-DATA) as the session key value (S509).

On the other hand, if the SQL statement (function, procedure, view) cannot be converted to a NoSQL document, the conversion failure handler is called to pass parameters such as table, update, and Sync-uid, and the conversion failure handler is shown in FIG. As described above, the conversion failure processing procedure is performed (S510).

Referring back to FIG. 5, if the read transaction data is DELETE, a NoSQL DELETE sentence converter is called and a DELETE NoSQL conversion procedure is performed as shown in FIG. 8 (S311, S312). And, if the read transaction data is the last (End), a load signal is sent to the NoSQL loader 28 (S303, S304).

Referring to FIG. 8, the NoSQL DELETE sentence converter parses and analyzes SQL to generate an SQL syntax tree (S601). At this time, if Sync_iid is less than commit_iid, it is already processed data, so it is desirable to return it, and to execute it only when Sync_iid is greater than commit_iid. That is, the DELETE statement generates a trigger that stores the Sync-iid column when deleting a record, so Sync_iid can be used.

Then, table information is extracted, and if it is a View table, the actual table name is used (S602). Meta information of the table is retrieved from the source RDBMS meta information storage (RDB-META-MAP) (S603).

Then, using the parsing analysis result and meta information of the table, it checks whether the SQL statement (function, procedure, view) can be converted into a NoSQL document, and if it can be converted, the meta information is extracted from the WHERE clause. If there is no WHERE clause, the entire data is deleted (S604~S606).

Then, based on the extracted meta information, the document data in the form of storing the NoSQL DBMS to be replicated is created (S607). For example, if the replication target NoSQL DBMS 40 is Mongo DB, the extracted meta information is created as Mongo DB Documnet data, and if the replication target NoSQL DBMS 40 is Dynamo DB, the extracted meta information is created as Dynamo DB Documnet data.

Then, the generated NoSQL Document data is stored in the NoSQL replicated data storage (NoSQL-TR-DATA) as the session key value (S608).

On the other hand, if the SQL statement (function, procedure, view) cannot be converted to a NoSQL document, the conversion failure handler is called and parameters such as table and delete are transmitted, and the conversion failure handler is converted as shown in FIG. The failure processing procedure is performed (S609).

Referring to FIG. 9, when an INSERT, UPDATE, and DELETE conversion fails, the conversion failure handler fetches and synchronizes the corresponding recovery data from the source RDBMS 30.

The conversion failure handler receives parameters such as a NoSQL-TR-DATA session key, table name, DML type, and sync_id (sync_iid/uid) from the conversion failure DML procedure (S701).

If the received factor is DML INSERT, after calculating the recovery Sync_iid value (recovery range), all data whose Sync_iid of the corresponding table of the source RDBMS corresponding to the recovery range is less than the recovery Sync_iid are retrieved (S702 to S704).

Then, based on the meta information of the table and the data obtained from the source RDBMS (30), INSERT-type NoSQL Document data is created, and the NoSQL Document data created as a session key value is stored in the NoSQL replication data store (NoSQL-TR-DATA). (S705).

If the received factor is DML UPDATE, the recovery Sync_uid range value is calculated, and all data whose Sync_uid is smaller than the recovery Sync_uid from the corresponding table of the source DBMS 30 are fetched (S706 to S708).

Then, based on the meta-information of the table and the data obtained from the source RDBMS (30), UPDATE-type NoSQL Document data is generated (S709). At this time, it is preferable to use a primary key (PK) as an update condition.

Then, the NoSQL document data generated as the session key value is stored in the NoSQL replicated data storage (NoSQL-TR-DATA) (S713).

If the received argument is DML DELETE, a list of information (Sync_iid) deleted from the trigger table of the corresponding table of the source RDBMS 30 is retrieved (S710, S711).

Next, DELETE-type NoSQL Document data is generated based on the meta information of the table and the data obtained from the source RDBMS 30 (S712). At this time, the deletion condition uses Sync_iid of the trigger table.

Then, the NoSQL document data generated as the session key value is stored in the NoSQL replicated data storage (NoSQL-TR-DATA) (S713).

10 is a flow chart showing a detailed procedure of the NoSQL loading step shown in FIG. 2.

Referring to FIG. 10, when the NOSQL load signal is received, the NoSQL loader 28 connects to the replication target NoSQL DBMS 40 (S801, S802).

Document data corresponding to a combination of a session key and a transaction key are sequentially read one by one from the NoSQL replicated data store (NoSQL-TR-DATA) (S803).

If there is data read, the read data is loaded into the NoSQL DBMS(40), and if there is no more data to be read, the document data stored in the NoSQL replication data store (NoSQL-TR-DATA) is deleted. (S804 to S806).

11 is an example in which a source RDBMS is converted to a NoSQL document according to an embodiment of the present invention. Referring to FIG. 11, it can be seen that the INSERT and UPDATE statements of the RDBMS are converted into NoSQL Document format through transaction control.

In the above, the present invention has been described with reference to one embodiment shown in the drawings, but those of ordinary skill in the art will understand that various modifications and other equivalent embodiments are possible therefrom.

10: RDBMS DML generation client 20: Synchronization proxy server
22: preparation module 24: transaction controller
26: NoSQL converter 28: NoSQL loader
30: source RDBMS 40: replication target NoSQL DBMS

Claims (5)

Synchronization proxy server adds Sync_iid and Sync_uid columns for meta information of RDBMS and recovery history, creates storage and data structure to control transactions, and creates storage and data structure for loading into NoSQL DBMS to perform synchronization operation. A transaction in which the RDBMS transaction is internally managed and processed by changing the DML of INSERT and UPDATE to handle NoSQL data conversion failure after the preparation step of performing the initialization operation and the synchronization proxy server receives and analyzes the packet from the network The control step, the NoSQL conversion step of processing the NoSQL conversion after the synchronization proxy server completes the transmission of the transaction's committed data to the client, and the DML NoSQL data converted in the NoSQL conversion step to the replication NoSQL DBMS. In the transaction control method for synchronizing DML statements of a relational database including the loading step of loading NoSQL to a NoSQL database,
The preparation step
The steps of adding Sync_iid and Sync_uid columns for meta information of the source RDBMS and recovery history, creating a storage and data structure to control transactions of the RDBMS, and creating a storage and data structure for loading into a NoSQL DBMS Including,
The transaction control step
The synchronization proxy server collects and analyzes packets of the RDBMS from the network; if it is a new session, generates a session key and stores it in a session-level transaction management data store (TR-SESSION-MAP); and if it is not a new session, Determining whether it is a data manipulation language (DML) and processing a partial rollback, commit, or rollback if it is not a data manipulation language (DML), and receiving an INSERT data manipulation language (DML) Add a Sync_iid column to the packet and change it to an extended packet with Table.sync_iid added to the value (VALUE).In the case of UPDATE data manipulation language (DML), add a Sync_uid column to the received packet, and add the value (VALUE). Steps of changing Table.sync_uid to the added extended packet, and if the RDBMS transaction data storage (RDB-TR-DATA) is not allocated, allocates an area of the RDBMS transaction data storage (RDB-TR-DATA), and performs session-based transactions. Creating a reference value to access the allocated area of the RDBMS transaction data store (RDB-TR-DATA) in the management data store (TR-SESSION-MAP) and the allocation area of the RDBMS transaction data store (RDB-TR-DATA). It includes the step of storing the corresponding DML data and the Sync_iid or Sync_uid value according to the DML type together, and then transmitting the extended packet to the source RDBMS,
The NoSQL conversion step is
When a transaction data processing signal is received from the transaction controller, the transaction data is read one by one from the RDBMS transaction data storage (RDB-TR-DATA). If the read transaction data is INSERT, a NoSQL INSERT statement converter is called and INSERT NoSQL Execute the conversion procedure, update the Sync-iid value of the converted source RDBMS ROW data to the Table.commit_iid value, and if the read transaction data is UPDATE, call the NoSQL UPDATE statement converter and perform the UPDATE NoSQL conversion procedure. And updating the Sync-uid value of the converted source RDBMS's ROW data to the Table.commit_uid value, and if the read transaction data is DELETE, calling a NoSQL DELETE statement converter and performing a DELETE NoSQL conversion procedure. A transaction control method for synchronizing DML statements of a relational database to a NoSQL database, characterized in that. delete delete delete The method of claim 1, wherein the NoSQL conversion step
A transaction control method for synchronizing DML statements from a relational database to a NoSQL database, further comprising transmitting a load signal to the NoSQL loader when the read transaction data is the end.

Images