KR20100011000A - Method and apparatus for data version management of grid database - Google Patents

Abstract

PURPOSE: A method and an apparatus for data version management of grid database are provided to keep the consistency in grid database permitting copied data in a plurality of nodes. CONSTITUTION: A data update operation is created from a node. The new version information request of data is received(S100). The processing of the new version information request as described above is determined. If the processing of the new version information request as described above is possible, the new version information production and Version information update operate(S110). The new version information as described above is transmitted to the node(S120). The node receiving the new version information of data from the version control apparatus writes out the version update message of date based on the received new version information as described above(S130).

Description

Method and apparatus for managing data version of grid database {Method and apparatus for data version management of grid database}

The present invention relates to a grid database, and more particularly, to a method and apparatus for data version management of a grid database.

As the Internet becomes more common and the performance of computers and networks improves, computers are being used in various fields. Examples of this are studies of large amounts of genetic information processing, aircraft or projectile design, climate and environmental changes, and data analysis in high-energy physics. In an effort to efficiently utilize such a huge amount of data, distributed databases and database clusters have been developed. In recent years, in the resource consolidation, a grid database (for integration of large data with not only the same type database but also with the same type database) has been developed. A study on grid databases is underway.

First, a distributed database is an integrated database that logically associates several local databases using computer networks. In a physically distributed and logically concentrated configuration, each database is connected to each other rather than a simple connection. The advantage of a distributed database is that the data is distributed and prepared for failure, and large numbers of users can share large databases at low cost. Distributed databases can be configured at a lower cost than centralized databases, and have advantages in scalability and availability.

As shown in FIG. 1, the grid database is composed of a plurality of distributed nodes 10, 20, 30, and 40 and a link interconnecting the nodes 10, 20, 30, and 40. The fields 10, 20, 30, and 40 are connected to the plurality of terminals 12, 22, 32, and 42. Among the plurality of nodes, a node in which a user's access and data update is most generated is defined as a root node 10. Here, a node refers to a database management system composed of a database management system or a cluster system, and a grid is a variety of objects that can react dynamically and in real time to all kinds of resources in response to changing requirements over time. It means to manage and utilize efficiently through cooperation.

Grid database is a database management system for efficient processing and use of distributed data in grid computing environment. The grid database basically includes the functions of the distributed database system described above, and provides functions such as integration, automation, and virtualization. The main functions of the grid database are management of large resources, high speed operations, and improved availability through data replication. Each node in the grid database replicates and stores the same data in different locations to improve data processing performance and availability, and provides data federation, data transformation, data placement, and data integration.

However, unlike the existing distributed database system, the grid database guarantees local autonomy, so that it is impossible to apply a single manager or inefficient system configuration. In addition, an efficient reorganization operation is required for a fluid response to an environment in which data is dynamically changed.

In the grid database, the same data is duplicated and managed in another node as described above in order to improve availability, scalability, and performance of data processing. However, although the availability of the system has been increased due to the use of data replicas, there are problems in version control (consistency) of data due to changes in the replica data made in real time on a plurality of nodes.

As a method of improving the problem of the conventional version management method, there is a data version management method using a demand-based tree. In the grid environment, the frequency of use of each copy is different according to the type of application service and the data, and the version of the data is managed using the demand tree.

However, the data version management method using the demand-based tree of the prior art is concentrated only on the propagation of the update data according to the frequency of the user's demand, and thus there is a disadvantage in that it is impossible to maintain the consistency of the update operations that occur simultaneously. In this case, the simultaneous update operation refers to a case where another update occurs in another node and an update operation of data occurs in a plurality of nodes in a situation where an update is generated for the replica in a fluidly changed grid environment.

When multiple update nodes occur simultaneously, there is a problem that the version of the data updated at each node is not managed efficiently in the entire grid database. Due to the time-consuming problem, there is a demand for data version management method of a new grid database suitable for such an environment.

Disclosure of Invention The present invention has been made in view of the above-described problems, and it is an object of the present invention to provide a data version management method and apparatus capable of maintaining the consistency of data managed in a grid database using a demand-based tree.

Disclosure of Invention The present invention has been made in view of the above-described problems, and it is an object of the present invention to provide a data version management method and apparatus capable of shortening update calculation time and data version management time of data in a grid database.

Data version management method according to an embodiment of the present invention for achieving the above object in the data version management method of a grid database including a plurality of nodes, a data update operation is generated from the node to the new version information of the data Receiving a request; Determining whether to process the new version information request; If it is determined that the processing is possible, generating new version information and updating the version information; And transmitting the new version information to the node.

According to an embodiment of the present invention, a data version management method includes: storing a new version information request from the node in a queue if processing is not possible as a result of determining whether to process a new version information request; And notifying the node that the update is to be stopped.

