Data management system and data management program

Abstract

To provide data management means which improves data consistency while maintaining high availability in a distributed computing environment.SOLUTION: A data management system includes a user terminal, a data management apparatus, a main server, and a set of replica servers. The data management apparatus includes: a management unit which receives a write request, specifies data to be written, writes the specified data to be written in a storage part, and transfers the write request to the main server; and a read management unit which receives a read request from the user terminal, specifies data to be read, specifies a target replica server that satisfies a predetermined recency criterion for the data to be read and satisfies a predetermined access criterion from the set of replica servers, and transfers the read request to the target replica server. The main server transmits the data to be written to each of the replica servers included in the set of replica servers.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present disclosure relates to a data management system and a data management program. [Background technology]

[0002] In recent years, so-called distributed computing has become the mainstream method of executing programs. Distributed computing refers to a method in which individual parts of a program are executed simultaneously and in parallel on multiple computers, and the processing proceeds as a whole while each computer communicates with the other computers via a network.

[0003] In a system that uses distributed computing (hereinafter referred to as a "distributed system"), a database that stores data used by a program is distributed over a network, just like the program. However, when a database is distributed among different nodes on a network, it becomes difficult to maintain the consistency, availability, and partition tolerance of the database, which gives rise to problems. Consistency means that each database distributed across different nodes on a network always maintains the latest data. Availability means that database data remains available even if a failure or fault occurs in the distributed system. Partition tolerance means that consistency and availability are maintained even if the network of a distributed system is divided into multiple groups.

[0004] According to the CAP theorem, known in distributed computing, it is possible to guarantee two of the three characteristics mentioned above, consistency, availability, and partition tolerance, at the same time, but it is not possible to guarantee all of them at the same time. Therefore, when building a distributed system, it is necessary to consider which two of consistency, availability, and partition tolerance should be prioritized.

[0005] Many modern distributed systems prioritize availability and partition tolerance over consistency, and use a system based on "eventual consistency" that tolerates a certain amount of stale data. Eventual consistency is a method to ensure final consistency by updating the corresponding database after a certain period of time has passed, rather than immediately updating the corresponding database when data is updated in the distributed system's database, in order to achieve high availability.

[0006] In a distributed system based on eventual consistency (hereafter referred to as an "eventual consistency system"), when a database is updated, other databases corresponding to that database are eventually updated after a certain period of time has passed, but old data may temporarily exist until the updates. Providing this old data in response to a read request to the database may result in losses due to a lack of accuracy or consistency of the data, so it is desirable to avoid using old data in processing.

[0007] Conventionally, several means have been proposed for improving data consistency. For example, U.S. Patent No. 9,251,072 (Patent Document 1) describes a technology that "generally describes a technology relating to a cache coherence directory for a multiprocessor architecture. In one example, a directory in a chip may receive a request for a particular block. The directory may determine a block aging threshold for the likelihood that multiple data blocks, including the particular data block, are stored in one or more caches in the chip. Additionally, the directory may analyze memory to identify a particular cache that has been indicated as storing the particular data block and to identify the number of cache misses for the particular cache. The directory may identify the time when an event occurred for the particular data block and may determine whether to send a request for the particular data block to a particular cache based on the aging threshold, the time of the event, and the number of cache misses." [Prior art documents] [Patent documents]

[0008] [Patent Document 1] U.S. Patent No. 9,251,072 Summary of the Invention [Problem to be solved by the invention]

[0009] Patent document 1 describes a means for preventing old data from being provided in response to a data read request in a multiprocessor architecture by determining which cache to use to obtain the data when the data read request is received based on an aging threshold indicating the age of the data in the cache, the time the event occurred, and the number of cache misses.

[0010] However, since a distributed system is composed of multiple nodes that are geographically separated, communication between the nodes takes time, and nodes may go down due to failures or maintenance, resulting in loss of communication. Therefore, when reading or writing data in a distributed system, it is desirable to take into account the state of the nodes and their geographical locations.

[0011] However, the means described in Patent Document 1 is related to a method for dealing with old data in a multiprocessor architecture, and does not take into account the specific structure and requirements of the distributed computing environment described above, so the cache coherence management means described in Patent Document 1 cannot be applied to a distributed system.

[0012] Therefore, an object of the present disclosure is to provide a data management means for improving data consistency while maintaining high availability in a distributed computing environment. [Means for solving the problem]

[0013] In order to solve the above problems, one representative data management system of the present invention is a data management system in which a user terminal used by a user, a data management device, a main server, and a set of replica servers including a plurality of replica servers are connected via a communication network, the data management device having a processor and a memory, the memory including processing instructions for causing the processor to function as a write management unit for receiving a write request, identifying write target data specified in the write request, and writing the identified write target data to the main server, and a read management unit for receiving a read request from the user terminal, identifying read target data specified in the read request, identifying a target replica server from the set of replica servers that satisfies a predetermined recency criterion and a predetermined access criterion, acquiring the read target data from the identified target replica server, and providing the data to the user terminal, the main server writing the write target data to a first replica server included in the set of replica servers. Effect of the Invention

[0014] According to the present disclosure, it is possible to provide a data management means for improving data consistency while maintaining high availability in a distributed computing environment. Other objects, configurations and effects will become apparent from the following description of the preferred embodiment of the invention. [Brief description of the drawings]

[0015] [Figure 1] FIG. 1 illustrates a computer system for implementing an embodiment of the present disclosure. [Diagram 2] FIG. 2 is a diagram illustrating an example of a configuration of a data management system according to an embodiment of the present disclosure. [Diagram 3] FIG. 3 is a diagram illustrating an example of the flow of a write management process according to an embodiment of the present disclosure. [Figure 4]FIG. 4 is a diagram showing an example of a data flow in a write management process according to an embodiment of the present disclosure. [Diagram 5] FIG. 5 is a diagram illustrating an example of the flow of a reading management process according to an embodiment of the present disclosure. [Figure 6] FIG. 6 is a diagram illustrating an example of a data flow in a reading management process according to an embodiment of the present disclosure. [Figure 7] FIG. 7 is a diagram illustrating an example of the flow of the access evaluation process according to the embodiment of the present disclosure. [Figure 8] FIG. 8 is a diagram illustrating an example of a GUI of the data management device according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Note that the present invention is not limited to the embodiment. In addition, in the description of the drawings, the same parts are denoted by the same reference numerals. In addition, terms such as "first," "second," and "third" may be used to describe various elements or components in this disclosure, but it will be understood that these elements or components should not be limited by these terms. These terms are used only to distinguish one element or component from another element or component. Thus, a first element or component discussed below can also be referred to as a second element or component without departing from the teachings of the inventive concept.

