Method and system for final consistency of data types in remote multi-live database system

Abstract

The invention provides a method and a system for realizing final consistency of data types in a remote multi-activity database system. According to the method, a multi-type conflict-free replicated data type (CRDT) structure is provided, and the method is applied to the field of multi-type conflict-free replicated data types (CRDT) structures and can be applied to the field of multi-type conflict-free replicated data types (CRDT) structures. According to the multi-type CRDT structure and the multi-type CRDT method, a remote multi-activity database system achieves final consistency in data type conflicts by supporting multiple incompatible data types.

Description

[0001] This application is a divisional application. The original application has the application number 202280100557.5 and the original application date is November 21, 2022. The entire contents of the original application are incorporated herein by reference. Technical Field

[0002] This 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 Technology

[0003] Active-active network architecture is a data resilience architecture that distributes database information across multiple data centers through independent and geographically dispersed clusters and nodes. This architecture is a network of independent processing nodes, each with a copy of the database (or cache), allowing all nodes to participate in a shared application, thus ensuring low local latency and enabling each region to operate in isolation.

[0004] However, without coordination between the computers hosting the replicated database, concurrent updates to multiple copies of the same data in a multi-active system can lead to inconsistencies between the replicas. When conflicts exist between updates, restoring eventual consistency and data integrity may require some or all updates to be completely or partially rejected.

[0005] Eventual consistency is a consistency model used in distributed computing to achieve high availability. It informally guarantees that, without any new updates to a given data item, all eventual accesses to that item will eventually return the same value across all replicas. Eventual consistency, also known as optimistic replication, is deployed in distributed systems and originated from early mobile computing projects. Systems that have implemented eventual consistency are often said to have converged or achieved replica convergence.

[0006] Many distributed computing solutions focus on how to prevent concurrent updates to replicated data in databases or caches. Another possible approach is optimistic replication, where all concurrent updates to the database or cache are allowed, potentially leading to inconsistencies, and the results are later merged or "resolved." In this approach, consistency between replicas can eventually be re-established through the "merging" of different replicas.

[0007] Distributed, multi-active database systems may require real-time, rapid, bidirectional data replication between different regions. Two parts of the system may attempt to create the same data items with different types, leading to conflicts. Multiple conflicts may occur for the same data when communication links are temporarily blocked (e.g., during a network partition). However, all data items must always remain available to all parts of the database system. Once replication is complete, the data in all regions must eventually be consistent. Conflict identification and resolution for data changes must be rapid.

[0008] Conflict-free replicated data type (CRDT) is a data structure that resolves conflicts between database or cache operations (including write, delete, and update commands) when replicating data and metadata across multiple service instances. The CRDT data structure can be implemented using a CRDT module (also known as a CRDT proxy) added to an existing data store. The CRDT module can be loaded and initialized when the cache service instance starts.

[0009] Operation-based CRDT may only transmit update operations, which may be small. Operation-based CRDT makes strong assumptions about communication reliability and requires the communication middleware to guarantee that operations are not discarded or copied when transmitted to other replicas, and that they are delivered in sequence. Therefore, the communication infrastructure must ensure that all operations on one replica are delivered to other replicas in sequence without duplication.

[0010] State-based CRDTs are called aggregate replication data types. State-based CRDTs are generally easier to design and implement. Their disadvantage is that the entire state of each CRDT must eventually be transferred to every other replica, which can result in higher infrastructure and time costs.

[0011] Cloud applications may have high demands for geographically distributed, active-active databases to provide global, reliable, and high-performance services. If two regions of a geographically distributed, active-active database system create the same data items with different data types, a data type conflict resolution mechanism is needed to ensure eventual consistency between these regions. Otherwise, application developers must modify business logic and follow specific usage patterns to avoid data type conflicts.

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

[0013] Some traditional CRDTs handle a single data type, limiting eventual consistency to a single instance of a single type. 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.

[0014] Therefore, there is a need for a method and system for implementing a conflict-free copy 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 can avoid or mitigate one or more limitations of existing technologies.