In the data version management method according to an embodiment of the present invention, whether to process the new version information request is determined by including first version information of the data from the node, previous version information and current version information stored in a version control device. And comparing the second version information, and if the first version information and the second version information are the same as the result of the comparison between the first version information and the second version information, perform the processing of the new version information request. And when the first version information and the second version information are different, suspend processing of the new version information request so that data is not updated in a plurality of nodes of the grid database.

In the data version control method according to an embodiment of the present invention, when a delay occurs in a first node of a plurality of nodes of the grid database, a node other than the first node until the delay of the first node is released. It is characterized by suspending the updating of data.

Data version management apparatus according to an embodiment of the present invention for achieving the above object in the data version management apparatus for managing the data version of the grid database including a plurality of nodes, the data is updated from the plurality of nodes A version information management unit for generating and managing version information of the; A work queue manager for creating and managing a work queue used when a new update calculation process is to be stopped due to a workload of some nodes in a process of updating a plurality of nodes simultaneously; Receiving information about data updates made by multiple nodes at the same time and storing them in a work queue, and priorities for controlling the priorities of each node so that the data updates made by the plurality of nodes can be sequentially performed. Management; An excess capacity queue manager configured to store and manage information of nodes whose update operations are delayed among the plurality of nodes in an excess capacity queue; And a priority update queue manager configured to store and manage update operation request messages received from the plurality of nodes in a priority update queue after an update delay occurs in at least one of the plurality of nodes. .

Data version control method and apparatus according to an embodiment of the present invention can provide a version control method and apparatus for maintaining consistency in a grid database that allows replica data in a plurality of nodes.

Data version management method and apparatus according to an embodiment of the present invention can improve the performance of the grid database by reducing the time required to perform data and data version information update in the grid database.

Data version management method and apparatus according to an embodiment of the present invention stores the location information of the node where the update operation occurs, if the future workload is relaxed in the future by processing the update operation again through the information stored in the queue multiple times This ensures the consistency of the data being updated.

Data version management method and apparatus according to an embodiment of the present invention can achieve the performance of the grid database by maintaining the consistency of the data and data version information in the grid database.

The data version management method according to an embodiment of the present invention can prevent a deadlock phenomenon that may occur when performing an update in a lower node by controlling an update operation request of each node.

Hereinafter, exemplary embodiments of the present invention will be described with reference to the accompanying drawings.

The present invention according to the embodiment proposes a version control method and version control apparatus for data using a hierarchical structure in a grid database. The data version control method according to an embodiment of the present invention may provide a data version control method for maintaining consistency of data in a grid database using a demand-based tree.

The data version management method according to an embodiment of the present invention can extend the existing demand-based tree, and maintain data consistency by managing versions of data replicas in the grid database through the data version management method and apparatus.

The data version control method and version control apparatus according to an embodiment of the present invention performs an organization of the hierarchical structure of the grid database, and organizers to logically collect information of the grid databases when reorganizing the hierarchical structure. Play a role.

Data version management method and version control apparatus according to an embodiment of the present invention can support the step-by-step information propagation and reorganization operation by configuring the entire grid database in a hierarchical structure. This enables support and efficient balancing of local reorganization operations. In addition, unnecessary reorganization operations can be eliminated, and the data processing capability of the grid database can be improved.

2 is a diagram illustrating a grid database including a version control apparatus according to an embodiment of the present invention. First, the number of terminals 112 connected to each of the nodes 110, 120, 130, and 140 may be arbitrarily set. For example, the case where the user demand for the data A1 established in the node N1 110 is most demanded is one example. Node N1 was defined as the root node 110.

Referring to FIG. 2, the grid database includes a plurality of distributed nodes 110, 120, 130, and 140, and links and nodes 110, 120, which interconnect the nodes 110, 120, 130, and 140. It includes a version control device 100 for managing the version of the data to be updated in 130, 140. Each of the nodes 110, 120, 130, and 140 is connected to the plurality of terminals 112, and defines a node having the highest user access and data update among the plurality of nodes as the root node 110. do.

Here, a node refers to a database management system composed of a database management system or a cluster system, and a grid is a variety of objects that can react dynamically and in real time to all kinds of resources in response to changing requirements over time. It means to manage and utilize efficiently through cooperation.

The nodes 110, 120, 130, and 140 all store replicas A1 to A9 of the same data, and have version information of the data replicas they store. Here, the copy of the data is propagated from the node where the data is updated through the demand-based tree structure to all the nodes of the grid database via the root node 110, and the version of the copy of the data that has been updated and updated. The information is generated and controlled by the version control device 100.