[0017] (Summary of the Disclosure) The present disclosure relates to a data management means for improving data consistency in an eventual consistency system while maintaining high availability. In one embodiment, when a write request is received in a data management device, the data management device writes the write target data specified in the write request to its own storage unit, and then transfers the write request to a primary server. The primary server writes the write target data to each replica server included in a set of replica servers. When writing the write target data, each replica server stores metadata indicating the version of the written write target data, etc., in a metadata DB stored in the data management device. This allows the data management device to manage the state of each replica server and the version of the write target data.

[0018] In addition, when a read request is received by the data management device, the data management device identifies the data to be read specified in the read request, and by referring to the metadata DB, identifies a target replica server that satisfies access criteria based on communication time, distance, etc. from among the replica servers that store the latest version of the data to be read, and transfers the read request to the identified target replica server.

[0019] In this way, by managing the versions of data stored in each set of replica servers included in the distributed system in the metadata DB, when a read request is made, it is possible to identify a replica server that has the latest version of the data to be read that is requested in the read request and can respond quickly. This makes it possible to improve data consistency while maintaining high availability in a distributed computing environment.

[0020] Next, referring to Fig. 1, a computer system 100 for implementing an embodiment of the present disclosure will be described. The mechanisms and devices of the various embodiments disclosed herein may be applied to any suitable computing system. The main components of the computer system 100 include one or more processors 102, memory 104, a terminal interface 112, a storage interface 113, an I / O (input / output) device interface 114, and a network interface 115. These components may be interconnected via a memory bus 106, an I / O bus 108, a bus interface unit 109, and an I / O bus interface unit 110.

[0021] Computer system 100 may include one or more general purpose programmable central processing units (CPUs) 102A and 102B, collectively referred to as processors 102. In some embodiments, computer system 100 may include multiple processors, while in other embodiments, computer system 100 may be a single CPU system. Each processor 102 executes instructions stored in memory 104 and may include an on-board cache.

[0022] In one embodiment, memory 104 may include random access semiconductor memory, storage devices, or storage media (either volatile or non-volatile) for storing data and programs. Memory 104 may store all or a portion of the programs, modules, and data structures that implement the functions described herein. For example, memory 104 may store data management application 150. In one embodiment, data management application 150 may include instructions or descriptions that execute on processor 102 the functions described below.

[0023] In some embodiments, data management application 150 may be implemented in hardware via semiconductor devices, chips, logic gates, circuits, circuit cards, and / or other physical hardware devices instead of or in addition to a processor-based system. In some embodiments, data management application 150 may include data other than instructions or descriptions. In some embodiments, cameras, sensors, or other data input devices (not shown) may be provided to communicate directly with bus interface unit 109, processor 102, or other hardware of computer system 100.

[0024] Computer system 100 may include a bus interface unit 109 that provides communication between processor 102, memory 104, display system 124, and I / O bus interface unit 110. I / O bus interface unit 110 may couple to an I / O bus 108 for transferring data to and from various I / O units. I / O bus interface unit 110 may communicate via I / O bus 108 with multiple I / O interface units 112, 113, 114, and 115, also known as I / O processors (IOPs) or I / O adapters (IOAs).

[0025] Display system 124 may include a display controller, a display memory, or both. The display controller may provide video, audio, or both data to display device 126. Computer system 100 may also include one or more sensors or other devices configured to collect data and provide the data to processor 102.

[0026] For example, computer system 100 may include biometric sensors to collect heart rate data, stress level data, etc., environmental sensors to collect humidity data, temperature data, pressure data, etc., and motion sensors to collect acceleration data, movement data, etc. Other types of sensors may also be used. Display system 124 may be connected to a display device 126, such as a standalone display screen, a television, a tablet, or a handheld device.

[0027] The I / O interface unit provides the ability to communicate with various storage or I / O devices. For example, the terminal interface unit 112 may be attached to user I / O devices 116, such as user output devices, such as a video display, a television with speakers, and user input devices, such as a keyboard, a mouse, a keypad, a touchpad, a trackball, buttons, a light pen, or other pointing device. A user may use a user interface to enter input data or instructions to the user I / O devices 116 and the computer system 100, and receive output data from the computer system 100, by manipulating the user input devices. The user interface may be displayed on a display, played through speakers, or printed via a printer, for example, via the user I / O devices 116.

[0028] Storage interface 113 allows attachment of one or more disk drives or direct access storage device 117 (usually a magnetic disk drive storage device, but may be an array of disk drives or other storage devices configured to appear as a single disk drive). In some embodiments, storage device 117 may be implemented as any secondary storage device. Contents of memory 104 may be stored in storage device 117 and retrieved from storage device 117 as needed. I / O device interface 114 may provide an interface to other I / O devices such as printers, fax machines, etc. Network interface 115 may provide a communications path to allow computer system 100 and other devices to communicate with each other. This communications path may be, for example, network 130.

[0029] In one embodiment, computer system 100 may be a device that receives requests from other computer systems (clients) without a direct user interface, such as a multi-user mainframe computer system, a single-user system, or a server computer, etc. In other embodiments, computer system 100 may be a desktop computer, a portable computer, a laptop, a tablet computer, a pocket computer, a telephone, a smartphone, or any other suitable electronic device.

[0030] Next, a data management system according to an embodiment of the present disclosure will be described with reference to FIG.

[0031] FIG. 2 is a diagram showing an example of a configuration of a data management system 200 according to an embodiment of the present disclosure. The data management system 200 is a system that can improve data consistency while maintaining high availability in a distributed computing environment. As shown in FIG. 2, the data management system 200 mainly includes a data management device 160, a client application 161, a primary server 178, a secondary server 180, a set of replica servers including multiple replica servers 182 and 184, a user terminal 186, and a GUI 187. In the data management system 200, the data management device 160, the client application 161, the primary server 178, the secondary server 180, the multiple replica servers 182 and 184, the user terminal 186, and the GUI 187 may be connected to each other via one or more communication networks (not shown in FIG. 2).

[0032] The client application 161 may be any application that transmits a write request 163 to the data management device 160 via a communication network. The write request 163 here is a request to add or change new data or information. In this disclosure, the data that is requested to be written by the write request 163 is referred to as "data to be written."