[0015] The purpose of the background art is to disclose information that the applicant believes may be relevant to the present invention. It is neither necessary nor appropriate to acknowledge that any of the foregoing information constitutes prior art in relation to the present invention. Summary of the Invention

[0016] This invention provides a method and system for achieving eventual consistency of data types in a geographically distributed, multi-active database system. A conflict-free replicated data type (CRDT) structure is provided. The multi-type CRDT structure and method enable the geographically distributed, multi-active database system to achieve eventual consistency in terms of 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, eventual transmission over a single point-to-point channel.

[0017] According to one aspect, a method is provided for conflict-free replication data type management in a database system comprising multiple data center nodes. The method includes: 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 having no defined data type or having one or more defined data types, wherein a priority order is associated with the one or more data types. The method further includes: the message processing function performing one or more operations based on an evaluation of the request.

[0018] In some embodiments, the execution step includes: the message processing function determining whether the request includes a request to obtain the current type associated with the data item. When it is determined at least partially based on the priority order that the data item has a data type, the execution step further includes: the message processing function reporting the data type associated with the data item. When it is determined that the data item does not have a data type, the execution step further includes: the message processing function reporting that the data item does not have a data type.

[0019] In some embodiments, the execution steps include: the message processing function determining whether the request includes a purge request associated with the data item. When the request is determined to be a purge request, the execution steps include: the message processing function purges one or more values ​​associated with the data item; the message processing function purges one or more attributes associated with the data item. When the request is determined to be a purge request, the execution steps further include: the message processing function establishing a merge purge message based on the purge of the one or more values ​​and the one or more attributes; the message processing function sending the merge purge request associated with the data item to all other data center nodes in the database system.

[0020] In some embodiments, when it is determined that the request is not a clear request, the execution step includes: the message processing function determining whether the data item has a data type. When it is determined that the data item does not have a data type and the request is meaningful: the execution step further includes: the message processing function applying a change to the value associated with the data item defined by the request; the message processing function applying a change to the attribute associated with the data item defined by the request. When it is determined that the data item does not have a data type and the request is meaningful, the execution step further includes: the message processing function sending a merge request associated with the data item to all other data center nodes in the database system.

[0021] In some embodiments, when it is determined, at least in part, based on the priority order, that the data item has a data type and the current data type associated with the data item matches the data type defined in the request: the execution steps include: the message processing function applying a change to the value associated with the data item defined in the request; the message processing function applying a change to the attribute associated with the data item defined in the request. When it is determined that the data item has a data type and the current data type associated with the data type matches the data type defined in the request, the execution steps further include: the message processing function sending a merge request associated with the data item to all other data center nodes in the database system.

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

[0023] In some embodiments, the request message is associated with a read request. In some embodiments, the data item may include multiple values ​​and multiple data types, wherein the data types are incompatible.

[0024] According to one aspect, a data center node associated with a database system is provided. The data center node includes: a processor; and memory including machine-executable instructions stored in the memory. When executed by the processor, the machine-executable instructions cause the data center node to perform one or more of the methods defined above.

[0025] According to one aspect, a database system comprising multiple data center nodes is provided. Each data center node includes: a processor; and memory, including machine-executable instructions stored in the memory. When executed by the processor, the machine-executable instructions configure a particular data center node to perform one or more of the methods defined above.

[0026] Embodiments have been described above in conjunction with various aspects of the present invention, and these embodiments can be implemented based on these aspects. Those skilled in the art will understand that embodiments can be implemented in conjunction with the aspects described therein, but may also be implemented together with other embodiments of that aspect. It will be apparent to those skilled in the art that embodiments are mutually exclusive or incompatible with each other. Some embodiments may be described in conjunction with one aspect, but may also be applicable to other aspects, which will be apparent to those skilled in the art. Attached Figure Description