Grid database including a version control device 100 according to an embodiment of the present invention is based on the demand-based tree, the current copy is stored in nodes that are geographically separated from each other, the demand for the replica of each node It is connected in a hierarchical structure in order. Here, the version control device 100 includes previous version information and current version information of the data to be updated in the grid database.

In the demand-based tree, each group is composed of one node and a plurality of terminals connected to the node, and these groups are connected to form a network structure of a tree. Here, demand is defined as the frequency of read operations per unit time for specific data in a single node, and each node records the demand for all data stored, and this information is updated periodically.

When data update occurs in any group, it is sent as a data update message within the group to the node of the group, and the node of the group where the data update has occurred is a data update message indicating that the data has been updated in its group. Is transmitted to other adjacent nodes using the above-described tree structure.

Here, the group node where the update of data has occurred, the root node 110 of the grid database, shown in Figure 2, in order to transmit information about the data update occurred in its group to all nodes of the grid database Transmits a data update message, and the root node 110 receiving the data update message propagates that the data update is generated from a specific node to all nodes of the grid database through the tree structure described above.

The version control apparatus 100 of the grid database according to an embodiment of the present invention generates a structure and a work queue for the version information of the data, and uses the structure and the work queue for the generated version information to update the data before updating. It records and manages previous version information and next version information of updated data.

To this end, the version control device 100, as shown in Figure 3, version information management unit 210, work queue management unit 220, processor 230, priority queue management unit 240, excess capacity queue management unit ( 250 and the priority update queue manager 260.

The version information management unit 210 generates and manages version information of data stored in the nodes 110, 120, 130, and 140, and version information of data updated from the nodes 110, 120, 130, and 140. do.

Hereinafter, on the basis of the update performed in the description, the version information for the data before the update is defined as the previous version information, and the version information for the data after the update is defined as the current version information or the next version information. .

The version information of the data managed by the version information management unit 210 is largely divided into two types: previous version information and next version (current version) information. The reason for storing the version information in these two types is that the update information must be executed in sequence while the update information is input irregularly in the various nodes. Through previous version information and current version information, it is possible to ensure that data updates are processed sequentially and consistently.

The previous version information and the current version information are used to maintain data consistency within the entire grid database upon data update of other nodes after the update of data performed at each node. Version information of the data provided from the version information management unit 210 of the version control device 100 can determine whether the copy of the data held by the current version of the data copy or the previous version of the data copy. .

The work queue manager 220 creates and manages a work queue used when a new update operation needs to be stopped due to a workload of some nodes in the process of concurrent update operations occurring in the grid database. do.

Here, the work queue stores the location information of the node where the update operation is newly generated during the period in which the update is stopped, and when the workload is relaxed in the future, the work queue re-processes the update operation based on the information accumulated in the queue. Ensure consistency for data replicas.

All nodes 110, 120, 130, and 140 of the grid database illustrated in FIG. 2 store replicas A1 to A9 for the same data, and according to the update order of the replicated data, 114).

Looking at the version information 114 of the data stored in the version control device 100, the current version information of the data is "4", the previous version information is "3". It can be seen that all nodes of the current grid database have the same version information 114 corresponding to version “4” for the same data. Here, the version control device 100 generates and manages previous and next version or current version information of the data, as shown in FIG. 4.

The priority management unit 230 loads information on data updates made by multiple nodes at the same time from the nodes, stores them in a work queue, and sequentially updates the data made by the nodes. Manage priority queues.

Here, if the priority queue is formed as shown in Fig. 5, it is a queue that the node has, and is a queue that stores update information occurring simultaneously. The node compares the version information of the data stored in the work queue of the version control device 100 with the version information of the data stored in the node, and if the version information of the data stored in the node is the previous version information, the version management device In addition to sequentially loading the version information of the data from the 100, the data corresponding to the current version information is sequentially loaded from the root node 110 to perform an update operation of the data. At this time, the information stored in the queue stores the update information and the version information of the actual data.

The node sequentially performs data update according to the version order of the data stored in the priority queue. Here, the means of sequentially updating the data means that the current version information of the data is "4" and the version "3" and version "4" when the version information of the data stored in the specific node is "2". This means that data is sequentially loaded and data is updated.

If there is no next version data of the currently executing version, the node waits for an update operation until the next version data is received. In addition, the node transmits an update information delay message to the version control device 100 because no more update information can be received when data more than the limit value of the queue is accumulated.

When the excess capacity queue manager 240 receives the update delay message from the node, the excess capacity queue manager 240 stores and manages information of the node whose update operation is delayed in the excess capacity queue as shown in FIG. 6. The excess capacity queue shown in FIG. 6 is one of queues managed by the version control apparatus 100. When an update delay occurs in a node, the excess capacity queue stores queue delay information of each node. The excess capacity queue manager 240 controls the respective nodes so that the update operation of the data does not occur from the respective nodes after the delay occurs using the delay information stored in the excess capacity queue. This allows you to maintain a consistent version of the data within the entire grid database.

 In addition, when the information of the delayed node is inserted into the excess capacity queue, the update queue management unit 250 operates first, and as shown in FIG. 7, the delay information from each node has priority update queue as shown in FIG. 7. Are stored in.

