Method and system for eventual consistency of data types in a geographically distributed active-active database system

Abstract

A method and system are provided for eventual consistency of data types in a geographically distributed active-active database system. A multi-type conflict-free replicated data type (CRDT) structure is provided. The multi-type CRDT structure and method enable a geographically distributed active-active database system to reach eventual consistency with respect to data type conflicts by supporting multiple incompatible data types.

Description

[Technical Field]

[0001] The present disclosure relates to systems and methods for data management in active-active architectures, including systems and methods for cross-domain active-active data replication between services in cloud computing. [Background technology]

[0002] An active-active network architecture is a data resilience architecture that distributes database information across multiple data centers through independent, geographically distributed clusters and nodes. It is a network of separate processing nodes, each with a replica of the database (or cache), where all nodes can participate in a common application, ensuring local low latency where each region can run independently.

[0003] However, simultaneous updates to multiple replicas of the same data in an active-active system without coordination between the computers hosting the replicated databases can result in inconsistencies between the replicas. Restoring eventual consistency and data integrity when there are conflicts between updates may require some or all of the updates to be fully or partially rejected.

[0004] Eventual consistency is a consistency model used in distributed computing to achieve high availability by informally guaranteeing that, in the absence of new updates to a given data item, all accesses to that item will eventually return the same value at all replicas. Eventual consistency, also known as optimistic replication, is deployed in distributed systems, originating from early mobile computing projects. Systems that achieve eventual consistency are often said to have converged or to have achieved replica convergence.

[0005] Much of distributed computing focuses on the problem of how to prevent concurrent updates to replicated data in a database or cache. Another possible approach is optimistic replication, where all concurrent updates to the database or cache may be allowed to occur, potentially resulting in inconsistencies, which are later merged or "resolved." In this approach, consistency between replicas can eventually be re-established through a "merging" of the different replicas.

[0006] A distributed active-active database system may require live, fast, bidirectional data replication between domains. Two parts of the system may attempt to create the same data item with different types, causing a conflict. If a communication link is temporarily blocked (e.g., during a network partition), multiple conflicts for the same data may occur. However, all data items must remain available to all parts of the database system at all times. Data in all domains must eventually be consistent after replication. Conflict identification and resolution for data modifications must be fast.

[0007] A conflict-free replicated data type (CRDT) is a type of data structure that enables conflict resolution between database or cache operations, including write commands, delete commands, and update commands, when replicating data and metadata across multiple service instances. CRDT data structures may be implemented using CRDT modules (also called CRDT agents) that add to the functionality of existing data stores. CRDT modules may be loaded and initialized when a cache service instance is started.

[0008] An operation-based CRDT may only send update operations, which can be small. Operation-based CRDTs make strong assumptions about the reliability of communication and require guarantees from the communication middleware, namely that operations are not dropped or duplicated when sent to other replicas, and that they are delivered in causal order. Therefore, the communication infrastructure must guarantee that all operations on a replica are delivered to other replicas in causal order, without duplication.

[0009] State-based CRDTs are called convergent replicated data types. State-based CRDTs are often simpler to design and implement. Their drawback is that the entire state of every CRDT must eventually be transmitted to every other replica, which can be costly, both in terms of infrastructure required and time required.

[0010] Cloud applications have a high demand for geographically distributed active-active databases to provide global, reliable, and high-performance services. When two regions in a geographically distributed active-active database system create the same data item with different types, a data type conflict resolution mechanism is required to ensure eventual consistency between the regions. Otherwise, application developers need to modify business logic and follow specific usage patterns to avoid data type conflicts.

[0011] Some traditional CRDTs avoid conflicts by requiring system designers to take specific steps (specific usage patterns) to ensure that conflicts never arise. Database providers must document the behaviors and constraints that resolve data type conflicts in their user guides, so applications must adapt to them.

[0012] Some traditional CRDTs handle data of individual types, restricting eventual consistency to a single instance of a single type. Some other traditional CRDTs support multiple data types by using different namespaces. However, using namespaces to separate data items by type can force developers to create and manage multiple namespaces. Some traditional CRDTs make strong assumptions about the reliability of communication.

[0013] Therefore, there is a need for a method and system for implementing a conflict-free replicated data type structure that can support multiple incompatible data types and ensure data consistency in the presence of mixed data types. Such a CRDT structure may avoid or mitigate one or more limitations of the prior art.

[0014] This background information is provided to identify information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should it be construed, that any of the preceding information constitutes prior art against the present invention. Summary of the Invention [Means for solving the problem]

[0015] The present disclosure is directed to a method and system for eventual consistency of data types in a geographically distributed active-active database system. A multi-type conflict-free replicated data type (CRDT) structure is provided. The multi-type CRDT structure and method enable a geographically distributed active-active database system to reach eventual consistency with respect to data type conflicts by supporting multiple incompatible data types. The multi-type CRDT structure handles multiple types simultaneously without separating instances of various CRDT data types and assumes only ordered eventual delivery over individual point-to-point channels.