[0033] The data management device 160 is a device that can improve data consistency while maintaining high availability in a distributed computing environment, and as shown in FIG. 2, includes a memory 162, a ROM 164, a storage unit 166, a write management unit 168, a metadata management unit 170, a read management unit 172, a replica identification unit 174, and a request forwarding unit 176.

[0034] The memory 162 may be a memory for storing a data management application (e.g., data management application 150 shown in FIG. 1) according to an embodiment of the present disclosure. The data management application may include instructions for causing a processor to implement the functions of the write manager 168, the metadata manager 170, the read manager 172, the replica identifyr 174, and the request forwarder 176 shown in FIG. A ROM (Read-Only Memory) 164 is a memory used to store auxiliary data and programs for the data management application 150 .

[0035] The storage unit 166 is a storage area that contains a database (hereinafter, "DB") for storing various information according to an embodiment of the present disclosure. In an embodiment, the storage unit 166 may store a transaction DB, a server DB, and a metadata DB, which will be described later.

[0036] The write management unit 168 is a functional unit that receives a write request 163 from the client application 161, identifies the data to be written specified in the write request 163, writes the identified data to be written to the transaction DB in the memory unit 166, and then transfers the write request 163 to the main server 178.

[0037] The primary server 178 may be any server including a CPU, a log, and a storage unit. The primary server 178 receives the data to be written from the write management unit 168 and writes the data to its own storage unit. After writing the data to be written, the primary server 178 returns an acknowledgment message ACK 169 indicating that the data to be written has been successfully written to the data management device 160. After writing the data to be written, the primary server 178 replicates the data to be written and transfers the data to the secondary server 180 in a synchronous update 165. Here, "synchronous update" refers to a data transfer method in which the data sender and receiver coordinate the timing of data transmission and reception. Since data transmission and reception are performed synchronously, the timing and order must match between the sender and receiver. This method guarantees data reliability and consistency, but since data transfer can take a long time, it is recommended to use it when high reliability is required.

[0038] The secondary server 180 may be any server including a CPU, a log, and a storage unit, similar to the primary server 178. The secondary server 180 writes the data to be written transferred from the primary server 178 to its own storage unit. After writing the data to be written, the secondary server 180 returns an acknowledgment message ACK 167 indicating that the data to be written has been successfully written to the primary server 178, and transmits metadata including the version of the written data to the data management device 160 by asynchronous update 171. After that, the secondary server 180 receives an acknowledgment message ACK 173 from the data management device 160 indicating that the metadata of the secondary server 180 has been successfully written to the metadata DB 166 of the data management device 160. Furthermore, after writing the data to be written, the secondary server 180 replicates the data to be written and transfers the data to the replica servers 182 and 184 in asynchronous updates 175 and 177 . Here, "asynchronous update" refers to a data transfer method that does not require the data sender and receiver to synchronize timing. In asynchronous data transfer, data is sent and received asynchronously between the sender and receiver, which increases the data transfer speed, but there is a possibility that the reliability and consistency of the data may be lost, so it is desirable to use this method when transfer speed is required.

[0039] The replica servers 182, 184 may be any servers including a CPU, a log, and a storage unit, similar to the primary server 178. The replica servers 182, 184 write the write target data transferred from the secondary server 180 to their own storage units. In addition, when the replica servers 182, 184 write the write target data, they transmit metadata including the version of the written write target data, etc., to the data management device 160 by asynchronous update 179. For convenience of explanation, FIG. 2 illustrates an example of a configuration including two replica servers 182, 184, but in reality, the number of replica servers 182, 184 is not limited.

[0040] The metadata management unit 170 of the data management device 160 is a functional unit that receives metadata transmitted from each of the secondary server 180 and the replica servers 182, 184, and stores the received metadata in a metadata DB stored in the memory unit 166.

[0041] The user terminal 186 is a terminal used by a user who wishes to view specific data. By using the user terminal 186, the user can create a read request 181 requesting specific data to be read, and transmit it to the data management device 160. As an example, the user terminal 186 may include a smartphone, a smart watch, a tablet, a personal computer, etc., and is not particularly limited. For ease of explanation, FIG. 2 illustrates an example of a configuration including one user terminal 186. However, the number of user terminals 186 is not limited, and a configuration including multiple user terminals 186 is also possible.

[0042] The read management unit 172 includes a replica identification unit 174 that receives a read request 181 from a user terminal 186, identifies the data to be read specified in the read request 181, and identifies a target replica server from among the replica servers 182, 184 that satisfies a predetermined recency standard for the data to be read and also satisfies a predetermined access standard by referring to a metadata DB stored in the memory unit 166, and a request forwarding unit 176 that forwards the read request 181 to the identified target replica server. As shown in FIG. 2, the replica server to which the read request 181 has been transferred transmits a response 185 to the read request 181 to the user terminal 186 .

[0043] The GUI 187 is a user interface for displaying information regarding the status of each server included in the data management system. This GUI 187 may be output to a terminal used by an administrator of the data management device 160, a user terminal 186, or any other terminal of a user with access authority.

[0044] In this way, according to the data management system 200 configured as shown in Fig. 2, the version of the data stored in each set of replica servers can be managed in the metadata DB, so that when a read request is received, a replica server that has the latest version of the data to be read and can provide it quickly can be identified. This makes it possible to improve data consistency while maintaining high availability in a distributed computing environment.

[0045] In FIG. 2, a configuration including a main server, a secondary server, and a plurality of replica storage servers is described as an example, but in one embodiment, a configuration of the data management system 200 including two types of servers, a main server and replicas, without providing a secondary server is also possible. In this case, the main server plays the role of the secondary server described above and can replicate write metadata to each replica server. However, since the use of a configuration including a secondary server can reduce the processing load of the main server, it is desirable to use a configuration including a secondary server when the computing resources of the main server are limited. In the following, for convenience of explanation, a configuration including a main server, a secondary server, and a replica storage server as shown in FIG. 2 is described as an example.

[0046] Next, a write management process according to an embodiment of the present disclosure will be described with reference to FIG.

[0047] 3 is a diagram showing an example of the flow of a write management process 300 according to an embodiment of the present disclosure. The write management process 300 shown in FIG. 3 is a process that is performed when the data management device 160 receives a write request, and may be executed by the write manager 168, the primary server 178, the secondary server 180, and the replica servers 182 and 184 shown in FIG.

[0048] First, in step P301, the writing management unit 168 of the data management device 160 receives a writing request from the client application 161. Here, the writing management unit 168 may receive a so-called POST request as the writing request.