Subsequently, the priority update queue manager 250 stores and manages all update operation request messages received from the nodes after the delay occurs in updating the data in the grid database in the priority update queue, as shown in FIG. 7. do. Here, the update queue first stores all update operation request messages after a delay occurs in updating data.

First, by sequentially storing update operation request messages in the update queue, when the delays of all nodes in the excess capacity queue are released, the update operations that occur simultaneously after the occurrence of the delay are guaranteed by ensuring the sequentiality of subsequent update operations. Can ensure consistency.

In the above description, the version control apparatus 100 is described as being formed as a separate component in a grid database. However, this is only an example, and the version control apparatus 100 is updated in nodes. It can be formed included in any node (eg, root node) for version control of the. In this case, the root node 110 is responsible for generation, management and transmission of version information of the data.

In the following description, a data version management method of a grid database according to an embodiment of the present invention will be described using an example in which a data update operation occurs at node A ₀ . The overall flow of the data version management method according to an embodiment of the present invention will be described with reference to FIG. 8, and the message transmission / reception process and data version between the version control device 100 and nodes are described with reference to FIGS. 9 to 11. The update process of the information will be described.

8 is a flowchart illustrating a data version management method according to an embodiment of the present invention. Referring first to Figure 8, when the updating operation of the data generated in the node A ₀ requests the new version information of the node A ₀ is a data update made to a version management apparatus (100) (S100). Here, when the version control device 100 is formed at any node of the grid database, the version control device 100 requests new version information of the updated data to the node having the version control device 100.

Thereafter, the version control apparatus 100 updates the version information of the currently stored data to generate new version information of the data (S110), and transmits the generated new version information to the node A ₀ requesting the new version information of the data. (S120).

Thereafter, the node A _{0, which} has received the new version information of the data from the version control apparatus 100, creates a version update message of the data based on the received new version information (S130).

Thereafter, the node A ₀ transmits the generated version update message to the root node 110 to transmit the updated data and the update information of the data to other nodes according to the propagation order in the tree structure (S140).

Thereafter, the root node 110 receiving the version update message from the node A ₀ where the data is updated compares the data version information of the received update message with the version information of the data stored therein. Here, the version information includes the current version information that has been updated with the previous version.

For example, if the version information of the received update message is changed from the previous version 3 to the current version 4, and the current version of the data owned by the root node 100 is 3, the version of the data it has is Since it is updated, the update operation is performed to update the data and the version information of the data stored therein (S150). Thereafter, the root node 100 transmits a version update message to another node (for example, node An-1) configured under its root (S160).

If the current version of data owned by the root node 110 is different from the previous version information of the data received from the node A ₀ , the update operation is temporarily suspended. For example, when the version information of the received update message is changed from the previous version 4 to the current version 5, and the current version of the data owned by the root node 100 is 3, the version of the data that the user has is In this case, the update operation is stored in the operation priority queue and the update operation of the version information is executed until the version of the replica data stored by the node A ₀ is replaced with the latest version. Withhold

The node An-1 receiving the version update message from the root node 110 performs an update operation through the same method as the node A ₀ and the root node 110 to update the data and version information of the data stored therein. (S170). Thereafter, the node An-1 transmits a version update message to another node (for example, node An) configured below it (S180).

If the node An-1 also differs from the version information of the data stored in the node and the version information of the data received from the root node 110, the update operation is performed until the version of the data stored in the node An-1 is changed to the latest version. Store in the priority queue to suspend the update operation of the version information.

The node An receives the version update message from the node An-1 and performs an update operation to update the data stored in the node An-1 and the version information of the data (S190).

Subsequently, after receiving the version update of the data as described above in S150 to S190, the data and the version information of the data stored therein are updated, and a version update message is transmitted to other nodes configured under the own. As a result, all nodes in the grid database store the same version of data. This ensures consistency of data in the grid database.

9 is a flowchart illustrating a process of transmitting and receiving an update message between a version control device and a node in a data version management method according to an embodiment of the present invention.

Referring to Figure 9, when the updating operation of data performed on the node A ₀ (S200), the node A ₀ is sent to create a version information update message (S210), the generated version information update message to the version management apparatus (100) (S220).

Thereafter, the version control apparatus 100 compares the currently stored version information (previous version information and current version information) with the version information received from the node A ₀ and checks whether data update and data version information are possible. (S230).

