Method and system for eventual consistency of data types in geo-distributed multi-active database systems

Abstract

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

Description

TECHNICAL FIELD

[0001] The present invention relates to systems and methods for data management in multi-active architectures, including systems and methods for cross-region multi-active data replication between services in cloud computing. BACKGROUND

[0002] Multi-active network architecture is a data resilience architecture that distributes database information across multiple data centers through independent and geographically separated clusters and nodes. The architecture is a network of independent processing nodes, each with a copy of a database (or cache), so that all nodes can participate in a common application, ensuring local low latency and each region can run in isolation.

[0003] However, without coordination between the computers hosting the replicated databases, concurrent updates to multiple copies of the same data in a multi-active system can lead to inconsistencies between the copies. When there is a conflict between updates, restoring eventual consistency and data integrity can require partial or complete rejection of some or all updates.

[0004] Eventual consistency is a consistency model used in distributed computing to achieve high availability, which informally guarantees that, given no new updates to a given data item, eventually all accesses to the item will return the same value across all replicas. Eventual consistency is also known as optimistic replication, deployed in distributed systems, originating from early mobile computing projects. A system that implements eventual consistency is often referred to as having converged or achieved replica convergence.

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

[0006] Distributed multi-active database systems can require real-time, fast, bidirectional data replication between different regions. Two parts of the system can attempt to create the same data item with different types, resulting in conflicts. Multiple conflicts can arise for the same data when the communication link is temporarily blocked (e.g., during network partitioning). However, all data items must always be available to all parts of the database system. After replication is complete, the data in all regions must eventually be consistent. Conflict identification and resolution of data changes must be fast.

[0007] Conflict-free replicated data types (CRDTs) are a class of data structures that can resolve conflicts between database or cache operations (including write commands, delete commands, update commands) when replicating data and metadata across multiple service instances. CRDT data structures can be implemented using a CRDT module (also referred to as a CRDT proxy) that is added to an existing data store functionality. The CRDT module can be loaded and initialized at service instance startup.

[0008] Operation-based CRDTs can transmit only update operations, which can be small. Operation-based CRDTs make strong assumptions about the reliability of communication and require that the communication middleware guarantee that operations are not dropped or duplicated when transmitted to other replicas and that they are delivered in order. Thus, the communication infrastructure must ensure that all operations on one replica are delivered to other replicas in order without duplication.

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

[0010] Cloud applications can have a high demand for geo-distributed multi-active databases to provide global, reliable, and high-performance services. If two regions of a geo-distributed multi-active database system create the same data item with different types, a data type conflict resolution mechanism is needed to guarantee eventual consistency between these regions. Otherwise, application developers must change the business logic and follow specific usage patterns to avoid data type conflicts.

[0011] Some traditional CRDTs ensure conflict avoidance by requiring the system design to take specific steps (specific usage patterns). Database providers must document the behavior and constraints for resolving data type conflicts in their user guides, as applications need to adapt to them.

[0012] Some traditional CRDTs handle a single data type, limiting 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] Accordingly, 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 when there are mixed data types. Such a CRDT structure can avoid or mitigate one or more limitations of the prior art.

[0014] The purpose of the background is to reveal information which the applicant believes to be of possible relevance to the present application. No admission is necessarily inferred, nor should it be construed, that any of the above information constitutes prior art against the present application. SUMMARY

[0015] The present application provides a method and system for implementing data type eventual consistency in a geo-distributed multi-active database system. A multi-type conflict-free replicated data type (CRDT) structure is provided. The multi-type CRDT structure and method enable a geo-distributed multi-active database system to reach eventual consistency on data type conflicts by supporting multiple incompatible data types. The multi-type CRDT structure can handle multiple types simultaneously without isolating instances of various CRDT data types and assumes only ordered, eventually delivered on a single point-to-point channel.

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

[0017] In some embodiments, the performing step comprises the message processing function determining whether the request comprises 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 order, the performing step further comprises the message processing function reporting the data type associated with the data item. Upon determining that the data item has no data type, the performing step further comprises the message processing function reporting that the data item has no data type.