[0027] Furthermore, the features and advantages of the invention will be readily understood by reading the following detailed description taken in conjunction with the accompanying drawings, in which: Figure 1 A block diagram of a geographic distribution database system provided for an embodiment; Figure 2 The block timeline diagram provided for the embodiment illustrates an example of a data type conflict caused by creating the same data items with different types and values ​​from geographically separated Asian and African databases; Figure 3 A logic diagram provided for resolving data type conflicts in an embodiment; Figure 4 The block timeline diagram provided for the embodiment illustrates an example of data type conflicts resolved after a pass-through clear (CLEAR) operation; Figure 5 A block timeline diagram of an example of non-sequential passing of an attribute that results in having no value, provided for the implementation. Figure 6 A block diagram of an electronic device provided for an embodiment. Detailed Implementation

[0028] Embodiments of the present invention provide a method and system for achieving eventual consistency of data types in a geographically distributed active-active database system. A conflict-free replicated datatype (CRDT) structure is provided. The multi-type CRDT structure and method enable the geographically distributed active-active database system to achieve eventual consistency in terms of 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, eventual transmission over a single point-to-point channel.

[0029] Figure 1 This is a block diagram of a geographically distributed database system provided for an embodiment. The distributed database system includes multiple geographically separated data center nodes, including gNB Asia3, gNB Europe2, and gNB Africa1. Although the data center nodes are shown as gNBs, other types of data center node configurations may be used in some embodiments, where data center nodes typically provide access to communications and other services via communication interfaces. The geographically separated data center nodes gNB Asia3, gNB Europe2, and gNB Africa1 are communicatively connected via a communication network 5, which provides a means for coordinating data replication among the geographically separated data center nodes associated with the geographically distributed database system. Clients in a specific geographical area, such as user equipment (UE), can perform tasks such as interacting with associated geographical data center nodes using the communication network (not shown). For example, client 36 communicates with gNB Asia3, client 26 communicates with gNB Europe2, and client 16 communicates with gNB Africa1.

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

[0031] Figure 2 The example provided illustrates a block timeline diagram showing an example of data type conflicts caused by creating identical data items with different types and values ​​from geographically separated Asian and African databases. Figure 2The block timeline diagram illustrates an example of a data type conflict caused by clients in African data center node 1 and Asian data center node 3. Data center nodes 1 through 3 host copies of the database. For example, European data center node 2 maintains database 15. The Asian and African data center nodes also maintain copies of database 15. African data center node 1 creates data item 11 with the data value set to "{a,b}" and the data type defined as "set". Asian data center node 3 creates the same data item (labeled as data item 12) with the data value set to "hello" and the data type defined as "string". African data center node 1 arrives at European data center node 2 and replicates its data item 11 as instance 13 on that node, while Asian data center node 3 replicates its data item 12 as instance 14 on European data center node 2. Instances 13 and 14 can be created on database 15 simultaneously or at different times. Because the data items in the copy of database 15 on the European data center node have more than one data type, the copy of database 15 needs a way to determine the data type to report to the client. Failure to resolve such data type conflicts quickly and efficiently can lead to customer complaints.

[0032] This invention provides a method and system for achieving eventually consistent data representation across all data centers hosting a database replica. The method for achieving eventually consistent data representation is a multi-type CRDT. The multi-type CRDT method and system facilitate a systematic approach to resolving data type conflicts, rather than managing a large number of data type instances that can be added and removed from mappings such as key-value stores distributed across a large geographic area. The multi-type CRDT method does not restrict clients to specific use cases (no modification to business logic is required) and simplifies adding new data types to the database. Consistency can be achieved during read operations by executing a type conflict resolution process.

[0033] According to some embodiments of the present invention, an instance of a multi-type CRDT structure is called a data item. Externally, a multi-type CRDT structure may or may not have a data type. At different times, a multi-type CRDT structure may have different external data types. Internally, a multi-type CRDT structure may not have a data type or may have multiple data types. Therefore, a multi-type CRDT structure can have more than one internal data type simultaneously. The list of internal data types associated with a data item may change over time.

[0034] According to embodiments, the internal CRDT data types are arranged in priority order. When a data item (a multi-type CRDT structure) has more than one internal data type, 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 strings and counters, where strings take precedence over counters. In another embodiment, the internal CRDT data types can be sets, lists, and maps, where the priority order can be defined as maps taking precedence over lists and sets, where lists take precedence over sets.