[0016] According to one aspect, a method is provided for conflict-free replicated data type management in a database system including multiple data center nodes. The method includes receiving, by a message processing function associated with the data center node, a request message defining a request related to a data item, the data item being defined without a data type or with one or more data types, and a priority associated with the one or more data types. The method further includes performing, by the message processing function, one or more actions based on an evaluation of the request.

[0017] In some embodiments, the performing step includes determining, by the message processing function, whether the request includes a get-current-type request associated with the data item. Upon determining that the data item has a data type based at least in part on the priority, the performing step further includes reporting, by the message processing function, the data type associated with the data item. Upon determining that the data item does not have a data type, the performing step further includes reporting, by the message processing function, that the data item does not have a data type.

[0018] In some embodiments, the performing step includes determining, by a message processing function, whether the request includes a clear request associated with the data item. Upon determining that the request is a clear request, the performing step includes clearing, by the message processing function, one or more values ​​associated with the data item and clearing, by the message processing function, one or more attributes associated with the data item. Upon determining that the request is a clear request, the performing step further includes building, by the message processing function, a merge clear message based on the clearing of the one or more values ​​and the one or more attributes, and sending, by the message processing function, the merge clear request associated with the data item to all other data center nodes in the database system.

[0019] In some embodiments, if it is determined that the request is not a clear request, the performing step includes determining, by a message processing function, whether the data item has a data type. If it is determined that the data item does not have a data type and the request is meaningful, the performing step further includes applying, by the message processing function, changes to values ​​associated with the data item defined by the request, and applying, by the message processing function, changes to attributes associated with the data item defined by the request. If it is determined that the data item does not have a data type and the request is meaningful, the performing step further includes sending, by the message processing function, a merge request associated with the data item to all other data center nodes in the database system.

[0020] In some embodiments, upon determining that the data item has a data type based at least in part on the priority and that the current data type associated with the data item matches the data type defined in the request, the performing step includes applying, by a message processing function, changes to values ​​associated with the data item defined by the request, and applying, by the message processing function, changes to attributes associated with the data item defined by the request. Upon determining that the data item has a data type and that the current data type associated with the data item matches the data type defined in the request, the performing step further includes sending, by the message processing function, a merge request associated with the data item to all other data center nodes in the database system.

[0021] In some embodiments, if the data item has a data type based at least in part on the priority, and if it is determined that the current data type associated with the data item is different from the data type defined in the request, the performing step includes rejecting the request, by the message processing function.

[0022] In some embodiments, the request message is associated with a read request. In some embodiments, a data item can include multiple values ​​and multiple data types, and the data types are not compatible.

[0023] According to one aspect, there is provided a data center node associated with a database system, the data center node including a processor and a memory having machine-executable instructions stored thereon, the machine-executable instructions, when executed by the processor, configuring the data center node to perform one or more of the above-defined methods.

[0024] According to one aspect, there is provided a database system including a plurality of database center nodes, each of which includes a processor and a memory having machine-executable instructions stored thereon, the machine-executable instructions, when executed by the processor, configuring the particular data center node to perform one or more of the above-defined methods.

[0025] According to one aspect, there is provided a computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform one or more of the methods defined above.

[0026] The embodiments have been described above in conjunction with aspects of the present disclosure in which they may be implemented. Those skilled in the art will understand that an embodiment may be implemented in conjunction with the aspect used in the description, but may also be implemented using other embodiments of that aspect. When embodiments are mutually exclusive or otherwise incompatible with one another, this will be apparent to those skilled in the art. Some embodiments may be described in relation to one aspect, but may also be applicable to other aspects, as will be apparent to those skilled in the art.

[0027] Further features and advantages of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0028] [Figure 1] FIG. 1 is a block diagram of a geographically distributed database system, according to an embodiment. [Figure 2] FIG. 1 is a block timeline diagram illustrating an example of a data type conflict caused by geographically separated databases in Asia and Africa creating the same data item with different types and different values, according to an embodiment. [Figure 3] FIG. 1 illustrates a logic diagram for resolving data type conflicts, according to an embodiment. [Figure 4] FIG. 10 is a block timeline diagram illustrating an example of a data type conflict being resolved after a CLEAR operation is delivered, according to an embodiment. [Figure 5]FIG. 10 is a block timeline diagram illustrating an example of acausal delivery leading to a valueless attribute, according to an embodiment. [Figure 6] FIG. 1 is a block diagram of an electronic device, according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0029] Embodiments of the present disclosure provide a method and system for eventual consistency of data types in a geographically distributed active-active database system. A multi-type conflict-free replicated data type (CRDT) structure is provided. The multi-type CRDT structure and method enable a geographically distributed active-active database system to reach eventual consistency with respect to data type conflicts by supporting multiple incompatible data types. The multi-type CRDT structure handles multiple types simultaneously without separating instances of various CRDT data types and assumes only ordered, eventual delivery over individual point-to-point channels.