[0018] In some embodiments, the performing step includes the message processing function determining whether the request includes a purge request associated with the data item. Upon determining that the request is a purge request, the performing step includes the message processing function purging one or more values associated with the data item; the message processing function purging one or more attributes associated with the data item. Upon determining that the request is a purge request, the performing step further includes the message processing function establishing a consolidated purge message based on the purge of the one or more values and the one or more attributes; the message processing function sending a consolidated purge request associated with the data item to all other data hub nodes in the database system.

[0019] In some embodiments, upon determining that the request is not a purge request, the performing step includes the message processing function determining whether the data item has a data type. Upon determining that the data item does not have a data type and the request has meaning: the performing step further includes the message processing function applying a change to a value associated with the data item defined by the request; the message processing function applying a change to an attribute associated with the data item defined by the request. Upon determining that the data item does not have a data type and the request has meaning, the performing step further includes the message processing function sending a consolidated request associated with the data item to all other data hub nodes in the database system.

[0020] In some embodiments, upon determining that the data item has a data type and a current data type associated with the data item matches a data type defined in the request based at least in part on the priority order: the performing step includes the message processing function applying a change to a value associated with the data item defined by the request; the message processing function applying a change to an attribute associated with the data item defined by the request. Upon determining that the data item has a data type and a current data type associated with the data type matches a data type defined in the request, the performing step further includes the message processing function sending a consolidated request associated with the data item to all other data hub nodes in the database system.

[0021] In some embodiments, upon determining that the data item has a data type and a current data type associated with the data item does not match a data type defined in the request based at least in part on the priority order: the performing step includes the message processing function rejecting the request.

[0022] In some embodiments, the request message is associated with a read request. In some embodiments, the data item can include a plurality of values and a plurality of data types, wherein the data types are incompatible.

[0023] According to an aspect, there is provided a data hub node associated with a database system. The data hub node comprises: a processor; a memory comprising machine executable instructions stored on the memory. The machine executable instructions, when executed by the processor, cause the data hub node to perform one or more of the methods defined above.

[0024] According to an aspect, there is provided a database system comprising a plurality of data hub nodes. Each data hub node comprises: a processor; a memory comprising machine executable instructions stored on the memory. The machine executable instructions, when executed by the processor, configure the particular data hub node to perform one or more of the methods defined above.

[0025] Embodiments are described above in connection with aspects of the application. These embodiments can be implemented based on the aspects described, but embodiments can also be implemented in combination with other aspects of the application. When embodiments are mutually exclusive or not compatible with each other, this will be apparent to the person skilled in the art. Some embodiments can be described in connection with one aspect, but can also be applicable to other aspects, as will be apparent to the person skilled in the art. BRIEF DESCRIPTION OF DRAWINGS

[0026] Further features and advantages of the application will become apparent from the following detailed description, taken in connection with the accompanying drawings, wherein:

[0027] Figure 1 Block timeline diagram showing a geographical distribution database system for embodiments;

[0028] Figure 2 Block timeline diagram showing an example of a data type conflict resulting from the creation of the same data item with different types and values by geographically separated Asian and African databases for embodiments;

[0029] Figure 3 Logic diagram for resolving data type conflicts for embodiments;

[0030] Figure 4 Block timeline diagram showing an example of a data type conflict resolved after a pass CLEAR operation for embodiments;

[0031] Figure 5 Block timeline diagram showing an example of non-sequential passing of attributes resulting in no value for embodiments;

[0032] Figure 6 Block diagram of an electronic device for embodiments. DETAILED DESCRIPTION

[0033] Embodiments of the present invention provide a method and system for implementing data type eventual consistency in a geo-distributed multi-active database system. A multi-type conflict-free replicated data type (CRDT) structure is provided. The multi-type CRDT structure and method enable a geo-distributed multi-active database system to achieve eventual consistency on data type conflicts by supporting multiple incompatible data types. The multi-type CRDT structure can handle multiple types simultaneously without isolating instances of various CRDT data types and only assumes ordered, eventually transmitted on a single point-to-point channel.