[0049] Next, in step P302, the write management unit 168 identifies the data to be written specified in the write request received in step P301, updates the transaction DB stored in the memory unit 166 based on the identified data to be written, and transfers the write request to the main server 178.

[0050] Next, in step P303, the write management unit 168 waits for a predetermined timeout period. This timeout period is the maximum time to wait for a response from the primary server 178, and may be freely set by the user. If there is no response from the primary server 178 after waiting for the timeout period, the process proceeds to step P304. On the other hand, if there is a response from the primary server 178 within the timeout period, the process proceeds to step P306.

[0051] Next, in step P304, if there is no response from the primary server 178 even after waiting for the timeout period, the write management unit 168 identifies a replica server that satisfies a predetermined recency criterion from the set of replica servers included in the data management system 200 (e.g., replica servers 182, 184). The "latestness criterion" here refers to a criterion for evaluating the recency of data stored in a replica server, and may be, for example, information that specifies the version of a specific piece of data. If the version of data stored in a replica server is newer than the version specified in the recency criterion, the replica server is deemed to satisfy the recency criterion, and if the version of data stored in a replica server is older than the version specified in the recency criterion, the replica server is deemed not to satisfy the recency criterion.

[0052] Next, in step P305, the write management unit 168 promotes the replica server that satisfies the recency criterion, identified in step P304, to a primary server. More specifically, in order to promote the replica server to a primary server, the write management unit 168 registers the identified replica server as a "primary server" in the server DB stored in the storage unit 166. As a result, in the subsequent processing, the replica server is used as the new primary server.

[0053] Next, in step P306, the primary server 178 writes the data to be written specified in the write request received from the write manager 168 to its own storage unit, and transmits the data to be written to the secondary server 180.

[0054] Next, in step P307, the primary server 178 waits for a predetermined time-out period. If there is no response from the secondary server 180 after waiting for the time-out period, the process proceeds to step P308. On the other hand, if there is a response from the secondary server 180 within the time-out period, the process proceeds to step P310.

[0055] Next, in step P308, if there is no response from the secondary server 180 after waiting for the timeout period, the primary server 178 identifies a replica server from the set of replica servers included in the data management system 200 (e.g., replica servers 182, 184) that satisfies a predetermined recency criterion, in the same manner as in step P304 described above.

[0056] Next, in step P309, the primary server 178 promotes the replica server that satisfies the recency criteria identified in step P304 to a secondary server. More specifically, to promote a replica server to a secondary server, the primary server 178 registers the identified replica server as a "secondary server" in the server DB stored in the memory unit 166. As a result, in the subsequent processing, the replica server is used as a new secondary server.

[0057] Next, in step P310, secondary server 180 writes the data to be written received from primary server 178 to its own storage unit, and sends an acknowledgment message to data management device 160 indicating that the writing has been completed successfully.

[0058] Next, in step P311, secondary server 180 transmits metadata including information about the data to be written written in step P310 and information about secondary server 180 to data management device 160 in an asynchronous update. This metadata may include information such as a server ID identifying secondary server 180, the geographic location of secondary server 180, a transaction ID identifying the data to be written, the destination to which the data to be written is to be written, and the date and time when the data to be written is written. In one embodiment, this metadata may also include version information indicating the version stored on secondary server 180.

[0059] Next, in step P312, the secondary server 180 writes the write target data received from the primary server 178 in step P310 to the set of replica servers (eg, replica servers 182, 184) in an asynchronous update. It should be noted that the secondary server 180 may perform steps P311 and P312 in parallel.

[0060] Next, in step P313, the metadata management section 170 of the data management device 160 receives the metadata transmitted from the secondary server 180 in step P311, and stores it in the metadata DB stored in the storage section 166.

[0061] Next, in step P314, the set of replica servers (e.g., replica servers 182, 184) send metadata to the data manager 160 in an asynchronous update, including information about the data to be written in step P312 and information about each replica server. In one embodiment, this metadata may also include version information indicating the version stored on each replica server.

[0062] Next, in step P315, the metadata management section 170 of the data management device 160 receives the metadata transmitted from each replica server in step P314, and stores it in the metadata DB stored in the storage section 166.

[0063] 3, the write management process 300 can write the write target data specified in the write request to each server included in the data management system 200, and can also build a metadata DB including metadata indicating the geographical location of each server and the version of the stored data. As will be described later, by using this metadata DB, when responding to a read request from a user terminal, it is possible to identify a target replica server that satisfies an access criterion based on communication time, distance, etc. from among replica servers that store the latest version of the read target data.

[0064] Next, a data flow in the write management process according to an embodiment of the present disclosure will be described with reference to FIG.

[0065] FIG. 4 is a diagram showing an example of a data flow in a write management process according to an embodiment of the present disclosure.

[0066] First, the client application 161 transmits a write request 401 including data to be written to the data management device 160. In one embodiment, the write request 401 may be a POST request using a REST API, requesting writing of the data to be written, “user_id:5, products: [X,Y]”.

[0067] Upon receiving the write request 401, the write management unit 168 (not shown in FIG. 4) of the data management device 160 saves the data to be written, which is included in the write request 401, in the transaction DBT1000 stored in the memory unit 166. This transaction DBT1000 includes a transaction ID (Transaction_ID) T1040 that uniquely identifies the write request or read request, and a transaction content (In_Transaction) T1020 that indicates the content of the write request or read request. In one embodiment, the information stored in the transaction details T1020 may be written in the format of "Table Name_Identifier," where "Table Name" is the table name specified in the write request 401, and "Identifier" is information indicating the value of the data to be written or read.

[0068] The write management unit 168 updates the transaction DBT 1000 based on the write request 401, and then transmits the write request 401 to the main server 178. Upon receiving the write request 401, the main server 178 writes the write target data specified in the write request 401 into its own storage unit. For example, when a write request 401 including the write target data "user_id:5, products: [X,Y]" is received, the main server 178 can create an updated user DBT1310 by adding the information "user_id:5" to the user DBT1300 stored in its own memory, and can create an updated order DBT1410 by adding the information "products: [X,Y]" to the order DBT1400 stored in its own memory.

[0069] After the primary server 178 writes the data to be written specified in the write request 401 to its own storage unit, the primary server 178 uses a predetermined data replication means 410 to transfer the data to be written to the secondary server 180. The data replication means 410 here may include, but is not limited to, change data capture, transactional replication, snapshot replication, and the like. Furthermore, after the main server 178 writes the data to be written specified in the write request 401 to its own storage unit, it transmits an acknowledgment message ACK 414 to the client application 161 indicating that the data to be written has been successfully written.