As a result of checking in S230, when an update is possible, new version information is generated and the generated new version information is transmitted to the node A ₀ (S2340).

Thereafter, the node A ₀ updates the data and the version information of the data with the new version information received from the version control apparatus 100 (S250). Thereafter, the new version information is transmitted to the root node 110 to transmit the new version information to all nodes of the grid database through the demand-based tree structure.

Returning to S230 again, if the update is not possible, the version information update request is suspended according to the received version information update message, and the received version information is stored in the excess capacity queue (S260).

In this case, when the update is not possible, the update request for the version information is sequentially performed when there is a request for the update of the version information from another node before the update request for the version information from the node A ₀ .

Since, the update operation by transmitting a stop message to the node A ₀ A ₀ a node ceases to perform updates of data version information (S270).

When the node notified of stopping the update operation of the version information from the version control device 100 did not obtain new version information according to the update of the data performed by the version control device 100, when the version control device 100 obtains the new version information. Until this, other nodes in the grid database are suspended from communicating information about their data updates.

When the data is updated from various nodes in the grid database through the processes of S200 to S270 described above, and the version information is requested to be updated, the version information can be sequentially updated to allow data to be updated in the grid database. And data version information can be kept consistent.

10 is a flowchart illustrating a process after receiving a message in a version control apparatus in a data version management method according to an embodiment of the present invention.

Referring to FIG. 10, when a message is received from nodes of a grid database (S300), a type of a received message is checked. First, it is checked whether a received message is a version information update message (UP DATA MSG) (S310). ).

If the received message is a version information update message as a result of checking in S310, the version information included in the version information update message received from the node is compared with the version information managed by the user, and the current version information can be updated when the version information is possible. The version information is updated with the new version information (S320). Here, when the update of the version information is not possible, the procedures of S260 and S270 of FIG. 9 are performed.

Here, the version information update message (UP DATA MSG) is a message indicating a general update of data generated in the node. The update operation checks the Waiting Flag and changes the version message to the next version when the Waiting Flag is FALSE. Then, the VMSUC MSG message is transmitted to the node. If the Waiting Flag is TRUE, data is stored in the priority queue through the Stored Waiting Q function. In addition, Exchange Version increases the currently stored version information and changes the new version information.

Returning to S310, if it is confirmed that the received message is not a version information update message, it is checked whether the received message is a delay message (PENDING MSG) (S330).

As a result of checking in S330, if the received message is a delay message, information on the node where the delay has occurred is stored in the excess capacity queue (S340). Thereafter, the update operation is blocked so that the update operation of the data and the data version information is not generated in the node where the delay has occurred (S350). Thereafter, the update message generated after the update operation is blocked is stored in the excess capacity queue (S360), and the update operation is suspended until the delay caused by the node is released.

Here, the Pending message (PENDING MSG) is a message containing the information of the node where the delay occurs, the version control device 100 stores the information of the node where the delay occurs, and calls the Wait Running Flag function for further update operation Control the node so that it does not occur.

Returning to S330, if it is determined that the received message is not a delay message (PENDING MSG), it is checked whether the received message is an IMPENDING MSG (S370).

As a result of checking in S370, if the received message is a delay release message, the delay state of the node is released to perform an update operation waiting in the excess capacity queue with respect to the node that has sent the message (S380). Then, it is checked whether information of another node exists in the current priority queue (S390).

As a result of checking in S390, if information of another node does not exist in the current priority queue, data of the priority update queue stored so far is transmitted to each node (S400). Through this, new version information from the node where the data is updated is transmitted to other nodes of the grid database. On the other hand, as a result of the check in 390, if information of another node exists in the current priority queue, a delay is generated in another node, or since there is information requested first, and the process waits until the processing thereof is completed (S395). ).

11 is a flowchart illustrating a processing process after receiving a data update message at a node in a data version management method according to an embodiment of the present invention. The node that stores and manages the replica of the data plays a general role of the database, and the updating of the data and the version information is changed according to messages input from the version control apparatus 100 and other nodes.

Referring to FIG. 11, when a message is received from a version control device 100 or another node of a grid database (S410), a type of a received message is checked. The received message is a version information update success message (VM SUC). MSG) (S420).

As a result of checking in S420, if the received message is a version information update success message, it is checked whether the version information in which the received update is successful is a version earlier than the version information stored in the node (S430).

As a result of the check in S430, if the version information received successfully is the same as the version information stored in the node or the previous version, the version information of the data stored in the node and the version information of the data stored in the version control device 100 Since it is the same, there is no need to perform an update operation.

However, as a result of checking in S430, when the version information for which the received update is successful is the latest version information than the version information stored in the node, it is necessary to perform the update operation of the version information.