[0030] FIG. 1 illustrates a block diagram of a geographically distributed database system, according to an embodiment. The distributed database system includes multiple geographically separated data center nodes, including gNB Asia 3, gNB Europe 2, and gNB Africa 1. While the data center nodes are shown as gNBs, other types of data center node configurations may be used in some embodiments, and the data center nodes generally provide access to communications and other services via a communications interface. The geographically separated data center nodes gNB Asia 3, gNB Europe 2, and gNB Africa 1 are communicatively connected via a communications network 5, which provides a means for coordinating the replication of data across the geographically separated data center nodes associated with the geographically distributed database system. Customers, e.g., user equipment (UE), within a particular geographic region can use the communications network (not shown) to perform tasks such as interacting with associated geographic data center nodes. For example, customer 36 communicates with gNB Asia 3, customer 26 communicates with gNB Europe 2, and customer 16 communicates with gNB Africa 1.

[0031] It is recognized that cloud applications may have high demands on geographically distributed active-active databases to provide global, reliable, and high-performance services. Therefore, when two domains of a geographically distributed active-active database system create the same data item with different types, a data type conflict resolution mechanism is needed to ensure eventual consistency between the domains.

[0032] 2 is a block timeline diagram illustrating an example of a data type conflict caused by geographically separated databases in Asia and Africa creating the same data item with different types and different values, according to an embodiment. In FIG. 2, the block timeline diagram illustrates an example of a data type conflict caused by a client of data center node 1 in Africa and a client of data center node 3 in Asia. Data center nodes 1-3 host replicas of the databases. For example, data center node 2 in Europe maintains database 15. Data center nodes in Asia and Africa also maintain replicas of database 15. Data center node 1 in Africa creates data item 11 with the data value set to "{a, b}" and the data type defined as "set." Data center node 3 in Asia creates the same data item (marked as data item 12) with the data value set to "hello" and the data type defined as "string." African datacenter node 1 attempts to communicate with European datacenter node 2, where it replicates its data item 11 as instance 13, and Asian datacenter node 3 replicates its data item 12 in European datacenter node 2 as instance 14. Instances 13 and 14 may be created in database 15 at the same time or at different times. If a data item in European datacenter node database replica 15 has multiple data types, database replica 15 needs a way to determine which data type to report to clients. If such data type conflicts are not resolved quickly and efficiently, customer complaints may result.

[0033] This disclosure provides a method and system for achieving eventually consistent data representation across all data centers hosting database replicas. A method for achieving eventually consistent data representation is a multi-type CRDT. The multi-type CRDT method and system facilitates a systematic approach to resolving data type conflicts instead of managing numerous instances of data types that may be added and removed from a map, such as a key-value store distributed across a wide geographic region. The multi-type CRDT method may make it easy to add new data types to a database without restricting customers to specific usage patterns (without having to modify business logic). Consistency may be achieved during READ operations by implementing a type conflict resolution procedure.

[0034] According to some embodiments of the present disclosure, an instance of a multitype CRDT structure is called a data item. Externally, a multitype CRDT structure may or may not have a data type. At different times, a multitype CRDT structure may have different external data types. Internally, a multitype CRDT structure may have no data type or may have multiple data types. Thus, a multitype CRDT structure may have two or more internal data types at the same time. Also, the list of internal data types associated with a data item may change over time.

[0035] According to an embodiment, the internal CRDT data types are arranged in order of priority. If a data item (a multi-type CRDT structure) has two or more internal data types, one conflict resolution may be performed each time the data item is accessed. For example, in one embodiment of a multi-type CRDT structure, the internal CRDT data types may be strings and counters, with strings having priority over counters. In another embodiment, the internal CRDT data types may be sets, lists, and maps, with the priority defined as maps having priority over lists and sets, and lists having priority over sets.

[0036] Depending on the embodiment, externally, a multitype CRDT structure may have attributes or no attributes. At different times, a multitype CRDT structure may have different external attributes. Internally, a multitype CRDT structure may have no attributes or multiple attributes. Thus, a multitype CRDT structure may have two or more internal attributes at the same time. The list of internal attributes associated with a data item may change over time. Multitype CRDT structure attributes are independent of its data type. Attributes of a multitype CRDT structure may have an attribute type.

[0037] According to this disclosure, a multitype CRDT structure may have no internal data values, no internal data types, and no internal attributes. Such a multitype CRDT structure is described as "empty." An empty multitype CRDT structure may have no external data values, no external data types, and no external attributes.