[0035] According to the embodiments, externally, a multi-type CRDT structure may or may not have attributes. At different times, a multi-type CRDT structure may have different external attributes. Internally, a multi-type CRDT structure may have no attributes or multiple attributes. Therefore, a multi-type CRDT structure can have more than one internal attribute simultaneously. The list of internal attributes associated with a data item may change over time. Multi-type CRDT structure attributes are independent of data type. Attributes in a multi-type CRDT structure can have attribute types.

[0036] According to the present invention, a multi-type CRDT structure may not have 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 may not have external data values, external data types, and external attributes.

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

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

[0039] In this invention, a local client is defined as a client that is geographically close to a specific data center node, for example, client 16 of African data center node 1. In this case, African data center node 1 is the local data center.

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

[0041] According to an embodiment, each data type (e.g., internal and external data types) of a multi-type CRDT structure may be accompanied by a set of local operations that return output information to the local client, as well as information that can be sent to all remote copies of a particular database. The information communicated with the remote copies may specify the 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 may not be sent to the remote copies. According to an embodiment, a requirement for instances in remote copies of a data item is that the remote copy data item has a multi-type CRDT structure. For example, the improvement provided by a multi-type CRDT structure is that even when a remote instance of a data item has a data type that does not match when 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 a copy of that data item in another database) will have the same data type.

[0042] According to embodiments, message processing functionality can facilitate the transmission of generated information to a local client and a remote copy of the local database. For example, a local operation CLEAR can place a local instance of a data item (e.g., a multi-type CRDT structure) into an empty state. The disclosed method can be defined as a read-only operation of EMPTY. When a 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.

[0043] According to embodiments, the message processing functionality can be integrated with a set of local operations to provide the desired operation and functionality according to various embodiments of the invention. The message processing functionality can be configured to operate 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 functionality can be configured as an application program interface (API).

[0044] According to the embodiment, the multi-type CRDT structure defined above is used, as referred to here. Figure 3 Discuss methods for resolving data type conflicts. Figure 3 A logic diagram for resolving data type conflicts is provided for an embodiment.

[0045] In some embodiments, the local client can address multiple types of CRDT structures (data items). dThe local data center sends a request 301. This request may indicate a 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 may 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 may provide an indication of the current data type.

[0046] According to an embodiment, the data type (e.g., the current data type of a data item) can be determined based on a priority sequence associated with the data type, which is associated with a multi-type CRDT structure, and will be discussed in more detail elsewhere in this document.

[0047] In some embodiments, the local client can address multiple types of CRDT structures (data items). d A request is sent to the local data center, which may indicate a CLEAR operation. In 315, if the request is a CLEAR operation, the CLEAR operation applied to the multi-type CRDT structure being addressed can invalidate each data value 316. A MERGE-CLEAR message can be generated for each data value invalidated or cleared by the CLEAR operation.

[0048] According to an embodiment, a CLEAR operation applied to a multi-type CRDT structure addressed by a request can invalidate each attribute 317. A MERGE-CLEAR message can be generated for each attribute invalidated by the CLEAR operation. After this step is completed, all attributes and data values ​​can be reported as empty. Furthermore, in this step, the local copy (the multi-type CRDT structure addressed in the local database) may not have a data type.

[0049] According to an embodiment, the method may further include generating or constructing a 318 Final Merge-Clear message. When this clear operation is applied to an addressed multi-type CRDT structure, the Final Merge-Clear message may be included in all Merge-Clear messages generated after the clear operation. The Final Merge-Clear message may be transmitted or sent accordingly to each remote copy of the addressed multi-type CRDT structure.

[0050] In some embodiments, the local client can address multiple types of CRDT structures (data items). dThe request is sent to the local data center. In 314, the addressed multi-type CRDT structure may not have a data type, but the request can also indicate a meaningful modification, i.e., a modification of the data item. For example, when the attribute reflects the time to live (TTL) associated with the data item, the attribute change can be meaningful even if the data item has no associated value.