[0070] Secondary server 180 receives the data to be written transferred from primary server 178 and writes it to its own storage unit. For example, when secondary server 180 receives data to be written, "user_id:5, products: [X,Y]", it may add the information "user_id:5" to user DBT 1500 stored in its own storage unit, and add the information "products: [X,Y]" to order DBT 1600 stored in its own storage unit.

[0071] Additionally, when the secondary server 180 writes the data to be written, it returns an acknowledgment message ACK 412 indicating that the data to be written has been successfully written to the primary server 178, and transmits metadata 416 to the data manager 160 in an asynchronous update. In one embodiment, the secondary server 180 may repeatedly transmit the metadata 416 until it receives an acknowledgment message ACK 415 from the data manager 160.

[0072] Metadata 416 may include information indicating a server ID that uniquely identifies secondary server 180, a table name indicating the destination of the data to be written, a geographic location of secondary server 180, a server type of secondary server 180 (primary, secondary, replica), a transaction ID that identifies the data to be written, a date and time when the data to be written was written, and a version of the data to be written. In one embodiment, metadata 416 may also include version information indicating the version of the data stored on secondary server 180. The primary server 178 forwards the acknowledgment message ACK 412 received from the secondary server 180 to the client application 161 .

[0073] Furthermore, after writing the data to be written, the secondary server 180 replicates the data to be written and transfers the data to the replica servers 182 and 184 in an asynchronous update 420 .

[0074] Here, we will explain an example in which the replica server 182 successfully receives the data to be written transferred from the secondary server 180 and writes it to its own memory, but the replica server 184 does not receive the data to be written due to a malfunction or communication failure, etc. The replica server 182 that receives the data to be written writes the data to the user DBT 1700 and order DBT 1800 stored in its own memory, and transmits metadata 422, which includes the version of the written data to be written, to the data management device 160 by asynchronous update. However, the replica server 184 was unable to receive the data to be written. The write target data cannot be written, and the metadata is not transmitted to the data management device 160.

[0075] When the data to be written is written to the secondary server 180 , the write management unit 168 of the data management device 160 deletes the data to be written from the transaction DB 1000 . Furthermore, the metadata management unit 170 of the data management device 160 receives the metadata 416 , 422 transmitted from the secondary server 180 and the replica server 182 , respectively, and stores the received metadata 416 , 422 in the metadata DBT 1100 .

[0076] 4, the metadata DBT1100 may include a server ID T1110 that uniquely identifies each server included in the data management system 200, a table name T1120 that identifies a table in which the data to be written is stored in each server, a geographical location T1130 of each server, freshness (is_available) T1140 that indicates whether each server meets a freshness criterion, and version information T1150 that indicates the version of the data to be written stored in each server. In the metadata DBT1100, when a value of "Y" (YES) is stored for a specific server, it means that the server meets the freshness criterion, and when a value of "N" (YES) is stored for a specific server, it means that the server does not meet the freshness criterion.

[0077] As an example, when the metadata management unit 170 creates updated metadata DBT1900 by updating metadata DBT1100 based on the received metadata 416, 422, the primary server 178 corresponding to the server ID "10H4334", the secondary server 180 corresponding to the server ID "69F432A", and the replica server 182 corresponding to the server ID "701H4920" have the latest version of the data to be read and their recency is "Y", whereas the replica server 184 corresponding to the server ID "60AA82O" does not have the latest version of the data to be read due to a malfunction, delay, communication failure, etc. and their recency is "N".

[0078] Furthermore, the data management device 160 uses a server DBT1200 to manage information about each server included in the data management system 200. As shown in Fig. 4, the server DBT1200 may include a server ID (Server_ID) T1220 that uniquely identifies each server included in the data management system 200, and a server type (Server_Type T1210) that indicates the type of each server (primary, secondary, replica). In one embodiment, when there is no response from a primary server or secondary server within a timeout period, the data management device 160 can promote a specific replica server to a new primary server or secondary server by changing the server type T1210 in the server DBT1200 of the specific replica server from among the replica servers that satisfy the recency criteria.

[0079] 4, the data to be written specified in a write request can be written to each server included in the data management system 200, and a metadata DB can be constructed including metadata indicating the geographical location of each server and the version of the stored data. As will be described later, by using this metadata DB, when responding to a read request from a user terminal, a target replica server that satisfies an access criterion based on communication time, distance, etc. can be identified from among the replica servers storing the latest version of the data to be read.

[0080] Next, a read management process according to an embodiment of the present disclosure will be described with reference to FIG.

[0081] Fig. 5 is a diagram showing an example of the flow of a reading management process 500 according to an embodiment of the present disclosure. The reading management process 500 shown in Fig. 5 is a process that is performed when the data management device 160 receives a reading request, and may be executed by the reading management unit 172 shown in Fig. 2.

[0082] First, in step P501, the read management unit 172 of the data management device 160 receives a read request from the user terminal 186. Here, the read management unit 172 may receive a so-called GET request as the read request. In addition, in the case of a data management system including multiple data management devices, the read request may be processed by a data management device that is registered as a leader in the data management system.

[0083] Next, in step P502, the read management unit 172 identifies the read target data specified in the read request received in step P501, and identifies the replica server that stores the read target data. Here, the read management unit 172 can identify the replica server that stores the specific read target data by referring to the above-mentioned metadata DB.

[0084] Next, in step P503, the reading management unit 172 determines whether the data to be read identified in step P502 is currently stored in the transaction DB (transaction DBT2100 shown in FIG. 6) of the memory unit 166 of the data management device 160. If the data to be read is currently stored in the transaction DB of the memory unit 166, the process proceeds to step P504. On the other hand, if the data to be read is not currently stored in the transaction DB of the memory unit 166, the process proceeds to step P505.

[0085] If the data to be read is currently stored in the transaction DB of the memory unit 166, the data to be read is currently being imported, so in step P504, the reading management unit 172 waits for a certain period of time until the transaction is completed and the data to be read is deleted from the transaction DB.