[0034] Figure 1 A block diagram of a geo-distributed database system is provided for embodiments. The distributed database system includes multiple geographically separated data center nodes, including gNB Asia 3, gNB Europe 2, and gNB Africa 1. Although the data center nodes are shown as gNBs, other types of data center node configurations can be used in some embodiments, where the data center nodes generally provide access to communication and other services through a communication interface. The geographically separated data center nodes gNB Asia 3, gNB Europe 2, and gNB Africa 1 are communicatively connected through a communication network 5 that provides a means for coordinating data replication between the geographically separated data center nodes associated with the geo-distributed database system. Customers in a particular geographic region, such as user equipment (UE), can perform tasks such as interacting with the associated geographic data center nodes using a communication network (not shown). For example, customer 36 communicates with gNB Asia 3, customer 26 communicates with gNB Europe 2, and customer 16 communicates with gNB Africa 1.

[0035] It has been recognized that cloud applications can have a high demand for geo-distributed multi-active databases to provide global, reliable, and high-performance services. Therefore, if two regions of a geo-distributed multi-active database system create the same data item with different types, a data type conflict resolution mechanism is needed to guarantee eventual consistency between these regions.

[0036] Figure 2 A block timeline diagram showing an example of a data type conflict caused by geographically separated Asia and Africa databases creating the same data item with different types and values is provided for embodiments. In this example, the same data item is created in two different regions of a geo-distributed multi-active database system. The data item is created in the Asia region with a string type and a value of “abc” and in the Africa region with an integer type and a value of 123. The data type conflict resolution mechanism is used to resolve the data type conflict and ensure eventual consistency between the two regions. Figure 2In the middle, the block timeline illustrates an example of data type conflict caused by clients in African data center node 1 and Asian data center node 3. Data center nodes 1-3 host replicas of a database. For example, European data center node 2 maintains database 15. The Asian and African data center nodes also maintain replicas of database 15. African data center node 1 creates data item 11 with data value set to "{a, b}" and data type defined as "set". Asian data center node 3 creates the same data item (labeled as data item 12) with data value set to "hello" and data type defined as "string". African data center node 1 reaches European data center node 2 and replicates its data item 11 as instance 13 at that node, while Asian data center node 3 replicates its data item 12 as instance 14 at European data center node 2. Instances 13 and 14 can be created on database 15 at the same time or at different times. Since the data items of the European data center node database replica 15 have more than one data type, database replica 15 needs a method to determine the data type to report to the client. If such data type conflicts cannot be resolved quickly and efficiently, it can cause customer complaints.

[0037] The present invention provides a method and system to obtain a consistent data representation in all data centers hosting replicas of a database. The method to obtain a consistent data representation is a multi-type CRDT. The multi-type CRDT method and system facilitate a systematic approach to resolving data type conflicts instead of managing a large number of data type instances that can be added and removed from a map such as a key-value store distributed across a large geographical area. The multi-type CRDT method does not restrict customers to use a specific usage pattern (no need to modify business logic) and can simplify the addition of new data types to the database. Consistency can be obtained during READ operations by performing a type conflict resolution procedure.

[0038] According to some embodiments of the present invention, an instance of the multi-type CRDT structure is referred to as a data item. Externally, the multi-type CRDT structure can have a data type or can have no data type. At different times, the multi-type CRDT structure can have different external data types. Internally, the multi-type CRDT structure can have no data type or can have multiple data types. Thus, the multi-type CRDT structure can have more than one internal data type at the same time. The list of internal data types associated with a data item can change over time.

[0039] According to an embodiment, the internal CRDT data types are ordered by priority. When a data item (multi-type CRDT structure) has more than one internal data type, a conflict resolution is performed each time the data item is accessed. For example, in one embodiment of a multi-type CRDT structure, the internal CRDT data types can be a string and a counter, where the string has priority over the counter. In another embodiment, the internal CRDT data types can be a set, a list, and a map, where the priority order can be defined as map has priority over list and set, where list has priority over set.

[0040] According to an embodiment, externally, a multi-type CRDT structure can have no attributes or can have attributes. At different times, a multi-type CRDT structure can have different external attributes. Internally, a multi-type CRDT structure can have no attributes or can have multiple attributes. Thus, a multi-type CRDT structure can have more than one internal attribute at the same time. The list of internal attributes associated with a data item can change over time. The multi-type CRDT structure attributes are independent of the data types. The attributes of a multi-type CRDT structure can have an attribute type.