[0051] According to an embodiment, the method may further include verifying the request and applying the requested modifications 313, 312 to the addressed multi-type CRDT structure. Furthermore, the method may include generating multiple merge messages after the requested modifications are applied to the addressed multi-type CRDT structure. For example, the requested modifications may be applied to internal data value 313 and the corresponding attribute 312.

[0052] According to an embodiment, the method may further include generating a final merge message. The final merge message may be included in all merge messages generated after the requested modifications are applied to the addressed multi-type CRDT structure. The final merge message may be transmitted or sent accordingly to each remote copy of the addressed multi-type CRDT structure.

[0053] In some embodiments of the method, the local client can address multiple types of CRDT structures (data items). d The request is sent to the local data center of the addressed multi-type CRDT structure. The addressed multi-type CRDT structure may have a current data type. The request may have an indication of a data type matching the current data type 306. The request may also indicate modifications to be applied to the addressed multi-type CRDT structure. The method may further include verifying the request and applying the requested modifications to the addressed multi-type CRDT structures 308, 309. For example, the requested modifications may be applied to internal data value 308 and the corresponding attribute 309.

[0054] According to an embodiment, the method may include generating multiple merge messages after applying the requested modifications to a multi-type CRDT structure addressed to the current data type. The method may also include generating a final merge message. The final merge message may be included in all merge messages generated after applying the requested modifications to the multi-type CRDT structure addressed to the current data type. The final merge message may be transmitted or sent accordingly to each remote copy of the multi-type CRDT structure addressed to the current data type.

[0055] In some embodiments of the method, the local client can address multiple types of CRDT structures (data items).d The request is sent to the local data center of the addressing multi-type CRDT structure. The addressing multi-type CRDT structure can have the current data type; however, the request can have an indication of a data type that does not match the current data type. In this case, the request to the local data center addressing the multi-type CRDT structure is rejected.

[0056] In some embodiments of this application, the multi-type CRDT structure is hosted on a local data center node, and remote copies of the multi-type CRDT structure are hosted on one or more remote data center nodes. According to an embodiment, a message processing function operating at a remote data center node can send an addressing operation request to the local data center node, which will perform an addressing operation associated with the multi-type CRDT structure stored on the local data center node. According to an embodiment, a message processing function operating at the local data center node can send an addressing operation request to one or more remote data center nodes, which will perform an addressing operation associated with the multi-type CRDT structure stored on the local data center node.

[0057] In some embodiments, a remote data center node sends a merge request for data items (i.e., addressed multi-type CRDT structures) stored on other data center nodes associated with the database system. In some embodiments, the merge request may instruct a merge-clear operation. If the request is a merge-clear, 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) may or may not have a data type. If the request is not a merge-clear, the merge request is executed by the application that performs the merge request, thereby correcting the merge into the indicated attribute or optional sub-value associated with the request.

[0058] Figure 4The provided example provides a block timeline diagram illustrating an example of data type conflicts resolved after a CLEAR operation. 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". Correspondingly or simultaneously 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 a multi-type CRDT structure 24 with internal date types: "set" and "string", and internal data values: "{a,b}" and "hello".

[0059] 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. Therefore, African data center node 1 hosts a multi-type CRDT structure 23 with internal date types "set" and "sting", and internal data values ​​"{a,b}" and "hello".

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

[0061] Asia data center node 3 receives message 25 from the local client. This message indicates a CLEAR operation. Upon confirmation and execution of the CLEAR operation, the data type and data value of instance (e.g., data item) 22 are invalidated or cleared. Furthermore, upon completion of the CLEAR operation, the message processing function at Asia data center node 3 generates a message indicating a MERGE-CLEAR operation, which is transmitted to other data centers hosting copies of data item 22. A MERGE-CLEAR operation message is sent to the Europe and Africa data center nodes. Upon receiving this message, instances with data types and data values ​​matching the data type "string" and data value "hello" of data item 22 are invalidated or cleared. Therefore, the multi-type CRDT structure 24 (e.g., data item 24) at Europe data center node 2 is updated to a new instance 27 with only one data type and only one data value. The multi-type CRDT structure 23 (e.g., data item 23) at Africa data center node 1 is updated to a new instance 28 with only one data type and therefore only one data value.