[0038] In some embodiments of the present disclosure, if a data item (multitype CRDT structure) has at least one internal data value that has a data type and no attributes, the multitype CRDT structure may have an external data value.

[0039] In some embodiments, a multi-type CRDT structure may have a data type only if it has a data value.

[0040] In this disclosure, a local client is defined as a client that is geographically close to a particular datacenter node, for example, client 16 to datacenter node 1 in Africa. In this case, datacenter node 1 in Africa is the local datacenter.

[0041] In some embodiments, the disclosed method may define a set of internal data types. The set of internal date types of the multi-type CRDT structure may be arranged in a sequential hierarchy (e.g., priority order). For each pair of different internal date types, one internal data type takes precedence over the other. Additionally, the method may determine a set of internal attributes (which may possibly be empty). Each internal attribute may have at least one attribute type.

[0042] According to an embodiment, each data type (e.g., both internal and external data types) in the multitype CRDT structure may be accompanied by a set of local operations that return output information to the local client and information that may be sent to all remote replicas of a particular database. The information communicated to the remote replica may specify a remote operation to be performed on instances with a matching data type (or matching data types) at each remote replica. In the case of read-only local operations, information about any changes may not be sent to the remote replica. According to an embodiment, a requirement for instances in a remote replica of a data item is that the remote replica data item has a multitype CRDT structure. For example, an improvement provided by a multitype CRDT structure is that both instances of a data item (i.e., a data item residing in a first database and a replica of that data item in another database) ultimately have the same data type, even if the remote instances of the data item have inconsistent data types when information (e.g., received from another data center regarding a particular data item) is communicated.

[0043] According to an embodiment, a message processing function may facilitate communication of the generated information to local clients and remote replicas of the local database. For example, a local operation CLEAR may place a local instance of a data item (e.g., a multitype CRDT structure) in an empty state. The disclosed method may define a read-only operation defined as EMPTY. When a multitype CRDT structure is in an empty state and an EMPTY operation is performed on such a structure, the EMPTY operation may return information indicating a "true" state.

[0044] According to embodiments, the message processing functionality can be integrated with a set of local operations to provide the desired operations and functionality according to various embodiments of the present application. The message processing functionality may be configured as a function, such as an application, software, software / firmware, or other configuration, operating on each of the data center nodes to provide the desired functionality. In some embodiments, the message processing functionality may be configured as an application program interface (API).

[0045] According to an embodiment, a method for resolving data type conflicts using the multi-type CRDT structure defined above is discussed with respect to Figure 3. Figure 3 is a logic diagram for resolving data type conflicts according to an embodiment.

[0046] In some embodiments, a local client may send a request to a local data center reviewing a multitype CRDT structure (data item-d) 301. The request may indicate a GET-CURRENT-TYPE operation 302. If the multitype CRDT structure does not currently have a data type 303, the output information communicated to the local client may include an indication that the data item (multitype CRDT structure) does not have a data type 305. If the multitype CRDT structure does have a current data type, the output information communicated to the local client may provide an indication of the current data type 304.

[0047] According to an embodiment, the data type, e.g., the current data type of a data item, may be determined based on the priority associated with the data types associated with the multi-type CRDT structure, which is discussed in more detail elsewhere in this specification.

[0048] In some embodiments, a local client may send a request to a local data center reviewing a multi-type CRDT structure (data item-d), and the request may indicate a CLEAR operation. If the request is a CLEAR operation at 315, the CLEAR operation applied to the reviewed multi-type CRDT structure may invalidate each of the data values ​​316. A MERGE-CLEAR message may be generated for all data values ​​invalidated or cleared by the CLEAR operation.

[0049] According to an embodiment, a CLEAR operation applied to the multi-type CRDT structure considered by the request may invalidate each of the attributes 317. A MERGE-CLEAR message may be generated for all attributes invalidated by the CLEAR operation. Upon completion of this step, all of the attributes and data values ​​may report that they are empty. Furthermore, in this step, the local replica (the considered multi-type CRDT structure in the local database) may have no data types.

[0050] According to an embodiment, the method may also include a step 318 of generating or constructing a final MERGE-CLEAR message. The final MERGE-CLEAR message may include all MERGE-CLEAR messages generated after the CLEAR operation when applying this CLEAR operation to the considered multi-type CRDT structure. The final MERGE-CLEAR message may consequently be communicated or transmitted to all remote replicas of the considered multi-type CRDT structure (319).

[0051] In some embodiments, a local client may send a request to a local data center reviewing a multi-type CRDT structure (data item-d). At 314, the reviewed multi-type CRDT structure may not have a data type, but the request may indicate a modification that may have meaning, i.e., a modification of a data item; an attribute change can have meaning, for example, if the attribute reflects a time-to-live (TTL) associated with the data item, even though the data item does not have an associated value.