[0041] According to the present invention, a multi-type CRDT structure can have no internal data values, internal data types, and internal attributes. Such a multi-type CRDT structure is described as “empty”. An empty multi-type CRDT structure can have no external data values, external data types, and external attributes.

[0042] In some embodiments of the present invention, if a data item (multi-type CRDT structure) has at least one internal data value with a data type but no attributes, the multi-type CRDT structure can have an external data value.

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

[0044] In the present invention, a local client is defined as a client that is geographically close to a particular data center node, for example, client 16 of African data center node 1. At this time, African data center node 1 is the local data center.

[0045] In some embodiments, the disclosed method can define a set of internal data types. The set of internal date types of a multi-type CRDT structure can be ordered in a hierarchical order (e.g., priority order). For each pair of different internal date types, one internal data type has priority over the other data type. In addition, the method can determine a set of internal attributes (possibly empty). Each internal attribute can have at least one attribute type.

[0046] According to embodiments, each data type of the multi-type CRDT structure (e.g., internal data types and external data types) can be accompanied by a set of local operations that return output information to the local client, and information that can be sent to all remote copies of the particular database. The information communicated to the remote copies can specify remote operations to be performed on instances of matching data types (or matching data types) on each remote copy. For read-only local operations, information about any changes can not be sent to the remote copies. According to embodiments, the requirement for instances in remote copies of data items is that the remote copy data items have a multi-type CRDT structure. For example, the improvement provided by the multi-type CRDT structure is that even when remote instances of a data item have data types that do not match at the time the information is transmitted (e.g., received from another data center regarding a particular data item), the final two instances of the data item (i.e., the data item existing in the first database and the copy of the data item in another database) will have the same data type.

[0047] According to embodiments, the message processing function can facilitate the transmission of generated information to the local client and remote copies of the local database. For example, a local operation clear (CLEAR) can place a local instance of a data item (e.g., a multi-type CRDT structure) in an empty state. The disclosed method can define a read-only operation as EMPTY. When the multi-type CRDT structure is in an empty state, and an EMPTY operation is performed on such a structure, the EMPTY operation can return information indicating a "true" state.

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

[0049] According to embodiments, using the multi-type CRDT structure defined above, reference is made herein to Figure 3 Methods for resolving data type conflicts are discussed. Figure 3 Logical diagrams for resolving data type conflicts are provided for embodiments.

[0050] In some embodiments, a local client can send a request 301 to a local data center addressing a multi-type CRDT structure (data item d). The request can indicate a get-current-type (GET-CURRENT-TYPE) operation 302. In 303, if the multi-type CRDT structure does not currently have a data type 305, the output information transmitted to the local client can have an indication that the data item (multi-type CRDT structure) does not have a data type. If the multi-type CRDT structure has a current data type 304, the output information transmitted to the local client can provide an indication of the current data type.

[0051] According to embodiments, a data type (e.g., a current data type of a data item) can be determined based on a priority sequence associated with the data type, the data type being associated with a multi-type CRDT structure, as discussed in more detail elsewhere herein.

[0052] In some embodiments, a local client can send a request to a local data center addressing a multi-type CRDT structure (data item d), the request can indicate a clear (CLEAR) operation. In 315, if the request is a clear (CLEAR) operation, a clear (CLEAR) operation applied to the addressed multi-type CRDT structure can invalidate each data value 316. A merge-clear (MERGE-CLEAR) message can be generated for each data value invalidated or cleared by the clear (CLEAR) operation.

[0053] According to embodiments, a clear (CLEAR) operation applied to a multi-type CRDT structure addressed by a request can invalidate each attribute 317. A merge-clear (MERGE-CLEAR) message can be generated for each attribute invalidated by the clear (CLEAR) operation. Upon completion of this step, all attributes and data values can report that they are empty. In addition, in this step, the local replica (multi-type CRDT structure addressed in the local database) can not have a data type.

[0054] According to embodiments, the method can further include generating or constructing 318 a final merge-clear (MERGE-CLEAR) message. The final merge-clear (MERGE-CLEAR) message can contain all merge-clear (MERGE-CLEAR) messages generated after the clear (CLEAR) operation is applied to the addressed multi-type CRDT structure. The final merge-clear (MERGE-CLEAR) message can be transmitted or sent 319 to each remote replica of the addressed multi-type CRDT structure accordingly.