[0086] Next, in step P505, the read management unit 172 identifies, from among the sets of replica servers in the metadata DB (e.g., the metadata DB 2300 shown in FIG. 6) stored in the memory unit 166, a set of latest replica servers whose version of the data to be read identified in step P502 satisfies the freshness criterion. As described above, the freshness criterion here is a criterion for evaluating the freshness of data stored in a replica server, and may be, for example, information that specifies the version of a particular piece of data. If the version of data stored in a replica server is newer than the version specified in the freshness criterion, the replica server is deemed to satisfy the freshness criterion, and if the version of data stored in a replica server is older than the version specified in the freshness criterion, the replica server is deemed not to satisfy the freshness criterion. In one embodiment, the version specified in the freshness criterion may be set to the version of the data to be read that is stored in the primary server or the secondary server.

[0087] Next, in step P506, the read manager 172 judges whether or not a set of latest replica servers that meet the recency criterion was identified in step P505. If a set of latest replica servers that meet the recency criterion was identified in step P505 (i.e., there is a latest replica server that meets the recency criterion), the process proceeds to step P507. On the other hand, if a set of latest replica servers that meets the recency criterion was not identified in step P505 (i.e., there is no latest replica server that meets the recency criterion), the process proceeds to step P508.

[0088] Next, in step P507, the read management unit 172 identifies a target replica server that satisfies the predetermined access criteria from the set of latest replica servers identified in step P505, and forwards the read request received in step P501 to the identified target replica server. The access criteria here are criteria for determining a replica server that can efficiently provide the read target data requested in the read request, and may specify the distance from the user terminal 186 or the estimated response time. For example, the read management unit 172 may specify a replica server that is installed within a predetermined distance from the user terminal that transmitted the read request received in step P501 (i.e., a server close to the user terminal 186) or a replica server that can respond within a predetermined time as a target replica server that satisfies the access criteria. The details of the process for identifying the target replica server will be described with reference to FIG. 7, and therefore will not be described here.

[0089] At step P508, if a set of up-to-date replica servers satisfying the freshness criterion could not be identified at step P505, the read manager 172 forwards the read request received at step P501 to a secondary server. This is because the secondary servers are more likely to contain the most up-to-date version of the data being read, since it is updated directly from the primary server.

[0090] Next, at step P509, the replica server or secondary server that has received the read request from the read manager 172 sends a response including the data to be read that is specified in the read request to the user terminal.

[0091] Next, a data flow in the reading management process according to an embodiment of the present disclosure will be described with reference to FIG.

[0092] FIG. 6 is a diagram illustrating an example of a data flow in a reading management process according to an embodiment of the present disclosure.

[0093] First, the user terminal 186 transmits a read request 502 requesting data to be read to the data management device 160. In one embodiment, the read request 502 may be a GET request using a REST API, requesting writing of the data to be read, for example, "user_id:5" and "Order_id:100".

[0094] The read management unit 172 (not shown in FIG. 6) of the data management device 160 that receives the read request 502 identifies the replica server and table name (save destination) that stores the read target data requested by the read request 502. The read management unit 172 also determines whether the read target data requested by the read request 502 is stored in the transaction DBT 2100 of the storage unit 166 of the data management device 160. If the read target data is currently stored in the transaction DBT 2100 of the storage unit 166, the read target data is currently being imported, so the read management unit 172 waits for a certain period of time until the transaction is completed and the read target data is deleted from the transaction DB.

[0095] As an example, as shown in FIG. 6, the data to be read requested by the read request 502, "user_id:5" and "Order_id:100", are stored in the transaction content (In_Transaction) column of the transaction DBT2100, so the read management unit 172 waits for a certain period of time until the transaction is completed and the data to be read is deleted from the transaction DB.

[0096] Next, the read management unit 172 identifies a set of the latest replica servers that meet the recency criteria by referring to the metadata DBT2300 and the server DBT2200. As an example, in the metadata DBT2300, the primary server 178 corresponding to the server ID "10H4334", the secondary server 180 corresponding to the server ID "69F432A", and the replica server 182 corresponding to the server ID "701H4920" have the latest version of the data to be read, and the recency is "Y", so the read management unit 172 identifies the primary server 178, the secondary server 180, and the replica server 182 as a set of the latest replica servers that meet the recency criteria. On the other hand, replica server 184 corresponding to server ID "60AA82O" does not have the latest version of the data to be read due to a malfunction, delay, communication failure, etc., and its recency is "N", so it is not included in the set of latest replica servers.

[0097] Next, the read manager 172 identifies a target replica server that satisfies a predetermined access criterion from the identified set of latest replica servers, and transfers the read request 504 received from the user terminal 186 to the target replica server. As an example, from among the primary server 178, the secondary server 180 and the replica server 182 included in the set of up-to-date replica servers that meet the recency criteria, if the replica server 182 meets a predetermined access criterion (e.g., the replica server 182 is closest to the user terminal 186 or can respond within a predetermined time), the read manager 172 may forward the read request 504 to the replica server 182.

[0098] Next, the replica server (for example, replica server 182 ) that receives the read request 504 transferred from the read management unit 172 transmits a response 506 including the data to be read that the read request 504 requests to the user terminal 186 . The user terminal 186 that receives this response 506 stores information about the replica server that satisfies the access criteria in a private cache T2000 of the user terminal 186. As shown in Fig. 6, this private cache T2000 may include information about a server ID (Server_ID) T2010 that uniquely identifies a server that satisfies the access criteria, a server IP (Server_IP) T2020 that indicates the IP address of the server, and a proximity rank (Proximity_Rank) T2030 that indicates the distance of the server from the user terminal 186. In this way, by storing information about replica servers that satisfy the access criteria in the private cache T2000 of the user terminal 186, read requests generated from the user terminal 186 thereafter can be efficiently forwarded to replica servers that satisfy the access criteria.

[0099] According to the read management process by the data management system 200 described with reference to FIG. 6, by referring to the metadata DB including metadata indicating the version of data stored in each server included in the data management system 200, when responding to a read request from a user terminal, it is possible to identify a target replica server that satisfies access criteria based on communication time, distance, etc. from among the replica servers storing the latest version of the data to be read.

[0100] Next, with reference to FIG. 7, a flow of an access evaluation process according to an embodiment of the present disclosure will be described.

[0101] 7 is a diagram showing an example of the flow of an access evaluation process 700 according to an embodiment of the present disclosure. The access evaluation process 700 shown in FIG. 7 is a process for identifying a target replica server that satisfies an access criterion, and is performed by the replica identification unit 174 of the read management unit 172. As described above, the access criteria here are criteria for determining a replica server that can efficiently provide the read target data requested in the read request, and may be information specifying the distance from the user terminal or the response time. It should be noted that the access evaluation process 700 shown in FIG. 7 substantially corresponds to the read management process 500 shown in FIG.