In this case, the received version information is stored in the Insert First PQ function (S440). Thereafter, if the priority queue is not exceeded, the received version information is inserted into Insert PT (S450). Then, it is checked whether the result value of the Insert First PQ function is FULL (S460). As a result of the check in S460, if the result value of the Insert First PQ function is FULL PQ, the delay message is transmitted to the version control device because the space of the priority queue is used up (S470). After that, the update operation of version information is suspended until the delay is released.

Returning to S420, if it is determined that the received message is not a version information update success message, it is checked whether the received message is a version information delivery delay message (VM WAIT MSG) (S480).

As a result of checking in S480, when the received message is a version information delivery delay message, the node transmits an update message to the version control device 100 even though the version control device 100 receives the information of the node where the delay has occurred. In one case, no further updates occur and must be suspended.

To this end, the version control apparatus 100 transmits a version information transfer delay message to the node, and the node receiving the same, suspends the update operation of the version information of the table requesting the update operation by operating a delaying process. The node suspends the update operation until it receives a version information retransmission message (VM RE UPDATE MSG) (S490).

In step S480, if the received message is not a version information delivery delay message, it is checked whether the received message is a version information retransmission message (VM RE UPDATE MSG) (S500).

As a result of checking in S500, if the received message is a version information retransmission message, since the delay release is notified from the version information manager 100, the update of the data on which the update is suspended is performed (S510).

Here, the version information retransmission message (VM RE UPDATE MSG) is a message transmitted from the version information manager 100 to the delayed node. When the node receives this message, it is possible to perform the update of the data and data version information, which has been suspended due to a delay in the version control device.

The data version management method according to an embodiment of the present invention can maintain the consistency of data and version information of data in a grid database through the above-described processes.

Hereinafter, another embodiment of the data version management method will be described.

Nodes in the grid database store update messages with priority queues and perform update operations on data and version information sequentially. Here, a case may occur where messages transmitted and received by the version information management unit and the node exceed the queue limit of the node. In this case, a delay message can be sent to the version control device to suspend further update operations from occurring. However, there may occur a case where the update date information is lost because the node no longer receives the update message that has been executed up to now.

In addition, while waiting for the next version of the update data version, the next version of the data may not be inserted, and later versions may be inserted first to exceed a storage limit of the priority queue.

If you exceed the limit of the queue, you may get a deadlock that will not receive any more data and will not be able to process because the next updated version of the data processed so far is not in the queue.

In order to prevent the above-described exceptional case, the data version management method according to another embodiment of the present invention uses a message of a NOTE MP MSG message and a HASE MP MSG.

First, a message of NOTE MP MSG is a message transmitted to a higher node when there is no more available space in the priority queue of the lower node. Next, the message of the HASE MP MSG is a message transmitted when there is space available in the priority queue at the lower node.

If the node no longer has available space in the priority queue, it sends a CHI FULL MSG message and information of the version it is currently waiting to. The reason for sending a message to the parent node is because the node no longer has enough space to store the update data in the queue, so the parent node does not deliver the message but instead keeps the message to be delivered to the child node. Subsequently, when a lower node delivers a message that an empty space of the priority queue has occurred, the upper node delivers an update message stored in its own node.

In addition, the send block PQ message prevents the data of the priority queue from being transmitted to the lower node and delays deletion of the update message with respect to the data whose update operation is performed in the current node. This delays the deletion and transmission of data at the upper node because no more update data can be stored at the lower node, thus ensuring that no data is lost at the lower node. In addition, if its own node fails to send update data to the lower node and the data accumulates and exceeds the limit that the priority queue can store, it sends a NOTE MP MSG message to its upper node. if. When the lower node sends a message of HASE MP MSG to the upper node, it transmits update data and deletes the transmitted data.

When a node receives a message of HASE MP MSG from its own node, Wanted Update data is a function that sends version information of data required by its subordinate node. By using this function, deadlocks in the priority queue at the lower node can be prevented.

12 is a view showing the update completion time according to the number of copies, FIG. 13 is a view showing the search rate for the information reflecting the update data according to the change in the access frequency, Figure 14 is a change in network usage according to the change in the access frequency It is a figure which shows.

Hereinafter, various effects obtained through the data version control method and apparatus according to the embodiment of the present invention and simulation results for verifying the same will be described with reference to FIGS. 12 to 14.

In order to prove that the data and data version control performance of the grid database is improved through the data version control method and apparatus according to an embodiment of the present invention, simulation was performed under the conditions of Table 1 below. The simulation was divided into three types: first, update completion time according to the number of replicas, second, search rate for information reflecting update data according to the change of access frequency, and third, network according to the change of access frequency. The usage was performed.