[0055] In some embodiments, a local client can send a request to a local data center addressing a multi-type CRDT structure (data item d). In 314, the addressed multi-type CRDT structure can not have a data type, but the request can also indicate a modification that can make sense, i.e. a modification of a data item, for example when the attribute reflects a time to live (TTL) associated with the data item, regardless of the data item not having an associated value, the attribute change can make sense.

[0056] According to embodiments, the method can further comprise validating the request and applying 313, 312 the requested modification to the addressed multi-type CRDT structure. Further, the method can comprise generating a plurality of MERGE messages after the requested modification is applied to the addressed multi-type CRDT structure. For example, the requested modification can be applied to the internal data value 313 and the corresponding attribute 312.

[0057] According to embodiments, the method can further comprise generating a final MERGE message. The final MERGE message can contain all the MERGE messages generated after the requested modification is applied to the addressed multi-type CRDT structure. The final MERGE message can be transmitted or sent 311 to each remote copy of the addressed multi-type CRDT structure accordingly.

[0058] In some embodiments of the method, a local client can send a request to a local data center addressing a multi-type CRDT structure (data item d). The addressed multi-type CRDT structure can have a current data type. The request can have an indication of a data type that matches the current data type 306. The request can also indicate a modification to be applied to the addressed multi-type CRDT structure. The method can further comprise validating the request and applying 308, 309 the requested modification to the addressed multi-type CRDT structure. For example, the requested modification can be applied to the internal data value 308 and the corresponding attribute 309.

[0059] According to embodiments, the method can comprise generating a plurality of MERGE messages after the requested modification is applied to the addressed multi-type CRDT structure having a current data type. The method can further comprise generating a final MERGE message. The final MERGE message can contain all the MERGE messages generated after the requested modification is applied to the addressed multi-type CRDT structure having a current data type. The final MERGE message can be transmitted or sent 310 to each remote copy of the addressed multi-type CRDT structure having a current data type accordingly.

[0060] In some embodiments of the method, the local client can send a request to the local data center addressing a multi-type CRDT structure (data item d). The addressed multi-type CRDT structure can have a current data type, however, the request can 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 addressing the multi-type CRDT structure is rejected 307.

[0061] In some embodiments of the application, a multi-type CRDT structure is hosted on a local data center node, and a remote copy of the multi-type CRDT structure is hosted on one or more remote data center nodes. According to embodiments, a message processing function operating at a remote data center node can send a request to the local data center node addressing an operation to be performed in association with the multi-type CRDT structure stored on the local data center node. According to embodiments, a message processing function operating at the local data center node can send a request to one or more remote data center nodes addressing an operation to be performed in association with the multi-type CRDT structure stored on the local data center node.

[0062] In some embodiments, a remote data center node sends a MERGE request for a data item stored on other data center nodes associated with the database system (i.e., an addressed multi-type CRDT structure). In some embodiments, the MERGE request can indicate a MERGE-CLEAR operation. If the request is a MERGE-CLEAR, the application of the MERGE-CLEAR operation can merge each sub-message into the corresponding attribute and optional sub-value associated with the addressed multi-type CRDT structure. Upon completion, the local copy of the local data center node (i.e., the addressed multi-type CRDT structure) can or can not have a data type. If the request is not a MERGE-CLEAR request, the application of the MERGE request incorporates the request into the indicated attribute or optional sub-value associated with the request.