[0102] First, in step P701, the reading management unit 172 of the data management device 160 receives a reading request from the user terminal 186. Here, the reading management unit 172 may receive a so-called GET request as the reading request. Note that step P701 substantially corresponds to step P501 in the reading management process 500 shown in FIG. 5 described above.

[0103] Next, in step P702, the read manager 172 extracts from the read request received in step P701 the IP address of the user terminal 186. In one embodiment, the read manager 172 may extract this IP address from metadata sent together with the read request.

[0104] Next, in step P703, the reading management unit 172 determines the type of the IP address of the user terminal 186 extracted in step P702. More specifically, here, the reading management unit 172 may determine whether the IP address of the user terminal 186 extracted in step P702 is a private IP address or a public IP address. A public IP address is an IP address used as a unique identifier on the Internet, and a private IP address is an IP address used within a private network. The determination of whether the IP address of the user terminal 186 extracted in step P702 is a private IP address or a public IP address may be made based on the value of the IP address and the IP address range of the network to which the IP address belongs. If the IP address of the user terminal 186 extracted in step P702 is a public IP address, the process proceeds to step P704. On the other hand, if the IP address of the user terminal 186 extracted in step P702 is a private IP address, the process proceeds to step P705.

[0105] If the IP address of the user terminal 186 extracted in step P702 is a public IP address, then in step P704, the reading management unit 172 determines a user location indicating the geographical location of the user terminal 186 based on the public IP address of the user terminal 186 extracted in step P702. Here, the reading management unit 172 may compare the extracted IP address with a table or database indicating the correspondence between public IP addresses and regions, and determine the coordinates or the like that define the geographical location corresponding to the public IP address as the user location.

[0106] Next, in step P706, the read management unit 172 uses the user location determined in step P704 to calculate the distance from the user location for each replica server included in the set of latest replica servers determined to satisfy the recency criterion. Here, the read management unit 172 may calculate the distance from the user location to each replica server based on, for example, a map or GPS (Global Positioning System) information.

[0107] If the IP address of the user terminal 186 extracted in step P702 is a private IP address, then in step P705, the read management unit 172 sends a small data packet requesting a response to each replica server included in the set of latest replica servers that have been determined to satisfy the recency criterion.

[0108] Next, at step P707, the read management section 172 calculates and records the time it takes for a response to arrive from each replica server to which the small amount of data packet was transmitted at step P705.

[0109] Next, in step P708, the read management unit 172 determines which replica servers meet the access criteria based on the distance from the user's location to each replica server calculated in step P706, or the time it takes for a response from each replica server to arrive recorded in step P707, and stores information about the determined replica servers in a private cache of the user terminal 186. As an example, if the IP address of the user terminal 186 extracted in step P702 is a public IP address, the read management unit 172 may determine that the replica server that is the closest to the user terminal 186 from the set of latest replica servers that have been determined to satisfy the recency criterion is the target replica server that satisfies the access criterion. As another example, if the IP address of the user terminal 186 extracted in step P702 is a private IP address, the read management unit 172 may determine that the replica server that responded to the data packet the fastest from the set of latest replica servers determined to satisfy the recency criterion is the target replica server that satisfies the access criterion.

[0110] Next, in step P709, the read management unit 172 establishes a so-called sticky session between the target replica server and the user terminal 186 so that read requests from the user terminal 186 are preferentially sent to the target replica server while the session continues.

[0111] Next, at step P710, if the read manager 172 detects that the target replica server no longer satisfies the access criteria due to a delay, a malfunction, a communication failure, or the like, the process proceeds to step P711.

[0112] Next, in step P711, the read manager 172 deletes the information about the target replica server from the private cache of the user terminal 186. After that, the process returns to step P702, and the subsequent steps are performed to determine a new target replica server.

[0113] According to the access evaluation process 700 described with reference to FIG. 7, replica servers that are close to the user terminal or have a fast response time are determined to be target replica servers that satisfy the access criteria, making it possible to provide a quick and efficient response to a read request from the user terminal.

[0114] Next, the GUI of the data management device according to the embodiment of the present disclosure will be described with reference to FIG.

[0115] 8 is a diagram illustrating an example of a GUI 187 of a data management device according to an embodiment of the present disclosure. As illustrated in FIG. 8, the GUI 187 may include a server list 802, a server type 804, a recency 806, metadata 808, a server search 810, and a server addition 812. The server list 802 is a GUI element that shows each server included in the data management system 200 . Server type 804 is a GUI element that indicates the type of each server included in data management system 200. For example, server type 804 may indicate whether a server is a primary server, a secondary server, or a replica server. Recency 806 is a GUI element that indicates whether each server included in data management system 200 meets the recency criteria. For example, a server displayed as "latest" meets the recency criteria and stores the latest data, and a server displayed as "not latest" does not meet the recency criteria and stores an older version of data.

[0116] By pressing Metadata 808, the user can see the metadata about a particular server. By pressing server search 810, the user can search for a specific server among the servers included in the data management system 200 based on attributes such as the server ID and the server type. By pressing add server 812 , a new server can be prepared and implemented in the data management system 200 .

[0117] As described above, in the data management means according to the embodiment of the present disclosure, when a write request is received in the data management device, the data management device writes the write target data specified in the write request to its own storage unit, and then transfers the write request to the primary server. The primary server writes the write target data to each replica server included in the set of replica servers. When writing the write target data, each replica server stores metadata indicating the version of the written write target data, etc., in a metadata DB stored in the data management device.

[0118] In addition, when a read request is received by the data management device, the data management device identifies the data to be read specified in the read request, and by referring to the metadata DB, identifies a target replica server that satisfies access criteria based on communication time, distance, etc. from among the replica servers that store the latest version of the data to be read, and transfers the read request to the identified target replica server.

[0119] In the data management device, by maintaining a metadata DB that manages the status of each replica server and the version of the data to be written, it is possible to easily identify the replica server that stores the latest version of any data. Therefore, when a read request is received from a user terminal, this metadata DB can be referenced to identify a target replica server that satisfies access criteria based on communication time, distance, etc. from among the replica servers that store the latest version of the data to be read, and the read request can be forwarded to the target replica server.

[0120] In this way, in a distributed computing environment to which the data management system according to the embodiment of the present disclosure is applied, a replica server that has the latest version of the data to be read that is requested by the read request and can provide a quick response is preferentially selected as a replica server that responds to a read request from a user terminal. This prevents old data from being provided in response to a read request, and reduces the time and computing resources required for a response to be sent to a user.