[0052] According to an embodiment, the method may further include steps of validating the request and applying the requested modifications to the considered multi-type CRDT structure 313, 312. Furthermore, the method may include steps of generating multiple MERGE messages after the requested modifications have been applied to the considered multi-type CRDT structure. For example, the requested changes may be applied to internal data values ​​313 or to corresponding attributes 312.

[0053] According to an embodiment, the method may also include a step of generating a final MERGE message. The final MERGE message may include all MERGE messages generated after the requested modifications are applied to the considered multi-type CRDT structure. The final MERGE message may then be communicated or transmitted to all remote replicas of the considered multi-type CRDT structure (311).

[0054] In some embodiments of the method, a local client may send a request to a local data center reviewing a multitype CRDT structure (data item-d). The reviewed multitype CRDT structure may have a current data type. The request may include an indication of a data type that matches the current data type 306. The request may also indicate modifications to be applied to the reviewed multitype CRDT structure. The method may further include steps 308, 309 of validating the request and applying the requested modifications to the reviewed multitype CRDT structure. For example, the requested changes may be applied to internal data values ​​308 or to corresponding attributes 309.

[0055] According to an embodiment, the method may include generating multiple MERGE messages after the requested modifications are applied to the considered multitype CRDT structure having the current data type. The method may also include generating a final MERGE message. The final MERGE message may include all MERGE messages generated after the requested modifications are applied to the considered multitype CRDT structure having the current data type. The final MERGE message may eventually be communicated or transmitted to all remote replicas of the considered multitype CRDT structure having the current data type (310).

[0056] In some embodiments of the method, a local client may send a request to a local data center that is considering a multi-type CRDT structure (data item-d). The considered multi-type CRDT structure may have a current data type, but the request may have an indication of a data type that does not match the current data type 306. In this case, the request to the local data center that is considering the multi-type CRDT structure is rejected 307.

[0057] In some embodiments of the present application, a multi-type CRDT structure is hosted on a local data center node, and remote replicas of the multi-type CRDT structure are hosted on one or more remote data center nodes. According to embodiments, a message processing function operable on a remote data center node may send a request to the local data center node discussing an action to be taken by the local data center node in relation to the multi-type CRDT structure stored therein. According to embodiments, a message processing function operable on the local data center node may send a request to one or more remote data center nodes discussing an action to be taken by one or more remote data center nodes in relation to the multi-type CRDT structure stored therein.

[0058] In some embodiments, a remote data center node sends a MERGE request for a data item (i.e., the considered multitype CRDT structure) stored in another data center node associated with the database system. In some embodiments, the MERGE request may indicate a MERGE-CLEAR operation. If the request is a MERGE-CLEAR, the application of the MERGE-CLEAR operation may merge each of the sub-messages into the corresponding attribute and option sub-values ​​associated with the considered multitype CRDT structure. Once completed, the local replica (i.e., the considered multitype CRDT structure) in the local data center node may or may not have the data type. If the request is not a MERGE-CLEAR request, the application of the MERGE request is performed, whereby the requested correction is merged into the indicated attribute or option sub-value associated with the request.

[0059] 4 is a block timeline diagram illustrating an example of a data type conflict resolved after a CLEAR operation is distributed, according to an embodiment. African data center node 1 hosts data item 20 with a date type defined as "set" and a data value defined as "{a, b}". Asian data center node 3 hosts the same data item (marked as instance 22) with a data type defined as "string" and a data value set to "hello". Asian data center node 3 contacts European data center node 2 to replicate data item 22, creating instance 21 with type "string" and value "hello". As a result of, or concurrently with, the operation performed by Asian data center node 3, African data center node 1 contacts European data center node 2 to create a replica of data item 20. As a result, European data center node 2 hosts a multi-type CRDT structure 24 with internal date types "set" and "string" and internal data values ​​"{a, b}" and "hello".

[0060] Additionally, the Asian data center node 3 contacts the African data center node 1 to replicate the data item 22 of type "set" and value "{a, b}" at the African data center node 1. As a result, the African data center node 1 hosts a multi-type CRDT structure 23 with internal date types "set" and "string" and internal data values ​​"{a, b}" and "hello".

[0061] According to an embodiment, data type conflicts (such as those found in multi-type CRDT structures 23 and 24) may be resolved by a priority order (eg, sequential hierarchy) applied during or before the commanded READ operation.