Experimental element Experimental data Experimental elements Experimental data Experiment time 30,000 unit Update operation processing time 4 to 7 unit Number of servers 200 to 400 Update information transmission time 2 to 4 unit Number of tables per node 0 to 300 Update query input interval 0.1 unit Transfer rate change rate 10 to 12 unit

Table 1 is an experimental environment for evaluating update data processing performance, and the information such as storage size of each node and queue size for logs is insignificant in the actual experiment evaluation, and thus the evaluation value is omitted. It was.

CSIM, a C / C ++ language based simulation tool, was applied to evaluate the data version control method according to an embodiment of the present invention. CSIM is a tool that enables most simulations, including computing models and algorithm evaluation in distributed environments.

In order to implement the data version management method according to an embodiment of the present invention, a plurality of clients and servers are configured, and the proposed queue data structure is stored in all servers. In addition, we used MS Visual C ++ 6.0 as the algorithm language to implement the simulation. The overall configuration allowed the use of replicas to suit the grid environment, and the evaluation was performed by setting the ranges of different queue sizes and query processing speeds at different nodes for performance evaluation in heterogeneous distributed environments.

Hereinafter, in the simulation results of FIGS. 12 to 14, a data version management method according to an embodiment of the present invention is defined as a DAF-tree. In addition, the data version control method of the related art compared to the data version control method according to an embodiment of the present invention applies a fast-consistency (FC) maintaining method as an example.

In addition, as a comparison target of the simulation, the fast FC method and the fast FC method are expanded to include the concept of representative nodes, and the fast-consistency with leader (FCL) method and the adaptive replica consistency service (ARCS) method are compared as examples of the simulation. Applied.

Here, the ARCS is a coherence service used in the data grid and uses a plurality of master nodes for fast update propagation. The master node is known as a data version control method that can improve the parallelism of the propagation process by updating a message to other nodes by placing a plurality of these nodes as the first update node.

Factors to be evaluated for the experiment include the time required for all nodes to be updated for any update operation, the retrieval rate of the update reflection information per unit time according to the change rate of the access frequency, and the network use rate. The retrieval rate of information per unit time means that the higher the value is, the higher the update information reflection rate is in the environment in which the access frequency is dynamically changed.

First, a simulation of the update completion time according to the number of replicas was first performed, and the result is shown in FIG. 12.

In the data version management method (DAF-tree) according to an embodiment of the present invention, it can be seen that the completion time is faster than the FC and FCL methods according to the prior art. This is because the update operation in the data version management method (DAF-tree) according to the embodiment of the present invention uses a message exchange method that is smaller than the FC and FCL methods of the prior art.

In the data version control method (DAF-tree) according to an embodiment of the present invention, since priorities are determined according to the access frequency, update messages are sequentially delivered without any special process. However, prior art FC and FCL methods precede the message exchange for priority comparison before delivering the update message. As a result, a difference in performance occurs as shown in FIG. 12.

Secondly, a simulation result of a search rate and network usage rate of the update reflection information per unit time when the access frequency value of each node is continuously changed is shown in FIG. 13.

In FIG. 13, the "search ratio of updated reflecting information" on the vertical axis means "a ratio indicating how many nodes have updated information reflected among the nodes constructed through each tree (where the tree is built in the grid database in advance). do. In addition, the "% change rate of access frequency" on the horizontal axis causes a load of the entire system through continuous access to each node, thereby causing a situation in which an update operation is slowed. It means the rate of change in the frequency of access at this time.

The change in the access frequency of each node is calculated as a change rate compared to the initial access frequency value, and it can be seen that the phase change between nodes in the data version management method (DAF-tree) according to the embodiment of the present invention increases as the ratio increases. In addition, it can be seen that the rate of retrieving updated information per unit time drops significantly with the change of the access frequency. In FIG. 13, the reduction ratio of the conventional data version management methods is larger than the data version control method (DAF-tree) according to the embodiment of the present invention. This is because the comparison is not smooth.

Next, a simulation result showing the network usage according to the change of the access frequency in packet units is shown in FIG. 14.

Through the data version management method (DAF-tree) according to an embodiment of the present invention it can be seen that the network usage is increased compared to the prior art. In addition, the data version control method (DAF-tree) according to an embodiment of the present invention was evaluated by increasing the threshold of each node, that is, the number of lower nodes from 4 to 20, in addition to the network speed When the processing speed of each node is changed and the overall performance is changed, the performance is improved compared to the FC and FCL methods of the prior art. Here, the threshold value of the data version control method (DAF-tree) according to an embodiment of the present invention for optimal performance may be applied differently depending on the environment of the grid database.

Data version management method and apparatus according to an embodiment of the present invention can provide a data version management method and apparatus for maintaining the consistency of the data version in the grid database that allows the replica data in a plurality of nodes through the above-described configuration and method have.