[0062] At this moment, data item replicas 26 to 28 at the three data center nodes 1 to 3 have achieved eventual consistency with the data type "set" and the data value "{a,b}".

[0063] Figure 5The following is a block timeline diagram illustrating an example of non-sequential transmission of attributes resulting in no value, provided for the implementation. Asian data center node 3 hosts data item 30, with a data type defined as "set" and a data value defined as "{a,b}". This data item is transmitted to both European data center node 2 and African data center node 1, where European data center node 2's receipt of the data item results in the creation of data item instance 31, while African data center node 1's receipt results in the creation of data item instance 36. It is important to note the timing difference regarding the reception 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 receiving data item 31, European data center node 2 merges the attribute reflecting 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 the other data center nodes (i.e., European data center node 2 and African data center node 1), where the request merges the TTL-related attribute with the data item received from Asian data center node 3. At Asian data center node 3, the MERGE request results in the creation of data item instance 35. However, as African data center node 1, it receives a MERGE request related to attributes (received from European data center node 2) before receiving the data item from Asian data center node 3. The African data center node considers the MERGE request. Assuming the data item has no value, but the MERGE request is meaningful, African data center node 1 creates data item instance 34. Later, African data center node 1 receives a data item from Asian data center node 3 with an indication that the data type is defined as "set" and the data value is defined as "{a,b}". Therefore, African data center node 1 creates data item instance 36 with a data type defined as "set", a data value defined as "{a,b}", and an attribute TTL defined as "12345". At this point, eventual consistency of the data items exists among each geographically distributed data center node (i.e., Asian data center node 3, European data center node 2, and African data center node 1).

[0064] Figure 6 This is 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 capabilities may be configured as electronic device 600. According to some embodiments, electronic device 600 may correspond to a client portion, such as user equipment (UE), or a data center node, or a data center node providing network access (e.g., gNB), or a message processing function configured as a device and associated with a data center node.

[0065] As shown in the figure, 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-transient mass storage 52; I / O interface 55; network interface 53; and transceivers 56, all of which are communicatively coupled via a bidirectional bus 57. According to some embodiments, any or all of the depicted elements may be used, or only a subset of the elements may be used. Furthermore, device 600 may include multiple instances of certain elements, such as multiple processors, memories, or transceivers. Additionally, elements of the hardware device may be directly coupled to other elements that do not have a bidirectional bus. Besides processors and memory, other electronic components such as integrated circuits may be used to perform the required logical operations.

[0066] 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 combinations thereof. Mass storage element 52 may include any type of non-transitory storage device, such as a solid-state drive, hard disk drive, disk drive, optical disk drive, USB drive, or any computer program product for storing data and machine-executable program code. According to some embodiments, memory 54 or mass storage 52 may have statements and instructions executable by processor 51 recorded on the memory for performing any of the above-described methods.

[0067] It should be understood that although specific embodiments of the technology have been described herein for illustrative purposes, various modifications may be made without departing from the scope of the technology. The specification and drawings are to be considered merely as an illustration of the invention as defined in the appended claims, and any and all modifications, variations, combinations, or equivalents falling within the scope of this specification are contemplated. Within the scope of this technology, a computer program product or program element, or a program storage element or memory device (e.g., magnetic or optical wires, magnetic tape or disk, etc.) is provided for storing machine-readable signals, controlling the operation of a computer according to the method of this technology, and / or constructing some or all of its components according to the system of this technology.

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

[0069] Furthermore, each operation of this method can be executed on any computing device, such as a personal computer, server, PDA, etc., based on one or more program elements, modules, or objects generated from any programming language such as C++, Java, or a portion thereof. Additionally, each operation, or the file or object implementing each operation, can be executed by dedicated hardware or a circuit module designed for this purpose.