[0063] Figure 4A block timeline diagram showing an example of a data type conflict resolved after a pass clear (CLEAR) operation is provided for an embodiment. African data center node 1 hosts data item 20 with a data type defined as "set" and a data value defined as "{a,b}". Asian data center node 3 hosts the same data item (labeled 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 and creates instance 21 with type "string" and value "hello". In correspondence with or concurrently with the action performed by Asian data center node 3, African data center node 1 contacts European data center node 2 to create a copy of data item 20. Thus, European data center node 2 hosts multi-type CRDT structure 24 with internal date types: "set" and "sting", and internal data values: "{a,b}" and "hello".

[0064] Asian data center node 3 also contacts African data center node 1 to replicate data item 22 with type "set" and value "{a,b}" at African data center node 1. Thus, African data center node 1 hosts multi-type CRDT structure 23 with internal date types: "set" and "sting", and internal data values: "{a,b}" and "hello".

[0065] According to an embodiment, data type conflicts (as seen in multi-type CRDT structures 23 and 24) can be resolved by a priority order (e.g. an order hierarchy) applied during or prior to an indicated read (READ) operation.

[0066] The Asia data center node 3 receives a message 25 from a local client. The message indicates a clear operation. Upon acknowledging and performing the clear operation, the data type and data value of the instance (e.g., data item) 22 are invalidated or cleared. Further, upon completion of the clear operation, the message processing function at the Asia data center node 3 generates a message indicating a merge-clear operation, which is transmitted to the other data centers hosting copies of the data item 22. The message indicating the merge-clear operation is sent to the Europe and Africa data center nodes. Upon receiving the message, instances having a data type and data value matching the data type “string” and data value “hello” of the data item 22 will be invalidated or cleared. Accordingly, the multi-type CRDT structure 24 (e.g., data item 24) at the Europe 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 (e.g., data item 23) at the Africa data center node 1 is updated to a new instance 28 having only one data type, and thus only one data value.

[0067] At this point in time, the data item copies 26-28 at the three data center nodes 1-3 have reached eventual consistency with the data type “set” and data value “{a, b}.”

[0068] Figure 5A block timeline diagram illustrating an example of non-sequential propagation of attributes resulting in no value for an embodiment. Asian data center node 3 hosts data item 30 with data type defined as "set" and data value defined as "{a,b}". This data item is propagated to both European data center node 2 and African data center node 1, where European data center node 2 receives this data item resulting in the creation of data item instance 31, and African data center node 1 receives this data item resulting in the creation of data item instance 36. It is important to note the difference in timing with respect to the receipt and subsequent creation of the data item instance at European data center node 2 and the data item instance at African data center node 1. After European data center node 2 receives data item 31, it merges the attributes of this data item that reflect the time to live (TTL) associated with the data item resulting in the creation of data item instance 32. European data center node 2 sends a modification request (i.e., a MERGE request) to other data center nodes (i.e., European data center node 2 and African data center node 1) where this request merges the attributes related to TTL with the data item received from Asian data center node 3. At Asian data center node 3, this MERGE request results in the creation of data item instance 35. However, as African data center node 1, the MERGE request related to attributes is received (from European data center node 2) before the data item is received from Asian data center node 3. African data center node considers the MERGE request. Assuming the data item has no value, but the MERGE request makes sense, African data center node 1 creates data item instance 34. Later, African data center node 1 receives the data item from Asian data center node 3 indicating data type defined as "set" and data value defined as "{a,b}". Thus, African data center node 1 creates data item instance 36 with data type defined as "set" and data value defined as "{a,b}" and attributes TTL defined together as "12345". At this point, there is eventual consistency of the data item across each geographically dispersed data center node (i.e., Asian data center node 3, European data center node 2, and African data center node 1).

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

[0070] As shown, the device 600 includes a processor 51, e.g., a central processing unit (CPU) or a dedicated processor such as a graphics processing unit (GPU) or other such processor unit, a memory 54, a non-transitory mass storage device 52, an I / O interface 55, a network interface 53, and a transceiver 56, all communicatively coupled via a bidirectional bus 57. According to certain embodiments, any or all of the depicted elements can be used, or only a subset of the elements. Moreover, the device 600 can include multiple instances of certain elements, such as multiple processors, memories, or transceivers. In addition, elements of the hardware device can be directly coupled to other elements without the bidirectional bus. Other than the processor and the memory, other electronic elements such as integrated circuits can be used to perform the required logical operations.

[0071] The memory 54 can 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), a combination of any of the above, or the like. The mass storage element 52 can include any type of non-transitory storage device, such as a solid-state drive, a hard disk drive, a disk drive, an optical disk drive, a USB drive, or any computer program product for storing data and machine-executable program code. According to certain embodiments, the memory 54 or the mass storage 52 can have recorded thereon statements and instructions executable by the processor 51 for performing any of the method operations described above.