The data version control method according to an embodiment of the present invention manages the cache through a version control device such as a processor in the grid database in order to maintain consistency due to concurrent multiple update operations of the replica data.

Version management apparatus according to an embodiment of the present invention has a structure for the version information in order to maintain the data consistency of the replica in the grid database, the version information is composed of the structure of the previous version value and the next version value. You can use these two values to keep your replica consistent.

In addition, the work queue managed by the version control device stores the position information of the node where the update operation occurs when a delay of the update operation occurs due to the workload of some nodes in the process of the update operation that occurs simultaneously. As future workloads ease, the queued information is processed again by update operations to ensure the consistency of concurrent data.

In the performance evaluation through simulation, the data version control method according to the embodiment of the present invention achieves 5 to 25% performance improvement over the prior art. This means that the performance of the grid database can be improved by maintaining the consistency of the data and the data version information in the grid database through the version management method and apparatus according to an embodiment of the present invention.

Data version management method according to an embodiment of the present invention can be useful in a grid database environment or a distributed database environment having a large number of nodes and having replica data.

The configuration and operation as described above is not limited to the claims of the present invention as an embodiment, and various changes and modifications are possible within the scope of not changing the technical spirit of the present invention in the field to which the present invention belongs. It is obvious to those who are engaged.

It is apparent to those skilled in the art that the present invention can be embodied in other specific forms without departing from the spirit and essential features of the present invention. Accordingly, the above detailed description should not be construed as limiting in all aspects and should be considered as illustrative. The scope of the invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the invention are included in the scope of the invention.

1 is a view showing the structure of a grid database according to the prior art.

2 is a diagram showing a grid database including a version control device according to an embodiment of the present invention.

3 is a diagram illustrating a configuration of a version control apparatus according to an embodiment of the present invention.

4 is a diagram illustrating a version information structure of a version management method according to an embodiment of the present invention.

5 is a diagram illustrating a priority queue of a version control method according to an embodiment of the present invention.

6 is a diagram illustrating an excess capacity queue of a version control method according to an embodiment of the present invention.

7 is a view showing a priority update queue of the version control method according to an embodiment of the present invention.

8 is a flowchart illustrating a data version management method according to an embodiment of the present invention.

9 is a flowchart illustrating a message transmission / reception process between a version control apparatus and a node in a data version management method according to an embodiment of the present invention.

10 is a flowchart illustrating a processing process after receiving a data update message in a version control apparatus in a data version management method according to an embodiment of the present invention.

11 is a flowchart illustrating a processing process after receiving a data update message at a node in a data version management method according to an embodiment of the present invention.

12 shows the update completion time according to the number of replicas.

FIG. 13 is a diagram illustrating a search rate for information in which update data is reflected according to a change in access frequency. FIG.

14 is a view showing a change in network usage according to a change in access frequency.

<Explanation of symbols for the main parts of the drawings>

100: version control device 110: root node

120, 130, 140: node 112: terminal

210: version information management unit 220: work queue management unit

230: priority queue management unit 240: excess capacity queue management unit

250: first update queue management unit

Claims (5)

In the data version management method of a grid database including a plurality of nodes, Generating a data update operation from a node to receive a request for new version information of the data; Determining whether to process the new version information request; If it is determined that the processing is possible, generating new version information and updating the version information; And And transmitting the new version information to the node. The method of claim 1, If the judgment is not possible, Storing a new version information request from the node in a queue; And And notifying the node to stop performing the update. The method of claim 1, The determination of whether or not to process the new version information request Comparing first version information of the data from the node with second version information including previous version information and current version information stored in a version control device, If the first version information is equal to the second version information and the first version information is identical to the second version information, the new version information request is processed; And when the first version information and the second version information are different, suspend the processing of the new version information request so that data is not updated in a plurality of nodes of the grid database. The method of claim 1, If a delay occurs in a first node of a plurality of nodes of the grid database, data update is suspended from other nodes besides the first node until the delay of the first node is released. Version control method. In the data version management apparatus for managing the data version of the grid database including a plurality of nodes, A version information manager configured to generate and manage version information of updated data from the plurality of nodes; A work queue manager for creating and managing a work queue used when a new update calculation process is to be stopped due to a workload of some nodes in a process of updating a plurality of nodes simultaneously; Receiving information about data updates made by multiple nodes at the same time and storing them in a work queue, and priorities for controlling the priorities of the nodes so that updates of data made by the multiple nodes can be performed sequentially. Management; An excess capacity queue manager configured to store and manage information of nodes whose update operations are delayed among the plurality of nodes in an excess capacity queue; And And a priority update queue manager for storing and managing update operation request messages received from the plurality of nodes in a priority update queue after an update delay occurs in at least one of the plurality of nodes. Version control device.

Images