[0062] The Asian data center node 3 receives a message 25 from a local client. The message indicates a CLEAR operation. Once the CLEAR operation is verified and executed, the data type and data value of the instance (e.g., data item) 22 are invalidated or cleared. Furthermore, once the CLEAR operation is completed, the message processing function of the Asian data center node 3 generates a message indicating a MERGE-CLEAR operation that is communicated to other data centers that host replicas of the data item 22. The message indicating the MERGE-CLEAR operation is sent to the European and African data center nodes. Upon receiving this message, instances having data types and data values ​​that match the data type "string" and data value "hello" of the data item 22 are invalidated or cleared. As a result, the multi-type CRDT structure 24 (e.g., data item 24) in the European data center node 2 is updated to a new instance 27 having only one data type and only one data value. The multi-type CRDT structure 23 (eg, data item 23) in the African data center node 1 is updated to a new instance 28 having only one data type, and therefore only one data value exists.

[0063] At this point, the data item replicas 26-28 at the three data center nodes 1-3 have reached eventual consistency with the data type "set" and data value "{a, b}".

[0064] 5 is a block timeline diagram illustrating an example of acausal delivery leading to a valueless attribute, according to an embodiment. Asian datacenter node 3 hosts data item 30 with a date type defined as “set” and a data value defined as “{a, b}.” This data item is sent to both European datacenter node 2 and African datacenter node 1; receipt of this data item by European datacenter node 2 will result in the creation of data item instance 31, and receipt of this data item by African datacenter node 1 will result in the creation of data item instance 36. It is important to note the timing difference between the receipt and subsequent creation of the data item instance at European datacenter node 2 and the creation of the data item instance at African datacenter node 1. After receiving data item 31, European datacenter node 2 will MERGES the attribute of this data item that reflects the time-to-live (TTL) associated with the data item to create data item instance 32. The European datacenter node 2 sends a modification request (i.e., a MERGE request to other datacenter nodes (i.e., the European datacenter node 2 and the African datacenter node 1)) to merge the attribute associated with the TTL with the data item received from the Asian datacenter node 3. At the Asian datacenter node 3, this MERGE request results in the creation of a data item instance 35. However, like the African datacenter node 1, the MERGE request associated with the attribute (received from the European datacenter node 2) is received before receiving the data item from the Asian datacenter node 3. The African datacenter node considers the MERGE request. Assuming that the data item does not have a value but the MERGE request is meaningful, the African datacenter node 1 creates a data item instance 34. The African datacenter node 1 then receives a data item from the Asian datacenter node 3 that indicates a data type defined as "set" and a data value defined as "{a, b}".Thus, African datacenter node 1 creates data item instance 36 with a data type defined as "set" and a data value defined as "{a, b}", with an attribute TTL defined as "12345". At this point, there is eventual consistency of the data item across each of the geographically distributed datacenter nodes: Asian datacenter node 3, European datacenter node 2, and African datacenter node 1.

[0065] 6 is a block diagram of an electronic device 600 that may provide the functionality of one or more components and is further described elsewhere herein. For example, a computer with network capabilities may be configured as electronic device 600. According to some embodiments, electronic device 600 may be configured as part of a customer, e.g., user equipment (UE), or a data center node, or a data center node or device that provides network access (e.g., gNB), and may support message processing functionality associated with the data center node.

[0066] As shown, device 600 includes a processor 51, such as a central processing unit (CPU) or a dedicated processor such as a graphics processing unit (GPU) or other such processor unit, memory 54, non-transitory mass storage 52, I / O interface 55, network interface 53, and transceiver 56, all of which are communicatively coupled via a bidirectional bus 57. According to a particular embodiment, any or all of the illustrated elements may be utilized, or only a subset of the elements may be utilized. Furthermore, device 600 may include multiple instances of a given element, such as multiple processors, memories, or transceivers. Elements of a hardware device may also be directly coupled to other elements without a bidirectional bus. In addition to or in place of the processor and memory, other electronic devices, such as integrated circuits, may be employed to perform the required logical operations.

[0067] Memory 54 may include any type of non-transitory memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or any combination of the like. Mass storage element 52 may include any type of non-transitory storage device, such as a solid-state drive, a hard disk drive, a magnetic disk drive, an optical disk drive, a USB drive, or any computer program product configured to store data and machine-executable program code. According to particular embodiments, memory 54 or mass storage 52 may store statements and instructions executable by processor 51 to perform any of the aforementioned method operations described above.

[0068] While specific embodiments of the present technology have been described herein for illustrative purposes, it should be understood that various modifications may be made without departing from the scope of the present technology. The specification and drawings should therefore be considered merely as illustrative of the invention, as defined by the appended claims, and are intended to encompass any modifications, variations, combinations, or equivalents that fall within the scope of the present disclosure. It is within the scope of the present technology to provide a computer program product or program element, or a program storage or memory device, such as a magnetic or optical wire, tape, or disk, for storing machine-readable signals, for controlling the operation of a computer in accordance with the methods of the present technology, and / or for structuring some or all of its components in accordance with the systems of the present technology.