[0070] Based on the description of the above embodiments, the present invention can be implemented solely in hardware, or it can be implemented using software and necessary general-purpose hardware platforms. Based on this understanding, the technical solution of the present invention can be embodied in the form of a software product. The software product can be stored in a non-volatile or non-transient storage medium, such as a compact disk read-only memory (CD-ROM), a USB flash drive, or a portable hard drive. The software product includes numerous instructions that enable a computer device (personal computer, server, or network device) to perform the methods provided in the embodiments of the present invention. For example, such execution may correspond to the simulation of logical operations as described herein. According to embodiments of the present invention, the software product may additionally or alternatively include multiple instructions that enable a computer device to perform operations configuring or programming digital logic devices.

[0071] Although the invention has been described with reference to specific features and embodiments thereof, it will be apparent that various modifications and combinations thereof can be made without departing from the invention. The specification and drawings are to be regarded merely as an illustration of the invention as defined in the appended claims and any and all modifications, variations, combinations or equivalents falling within the scope of this specification are to be considered.

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 includes: The message processing function associated with the data center node receives request messages that define requests related to data items, where the data items have no defined data type or have one or more defined data types, wherein the priority order is associated with the one or more data types; The message processing function performs one or more operations based on the evaluation of the request.

2. The method according to claim 1, characterized in that, The execution steps include: The message processing function determines whether the request includes a request to obtain the current type associated with the data item; When it is determined, at least in part, that the data item has a data type based on the priority order, the message processing function reports the data type associated with the data item; When it is determined 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.

3. The method according to claim 1, characterized in that, The execution steps include: The message processing function determines whether the request includes a clear request associated with the data item; When the request is determined to be a clearing 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; The message processing function establishes a merged cleanup message based on the cleanup of the one or more values ​​and the one or more attributes; The message processing function sends a merge and clear request associated with the data item to all other data center nodes in the database system.

4. The method according to claim 1, characterized in that, The execution steps include: When it is determined that the request is not a clear request, the message processing function determines whether the data item has a data type; When it is determined that the data item does not have a data type and the request is meaningful: The message processing function applies changes to the values ​​associated with the data items defined in the request; The message processing function applies changes to the attributes associated with the data item defined in 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.

5. The method according to claim 1, characterized in that, The execution steps include: When it is determined, at least in part, based on the priority order, that the data item has a data type and the current data type associated with the data item matches the data type defined in the request: The message processing function applies changes to the values ​​associated with the data items defined in the request; The message processing function applies changes to the attributes associated with the data item defined in 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.

6. The method according to claim 1, characterized in that, The execution steps include: When, at least in part, the data item is determined to have a data type based on the priority order, and the current data type associated with the data item is different from the data type defined in the request: The message processing function rejects the request.

7. The method according to any one of claims 1 to 6, characterized in that, The request message is associated with a read request.

8. The method according to any one of claims 1 to 6, characterized in that, The data item may include multiple values ​​and multiple data types, wherein the data types are incompatible.

9. A data center node associated with a database system, characterized in that, The data center nodes include: processor; The memory includes machine-executable instructions stored thereon, which, when executed by the processor, cause the data center node to perform the following operations: Receive a request message that defines a data item related to a data item, wherein the data item has no defined data type or has one or more defined data types, wherein the priority order is associated with the one or more data types; One or more operations are performed based on the evaluation of the request.

10. The data center node according to claim 9, characterized in that, When performing one or more operations, the machine-executable instructions, when executed by the processor, also cause the data center node to perform the following operations: Determine whether the request includes a request to obtain the current type associated with the data item; When it is determined at least in part based on the priority order that the data item has a data type, the data type associated with the data item is reported; If it is determined that the data item does not have a data type, report that the data item does not have a data type.

11. The data center node according to claim 9, characterized in that, When performing one or more operations, the machine-executable instructions, when executed by the processor, also cause the data center node to perform the following operations: Determine whether the request includes a clearing request associated with the data item; When the request is determined to be a clearing request: Clear one or more values ​​associated with the data item; Clear one or more attributes associated with the data item; The clearing process establishes a merged clearing message based on the one or more values ​​and the one or more attributes; Send a merge and clear request associated with the data item to all other data center nodes in the database system.