[0072] It should be understood that although specific embodiments of the technology have been described herein, various modifications can be made without departing from the scope of the technology. The specification and drawings are, accordingly, to be regarded simply as an illustration of the application as defined by the appended claims and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present specification. Within the scope of the technology, a computer program product or program element, or a program storage device or memory device such as magnetic discs, optical disks, operable connection for communicating electric signals digital and / or analog communications links, etc. is supplied for storing a computer program or program code means which is executable by a computer for performing operations for controlling a computer according to the methods of the technology and / or for structuring a system according to the technology to perform operations for controlling a computer according to the methods of the technology and / or for structuring a system according to the technology to perform operations for controlling a computer according to the methods of the technology.

[0073] The actions associated with the methods described herein can be implemented in a computer program product as encoded instructions. In other words, the computer program product is a computer-readable medium on which software code is recorded in order to execute the methods when the computer program product is loaded into the memory and executed on the microprocessor of the communication device.

[0074] Furthermore, each operation of the method can be executed on any computing device, such as a personal computer, a server, a PDA, etc., according to one or more program elements, modules or objects generated from any programming language, such as C++, Java, etc., or one or more parts of one or more program elements, modules or objects. Further, each operation or the files or objects, etc. implementing each described operation can be executed by a dedicated hardware or a circuit module designed for this purpose.

[0075] From the description of the above-mentioned embodiments, it can be seen that the present application can be realized only by hardware, or by software and necessary general hardware platforms. Based on such an understanding, the technical solutions of the present application can be embodied in the form of a software product. The software product can be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk or a mobile hard disk. The software product includes a plurality of instructions, which enable a computer device (a personal computer, a server or a network device) to execute the methods provided in the embodiments of the present application. For example, such execution can correspond to the simulation of logical operations as described herein. According to the embodiments of the present application, the software product can additionally or alternatively include a plurality of instructions, which enable the computer device to execute operations of configuring or programming a digital logic device.

[0076] Although the present application has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the application. The description and drawings are, accordingly, to be regarded simply as an illustration of the underlying application, and are to be construed as a limitation only when in accordance with the claims.

Claims

1. A method for managing conflict-free replicated data types in a database system comprising multiple data center nodes, characterized in that: The method comprises: A message processing function associated with a data center node receives a request message defining a request related to a data item, the data item having no data type defined or having one or more data types defined, wherein a priority order is associated with the one or more data types; The message processing function performs one or more operations based on an evaluation of the request; The execution steps include: The message processing function determines whether the request includes a get current type request associated with the data item; Upon determining, based at least in part on the priority order, that the data item has a data type, the message processing function reports the data type associated with the data item; When determining that the data item does not have a data type, the message processing function reports that the data item does not have a data type; or, The execution steps include: The message processing function determines whether the request includes a purge request associated with the data item; When the request is determined to be a purge request: The message processing function clears one or more values ​​associated with the data item; The message processing function clears one or more attributes associated with the data item; said message processing function establishing a merged purge message based on said purge of said one or more values ​​and said one or more attributes; The message processing function sends a merge purge request associated with the data item to all other data center nodes in the database system; or, The execution steps include: The message processing function determines whether the data item has a data type; Upon determining that the data item does not have a data type and the request makes sense: said message processing function applying a change to a value associated with said data item defined by said request; the message processing function applying changes to attributes associated with the data item defined by the request; The message processing function sends a merge request associated with the data item to all other data center nodes in the database system; or, The execution steps include: Upon determining, based at least in part on the priority order, that the data item has a data type and a current data type associated with the data item matches a data type defined in the request: said message processing function applying a change to a value associated with said data item defined by said request; the message processing function applying changes to attributes associated with the data item defined by the request; The message processing function sends a merge request associated with the data item to all other data center nodes in the database system; or, The execution steps include: Upon determining, based at least in part on the priority order, that the data item has a data type and a current data type associated with the data item is different from a data type defined in the request: The message processing function rejects the request.

2. The method according to claim 1, characterized in that The request message is associated with a read request.

3. The method according to claim 1 or 2, characterized in that The data item may include multiple values ​​and multiple data types, wherein the data types are incompatible.