[0069] The operations associated with the methods described herein may be embodied as coded instructions in a computer program product, which is a computer-readable medium having recorded thereon software code for performing the methods when the computer program product is loaded into a memory and executed on a microprocessor of a communication device.

[0070] Furthermore, each operation of the method may be executed according to one or more, or one or more partial program elements, modules, or objects created from any programming language such as C++, Java, etc. on any computing device such as a personal computer, a server, a PDA, etc. In addition, each operation, or a file or object implementing each operation, may be executed by dedicated hardware or a circuit module designed for that purpose.

[0071] Through the description of the foregoing embodiments, the present invention may be implemented using hardware alone or using software and a required universal hardware platform. Based on this understanding, the technical solutions of the present invention may be embodied in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which may be a compact disc read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes some instructions that enable a computer device (a personal computer, a server, or a network device) to execute the methods provided in the embodiments of the present invention. For example, such execution may correspond to the simulation of the logical operations described herein. The software product may additionally or alternatively include some instructions that enable a computer device to execute operations for programming or implementing a digital logic device according to the embodiments of the present invention.

[0072] While the invention has been described with reference to particular features and embodiments thereof, it will be apparent that various modifications and combinations can be made without departing from the invention. The specification and drawings are therefore to be considered merely as illustrative of the invention as defined by the appended claims, and are intended to cover any modifications, variations, combinations, or equivalents that fall within the scope of the invention. [Explanation of symbols]

[0073] 1 Data Center Node gNB Africa 2 Datacenter Node gNB Europe 3 Datacenter Node gNB Asia 5. Communication Network 11 Data Items 12 Data Items 13 instances 14 instances 15 Databases 16 Customer 20 Data Items 21 instances 22 Data Items 23 Multi-type CRDT structure 24 Multi-type CRDT structure 25 Messages 26 Customer 27 new instances 28 new instances 29 new instances 30 Data Items 31 Data Item Instances 32 Data Item Instances 34 Data Item Instances 35 Data Item Instances 36 Customer, Data Item Instance 51 processors 52 Mass Storage 53 Network Interface 54 memory 55 I / O interfaces 56 Transceiver 57 Bidirectional Bus 600 Electronic Devices

Claims

1. 1. A method for managing conflict-free replicated data types in a database system including multiple data center nodes, comprising: receiving, by a message processing function associated with a data center node, a request message defining a request related to a data item, the data item being defined without a data type or with one or more data types, and a priority associated with the one or more data types; performing, by said message processing function, one or more actions based on an evaluation of said request; A method comprising:

2. The steps of performing determining, by said message processing function, whether said request includes a get-current-type request associated with said data item; reporting, by the message processing function, the data type associated with the data item upon determining that the data item has a data type based at least in part on the priority; if determining that the data item does not have a data type, reporting by the message processing function that the data item does not have a data type; 2. The method of claim 1, comprising:

3. The steps of performing determining, by said message processing function, whether said request includes a clear request associated with said data item; Upon determining that the request is a clear request, clearing, by said message processing function, one or more values ​​associated with said data item; clearing, by said message processing function, one or more attributes associated with said data item; constructing, by the message processing function, a merge clear message based on the one or more values ​​and the clearing the one or more attributes; sending, by the message processing function, a merge clear request associated with the data item to all other data center nodes in the database system; 2. The method of claim 1, comprising:

4. The steps of performing if the request is determined to be not a clear request, determining by the message processing function whether the data item has a data type; If it is determined that the data item does not have a data type and the request is meaningful, applying, by said message processing function, changes to values ​​associated with said data items defined by said request; applying, by said message processing function, changes to attributes associated with said data item defined by said request; sending, by the message processing function, a merge request associated with the data item to all other data center nodes in the database system; 2. The method of claim 1, comprising:

5. The steps of performing determining that the data item has a data type based at least in part on the priority order and that the current data type associated with the data item matches the data type defined in the request; applying, by said message processing function, changes to values ​​associated with said data items defined by said request; applying, by said message processing function, changes to attributes associated with the data item defined by said request; sending, by the message processing function, a merge request associated with the data item to all other data center nodes in the database system; 2. The method of claim 1, comprising:

6. The steps of performing determining that the data item has a data type based at least in part on the priority order and that the current data type associated with the data item is different from the data type defined in the request; The method of claim 1 , further comprising the step of: denying, by the message processing function, the request.

7. The method of claim 1 , wherein the request message is associated with a read request.

8. 7. The method of claim 1, wherein the data items can contain multiple values ​​and multiple data types, and the data types are incompatible.

9. A data center node associated with a database system, the data center node comprising: a processor; a memory having machine-executable instructions stored therein, the machine-executable instructions, when executed by the processor, causing the data center node to: receiving a request message defining a request related to a data item, the data item being defined without a data type or with one or more data types, and a priority associated with the one or more data types; memory configured to perform one or more actions based on an evaluation of the request; A data center node comprising:

10. The machine-executable instructions, when executed by the processor, during the performance of one or more operations: The data center node determining whether the request includes a get-current-type request associated with the data item; upon determining that the data item has a data type based at least in part on the priority, reporting the data type associated with the data item; The data center node of claim 9 , further configured to, upon determining that the data item does not have a data type, report that the data item does not have a data type.

11. During the performance of one or more operations, the machine-executable instructions, when executed by the processor, cause the data center node to: determining whether the request includes a clear request associated with the data item; Upon determining that the request is a clear request, clearing one or more values ​​associated with said data item; clearing one or more attributes associated with said data item; constructing a merge clear message based on clearing the one or more values ​​and the one or more attributes; The data center node of claim 9 , further configured to send a merge clear request associated with the data item to all other data center nodes in the database system.

12. During the performance of one or more operations, the machine-executable instructions, when executed by the processor, cause the data center node to: If it is determined that the request is not a clear request, determining whether the data item has a data type; If it is determined that the data item does not have a data type and the request is meaningful, applying changes to values ​​associated with said data items defined by said request; applying changes to attributes associated with said data item defined by said request; The data center node of claim 9 , further configured to send a merge request associated with the data item to all other data center nodes in the database system.

13. During the performance of one or more operations, the machine-executable instructions, when executed by the processor, cause the data center node to: determining, based at least in part on the priority, that the data item has a data type and that the current data type associated with the data item matches the data type defined in the request; applying changes to values ​​associated with said data items defined by said request; applying changes to attributes associated with said data item defined by said request; The data center node of claim 9 , further configured to send a merge request associated with the data item to all other data center nodes in the database system.

14. During the performance of one or more operations, the machine-executable instructions, when executed by the processor, cause the data center node to: determining that the data item has a data type based at least in part on the priority order, and that the current data type associated with the data item is different from the data type defined in the request; The data center node of claim 9 , further configured to reject the request.

15. The data center node according to claim 9 , wherein the request message is associated with a read request.

16. 15. The data center node of claim 9, wherein the data item can include multiple values ​​and multiple data types, and the data types are incompatible.

17. Multiple Database Center Nodes Each of the data center nodes comprises: a processor; a memory having machine-executable instructions stored therein, the machine-executable instructions, when executed by the processor, for configuring a particular data center node to: receiving a request message defining a request related to a data item, the data item being defined without a data type or with one or more data types, and a priority associated with the one or more data types; memory configured to perform one or more actions based on an evaluation of the request; A database system comprising:

18. While performing one or more operations, the machine-executable instructions, when executed by the processor, cause the particular data center node to: determining whether the request includes a get-current-type request associated with the data item; upon determining that the data item has a data type based at least in part on the priority, reporting the data type associated with the data item; 10. The database system of claim 9, further configured to, upon determining that the data item does not have a data type, report that the data item does not have a data type.

19. While performing one or more operations, the machine-executable instructions, when executed by the processor, cause the particular data center node to: determining whether the request includes a clear request associated with the data item; Upon determining that the request is a clear request, clearing one or more values ​​associated with said data item; clearing one or more attributes associated with said data item; constructing a merge clear message based on clearing the one or more values ​​and the one or more attributes; The database system of claim 9 , further configured to send a merge clear request associated with the data item to all other data center nodes in the database system.

20. While performing one or more operations, the machine-executable instructions, when executed by the processor, cause the particular data center node to: If it is determined that the request is not a clear request, determining whether the data item has a data type; If it is determined that the data item does not have a data type and the request is meaningful, applying changes to values ​​associated with said data items defined by said request; applying changes to attributes associated with said data item defined by said request; The database system of claim 9 , further configured to send a merge request associated with the data item to all other data center nodes in the database system.

21. While performing one or more operations, the machine-executable instructions, when executed by the processor, cause the particular data center node to: determining, based at least in part on the priority, that the data item has a data type and that the current data type associated with the data item matches the data type defined in the request; applying changes to values ​​associated with said data items defined by said request; applying changes to attributes associated with said data item defined by said request; The database system of claim 9 , further configured to send a merge request associated with the data item to all other data center nodes in the database system.

22. While performing one or more operations, the machine-executable instructions, when executed by the processor, cause the particular data center node to: determining that the data item has a data type based at least in part on the priority order, and that the current data type associated with the data item is different from the data type defined in the request; The database system of claim 9 , further configured to reject the request.

23. 23. The database system of claim 17, wherein the request message is associated with a read request.

24. 23. The database system of claim 17, wherein the data items can contain multiple values ​​and multiple data types, and the data types are incompatible.

Images