12. The data center node according to claim 9, characterized in that, When performing one or more operations, the machine-executable instructions, when executed by the processor, also cause the data center node to perform the following operations: If it is determined that the request is not a clearing request, it is determined whether the data item has a data type; When it is determined that the data item does not have a data type and the request is meaningful: Apply the change to the value associated with the data item defined in the request; Apply changes to the attributes associated with the data item defined in the request; Send a merge request associated with the data item to all other data center nodes in the database system.

13. The data center node according to claim 9, characterized in that, When performing one or more operations, the machine-executable instructions, when executed by the processor, also cause the data center node to perform the following operations: When it is determined, at least in part, based on the priority order, that the data item has a data type and the current data type associated with the data item matches the data type defined in the request: Apply the change to the value associated with the data item defined in the request; Apply changes to the attributes associated with the data item defined in the request; Send a merge request associated with the data item to all other data center nodes in the database system.

14. The data center node according to claim 9, characterized in that, When performing one or more operations, the machine-executable instructions, when executed by the processor, also cause the data center node to perform the following operations: When, at least in part, the data item is determined to have a data type based on the priority order, and the current data type associated with the data item is different from the data type defined in the request: The request was rejected.

15. The data center node according to any one of claims 9 to 14, characterized in that, The request message is associated with a read request.

16. The data center node according to any one of claims 9 to 14, characterized in that, The data item may include multiple values ​​and multiple data types, wherein the data types are incompatible.

17. A database system, characterized in that, The database system includes: Multiple database center nodes, each of the data center nodes including: processor; The memory includes machine-executable instructions stored thereon, which, when executed by the processor, cause a particular data center node to perform the following operations: Receive a request message that defines a data item related to a data item, wherein the data item has no defined data type or has one or more defined data types, wherein the priority order is associated with the one or more data types; One or more operations are performed based on the evaluation of the request.

18. The database system according to claim 17, characterized in that, When performing one or more operations, the machine-executable instructions, when executed by the processor, also cause the specific data center node to perform the following operations: Determine whether the request includes a request to obtain the current type associated with the data item; When it is determined at least in part based on the priority order that the data item has a data type, the data type associated with the data item is reported; If it is determined that the data item does not have a data type, report that the data item does not have a data type.

19. The database system according to claim 17, characterized in that, When performing one or more operations, the machine-executable instructions, when executed by the processor, also cause the specific data center node to perform the following operations: Determine whether the request includes a clearing request associated with the data item; When the request is determined to be a clearing request: Clear one or more values ​​associated with the data item; Clear one or more attributes associated with the data item; The clearing process establishes a merged clearing message based on the one or more values ​​and the one or more attributes; Send a merge and clear request associated with the data item to all other data center nodes in the database system.

20. The database system according to claim 17, characterized in that, When performing one or more operations, the machine-executable instructions, when executed by the processor, also cause the specific data center node to perform the following operations: If it is determined that the request is not a clearing request, it is determined whether the data item has a data type; When it is determined that the data item does not have a data type and the request is meaningful: Apply the change to the value associated with the data item defined in the request; Apply changes to the attributes associated with the data item defined in the request; Send a merge request associated with the data item to all other data center nodes in the database system.

21. The database system according to claim 17, characterized in that, When performing one or more operations, the machine-executable instructions, when executed by the processor, also cause the specific data center node to perform the following operations: When it is determined, at least in part, based on the priority order, that the data item has a data type and the current data type associated with the data item matches the data type defined in the request: Apply the change to the value associated with the data item defined in the request; Apply changes to the attributes associated with the data item defined in the request; Send a merge request associated with the data item to all other data center nodes in the database system.

22. The database system according to claim 17, characterized in that, When performing one or more operations, the machine-executable instructions, when executed by the processor, also cause the specific data center node to perform the following operations: When, at least in part, the data item is determined to have a data type based on the priority order, and the current data type associated with the data item is different from the data type defined in the request: The request was rejected.

23. The database system according to any one of claims 17 to 22, characterized in that, The request message is associated with a read request.

24. The database system according to any one of claims 17 to 22, characterized in that, The data item may include multiple values ​​and multiple data types, wherein the data types are incompatible.

Images