4. A data center node associated with a database system, characterized in that: The data center node includes: processor; A memory comprising machine-executable instructions stored in the memory, wherein when the machine-executable instructions are executed by the processor, the data center node is caused to perform the following operations: receiving a request message defining a request associated with a data item, the data item having no data type defined therein or having one or more data types defined therein, wherein a priority order is associated with the one or more data types; performing one or more actions based on an evaluation of the request; In performing one or more operations, the machine-executable instructions, when executed by the processor, further cause the 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 order, reporting the data type associated with the data item; When it is determined that the data item does not have the data type, reporting that the data item does not have the data type; or, In performing one or more operations, the machine-executable instructions, when executed by the processor, further cause the data center node to: determining whether the request includes a purge request associated with the data item; When the request is determined to be a purge request: clearing one or more values ​​associated with the data item; clearing one or more attributes associated with the data item; establishing a merged purge message based on said purge of said one or more values ​​and said one or more attributes; sending a merge purge request associated with the data item to all other data center nodes in the database system; or, In performing one or more operations, the machine-executable instructions, when executed by the processor, further cause the data center node to: determining whether the data item has a data type; Upon determining that the data item does not have a data type and the request makes sense: applying a change to a value associated with the data item defined by the request; applying changes to attributes associated with the data item defined by the request; sending a merge request associated with the data item to all other data center nodes in the database system; or, In performing one or more operations, the machine-executable instructions, when executed by the processor, further cause the data center node to: Upon determining, based at least in part on the priority order, that the data item has a data type and a current data type associated with the data item matches a data type defined in the request: applying a change to a value associated with the data item defined by the request; applying changes to attributes associated with the data item defined by the request; sending a merge request associated with the data item to all other data center nodes in the database system; or, In performing one or more operations, the machine-executable instructions, when executed by the processor, further cause the data center node to: Upon determining, based at least in part on the priority order, that the data item has a data type and a current data type associated with the data item is different from a data type defined in the request: The request is denied.

5. The data center node according to claim 4, characterized in that: The request message is associated with a read request.

6. The data center node according to claim 4 or 5, characterized in that: The data item may include multiple values ​​and multiple data types, wherein the data types are incompatible.

7. A database system, characterized in that: The database system includes: A plurality of data center nodes, each of the data center nodes comprising: processor; A memory comprising machine-executable instructions stored on the memory, wherein the machine-executable instructions, when executed by the processor, cause a specific data center node to perform the following operations: receiving a request message defining a request associated with a data item, the data item having no data type defined therein or having one or more data types defined therein, wherein a priority order is associated with the one or more data types; performing one or more actions based on an evaluation of the request; In performing one or more operations, the machine-executable instructions, when executed by the processor, further 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 order, reporting the data type associated with the data item; When it is determined that the data item does not have the data type, reporting that the data item does not have the data type; or, In performing one or more operations, the machine-executable instructions, when executed by the processor, further cause the particular data center node to: determining whether the request includes a purge request associated with the data item; When the request is determined to be a purge request: clearing one or more values ​​associated with the data item; clearing one or more attributes associated with the data item; establishing a merged purge message based on said purge of said one or more values ​​and said one or more attributes; sending a merge purge request associated with the data item to all other data center nodes in the database system; or, In performing one or more operations, the machine-executable instructions, when executed by the processor, further cause the particular data center node to: determining whether the data item has a data type; Upon determining that the data item does not have a data type and the request makes sense: applying a change to a value associated with the data item defined by the request; applying changes to properties associated with the data item defined by the request; sending a merge request associated with the data item to all other data center nodes in the database system; or, In performing one or more operations, the machine-executable instructions, when executed by the processor, further cause the particular data center node to: Upon determining, based at least in part on the priority order, that the data item has a data type and a current data type associated with the data item matches a data type defined in the request: applying a change to a value associated with the data item defined by the request; applying changes to attributes associated with the data item defined by the request; sending a merge request associated with the data item to all other data center nodes in the database system; or, In performing one or more operations, the machine-executable instructions, when executed by the processor, further cause the particular data center node to: Upon determining, based at least in part on the priority order, that the data item has a data type and a current data type associated with the data item is different from a data type defined in the request: The request is denied.

8. The database system according to claim 7, characterized in that The request message is associated with a read request.

9. The database system according to claim 7 or 8, characterized in that: The data item may include multiple values ​​and multiple data types, wherein the data types are incompatible.

Images