[0121] This makes it possible to provide a data management means for improving data consistency while maintaining high availability in a distributed computing environment.

[0122] As described above, the data management means according to the embodiments of the present disclosure may be implemented, for example, as an apparatus having a dedicated hardware configuration, a system having multiple servers, or a program executed on a computer, but is not limited thereto, and may include the following aspects.

[0123] (Aspect 1) A data management method implemented in a data management system, comprising: In the data management system, A user terminal used by a user; A data management device; The main server, a set of replica servers including a plurality of replica servers connected via a communication network; The data management device includes: A processor, a memory, and a storage unit are provided, The storage unit stores a metadata database; The memory includes: receiving a write request; identifying data to be written that is specified in the write request; writing the specified write target data to the storage unit; forwarding the write request to the primary server; sending a command to the primary server to cause the primary server to forward the write request to each replica server in the set of replica servers; receiving metadata from each replica server included in the set of replica servers, the metadata including at least a server ID for identifying the replica server, a geographic location of the replica server, a transaction ID for identifying the data to be written, a destination for the data to be written, and a date and time when the data to be written is written; storing the received metadata and version information indicating a version of data stored in each of the replica servers in the metadata database; receiving a read request from the user terminal; identifying data to be read that is specified in the read request; identifying, from among the set of replica servers in the metadata database, a set of up-to-date replica servers in which the version of the data to be read satisfies a predetermined freshness criterion; identifying a target replica server from the set of latest replica servers that satisfies a predetermined access criterion; forwarding the read request to the identified target replica server; The data management method according to claim 1, further comprising:

[0124] Although the embodiment of the present invention has been described above, the present invention is not limited to the above-described embodiment, and various modifications are possible without departing from the gist of the present invention. [Explanation of symbols]

[0125] 160 Data management device 161 Client Applications 162 Memory 163 Write Request 164 ROM 165 synchronous update 166 Memory section 168 Write Management Unit 169, 173 Acknowledgement message ACK 170 Metadata Management Department 171 Asynchronous Write 172 Loading Management Unit 174 Replica Identification Section 175, 177, 179 Asynchronous updates 176 Request Forwarder 178 Major Servers 180 Secondary Server 181 Read Request 182, 184 replica servers 185 responses 186 User Terminals 187 GUI 200 Data Management System

Claims

1. A user terminal used by a user; A data management device; The main server, A data management system in which a set of replica servers including a plurality of replica servers is connected via a communication network, The data management device includes: A processor, a memory, and a storage unit are provided, The memory includes: a write management unit that receives a write request, identifies data to be written that is specified in the write request, writes the identified data to be written to the storage unit, and transfers the write request to the primary server; a read management unit that receives a read request from the user terminal, identifies read target data specified in the read request, identifies a target replica server from the set of replica servers that satisfies a predetermined recency criterion for the read target data and also satisfies a predetermined access criterion, and transfers the read request to the identified target replica server; and processing instructions for causing the processor to function as The primary server is Sending the data to be written to each replica server included in the set of replica servers; A data management system comprising:

2. A first replica server in the set of replica servers comprises: when the write target data received from the main server is written, transmitting metadata to the data management device, the metadata including at least a server ID for identifying the first replica server, a geographical location of the first replica server, a transaction ID for identifying the write target data, a write destination of the write target data, and a date and time when the write target data was written; 2. The data management system according to claim 1.

3. The storage unit is Stores the metadata database, The memory of the data management device includes: a metadata management unit that receives the metadata transmitted from each replica server included in the set of replica servers, and stores the received metadata and version information indicating a version of data stored in each replica server in the metadata database; The data management system according to claim 2 , wherein the processor functions as:

4. The write management unit is When the write request is received, forwarding the write request to the primary server; If there is no response from the primary server within a specified time, identifying a second replica server in the metadata database from among the set of replica servers whose version satisfies the freshness criterion, promoting the identified second replica server to the primary server, and forwarding the write request to the promoted primary server; 4. The data management system according to claim 3.

5. The reading management unit is When the read request is received, identifying, from among the set of replica servers in the metadata database, a set of up-to-date replica servers in which the version of the data to be read satisfies the freshness criterion; identifying a target replica server that satisfies an access criterion from among the set of up-to-date replica servers; 5. The data management system according to claim 4.

6. The reading management unit is if it is determined that the version of the data to be read stored in a particular replica server is newer than a predetermined version, it is determined that the replica server satisfies the freshness criterion; 6. The data management system according to claim 5.

7. The reading management unit is When the read request is received, Extracting an IP address of the user terminal from the read request; Determine whether the extracted IP address is a private IP or a public IP; If the extracted IP address is a private IP, sending a data packet to each of the set of up-to-date replica servers; determining that a replica server from which a response to the data packet arrives within a predetermined time period satisfies the access criteria; If the extracted IP address is a public IP, determining a user location indicating a geographic location of the user terminal that sent the read request based on the IP address; calculating a distance from the user location for each of the set of up-to-date replica servers using geographic location information of the replica servers stored in the metadata database; determining that a replica server located within a predetermined distance from the calculated user location satisfies the access criterion; 7. The data management system according to claim 6.

8. A data management program executed in a data management system, In the data management system, A user terminal used by a user; A data management device; The main server, a set of replica servers including a plurality of replica servers connected via a communication network; The data management device includes: A processor, a memory, and a storage unit are provided, The storage unit stores a metadata database; The memory includes: receiving a write request; identifying data to be written that is specified in the write request; writing the specified write target data to the storage unit; forwarding the write request to the primary server; sending a command to the primary server to cause the primary server to forward the write request to each replica server in the set of replica servers; receiving metadata from each replica server included in the set of replica servers, the metadata including at least a server ID for identifying the replica server, a geographic location of the replica server, a transaction ID for identifying the data to be written, a destination for the data to be written, and a date and time when the data to be written is written; storing the received metadata and version information indicating a version of data stored in each of the replica servers in the metadata database; receiving a read request from the user terminal; identifying data to be read that is specified in the read request; identifying, from among the set of replica servers in the metadata database, a set of up-to-date replica servers in which the version of the data to be read satisfies a predetermined freshness criterion; identifying a target replica server from the set of latest replica servers that satisfies a predetermined access criterion; forwarding the read request to the identified target replica server; A data management program comprising a processing instruction for causing the processor to execute the above.

Images