Mutable object metadata for database replication

Abstract

Systems and methods for asynchronously replicating mutable metadata fields in distributed environments comprise a lineage-based approach, wherein individual changes to metadata fields are stored as timestamped entries in lineage tables that enable efficient tracking and replication of updates. Advantageously, this approach to replicates individual entries independently, allows updates to be replied in any order while maintaining consistency across source and destination systems, and eliminates the need for strict sequencing, synchronization, or exactly-once delivery, which ensured reliability even in active-active configurations or high-latency networks. Metadata queries retrieve the most recent values based on timestamps to ensure consistency and eventual alignment of data between databases. Various embodiments support bidirectional replication, concurrent updates, and error handling, making them suitable for geographically distributed systems, hybrid cloud environments, and disaster recovery applications.

Description

Attorney Docket No. 120179-0589W001MUTABLE OBJECT METADATA FOR DATABASE REPLICATIONBACKGROUNDField

[0001] The present disclosure relates generally to data management in geographically distributed environments, such as networking devices and object storage platforms. More particularly, the present disclosure relates to systems and methods for handling mutable metadata fields while maintaining global consistency and resolving challenges associated with asynchronous replication and active-active configurations.Related Art

[0002] Object storage systems have historically been designed as Write Once, Read Many systems. In such systems, once an object is written, it becomes immutable, and any modification to the object necessitates the creation of a new version of the object. While such approaches are aimed at providing robust data integrity, easy versioning, and straightforward backup and recovery’ processes, they’ introduce significant challenges in cases where metadata fields associated with the object must be updated without altering the object itself or creating a new' version.

[0003] Some object storage systems allow specific metadata fields to be mutable, which introduces complexity, particularly when these changes need to be replicated across distributed storage systems in an asynchronous environment.

[0004] Traditional replication systems, often reliant on synchronization or exactly-once delivery-’ guarantees, struggle to meet the scalability, efficiency, and fault tolerance demands of large-scale distributed environments.

[0005] The challenges of replicating mutable metadata are exacerbated in active-active configurations, where multiple systems can independently update the same metadata fields. Existing approaches frequently depend on mechanisms like message brokers, which can only guarantee at-least-once delivery, resulting in potential duplicate updates. Even with sophisticated brokers, ensuring strict message order, exactly-once guarantees, or low latency is computationally expensive and impractical for high-performance applications,

[0006] Moreover, message brokers cannot control the latency between when a message is published and when it is delivered. This latency is unpredictable and can reach anywhere from milliseconds to orders of magnitude longer, e.g., days.Attorney Docket No. 120179-0589W001

[0007] Accordingly, it is desirable to have methods and systems that can handle mutable metadata fields while, at the same time, ensuring consistency across distributed systems, even under asynchronous replication. Such systems should eliminate dependencies on synchronization, arrival order guarantees, or exactly-once delivery while maintaining eventual consistency, high performance, and scalability.SUMMARY

[0008] In some aspects of the disclosure a method for replicating mutable metadata comprises: generating, for a record comprising a change to a mutable field that is associated with an object, a timestamp that indicates when the change occurred in a first database system, without creating a new version of the object; storing the change in a first set of records associated with the mutable field, the record comprising a value and its corresponding timestamp; querying the first set of records to identify a record having a latest timestamp; asynchronously replicating the record having the latest timestamp from the first database system to a second database system regardless of an order or a timing of the change; storing the record having the latest timestamp in a second set of records at the second database system; and obtaining a current value from the mutable field from tire record having the latest timestamp.

[0009] The first set of records may comprise historical records and may be maintained in chronological order based on timestamps, thereby obviating the need for sorting at the time of querying. Querying may be performed in response to a request for the current value and comprises at least one of maintaining chronological order during insertion, sorting timestamps, or comparing timestamps.

[0010] In some aspects, asynchronously replicating comprises asynchronously transmitting the record without requiring a synchronization, an ordered delivery', or a guarantee of exact delivery' timing. Accordingly, the record may be s tored wi thout regard to an order of arrival or a delivery timing and independently of other metadata fields or object versions.

[0011] In some aspects, the first database system may be a destination database and the second database system may be a source database, both configured to operate in a bidirectional mode. Some aspects further comprise a unique tie-breaker for equal timestamps. The unique tie-breaker may be, e.g., a lowest source bucket identifier.

[0012] In some aspects, a system for replicating mutable metadata comprises: a first database system configured to: generate, without creating a new' version of an object, a timestamp for a record comprising a change to a mutable field associated with the object,Attorney Docket No. 120179-0589W001wherein the timestamp indicates when the change occurred; and store the change in a first set of records associated with the mutable field, the record comprising a value and its corresponding timestamp; a querying module configured to query' the first set of records to identify a record having a latest timestamp; and a replication mechanism configured to asynchronously replicate the record having the latest timestamp from the first database system to a second database system, regardless of an order or timing of the change, tire second database system configured to: store the record having the latest timestamp in a second set of records; and obtain a current value from the mutable field by accessing the record having the latest timestamp.

[0013] The first set of records may' comprise historical records and may' be maintained in chronological order based on timestamps, thereby obviating the need for sorting at the time of querying. Querying may be performed in response to a request for the current value and comprises at least one of maintaining chronological order during insertion, sorting timestamps, or comparing timestamps.

[0014] In some aspects, asynchronously replicating comprises asynchronously transmitting the record without requiring a synchronization, an ordered delivery, or a guarantee of exact delivery timing. Accordingly, the record may be stored without regard to an order of arrival or a delivery' timing and independently' of other metadata fields or object versions.

[0015] In some aspects, the first database system may be a destination database and the second database sy stem may be a source database, both configured to operate in a bidirectional mode. Some aspects further comprise a unique tie-breaker for equal timestamps. The unique tie-breaker may be, e.g., a lowest source bucket identifier.

[0016] Aspects of the present disclosure can involve a system, which can involve means for generating, for a record comprising a change to a mutable field that is associated with an object, a timestamp that indicates when the change occurred in a first database system, without creating a new' version of the object; means for storing the change in a first set of records associated with the mutable field, the record comprising a value and its corresponding timestamp; means for querying the first set of records to identify-' a record having a latest timestamp; means for asynchronously replicating the record having the latest timestamp from the first database system to a second database system regardless of an order or a timing of the change; means for storing the record having the latest timestamp in a second set of records at the second database system; and means for obtaining a current value from the mutable field from the record having the latest timestamp.Attorney Docket No. 120179-0589W001BRIEF DESCRIPTION OF DRAWINGS

[0018] FIG. 1A - FIG. 1C illustrate an exemplary asynchronous replication system according to various embodiments of the present disclosure.

[0019] FIG. 2 illustrates an exemplary- asynchronous replication between source and destination systems according to various embodiments of the present disclosure.

[0020] FIG. 3A and FIG. 3B illustrate an exemplary asynchronous replication between source and destination databases according to various embodiments of the present disclosure.

[0021] FIG. 4 is a flowchart illustrating an exemplary'- process for replicating mutable metadata in accordance with various embodiments of the present disclosure.

[0022] FIG. 5 illustrates an example computing environment according to various embodiments of the present disclosure.Attorney Docket No. 120179-0589W001DETAILED DESCRIPTION

[0023] The following detailed description provides details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term “automatic” may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application. Selection can be conducted by a user through a user interface or other input means, or can be implemented through a desired algorithm. Example implementations as described herein can be utilized either singularly or in combination and the functionality of the example implementations can be implemented through any means according to the desired implementations.

[0024] Some object storage systems allow specific metadata fields, such as “Last Accessed Time,” “Retention Policy,” or “Custom Tags,” to be mutable. These fields are essential tor applications requiring frequent updates to metadata, such as lifecycle management, analytics, and compliance monitoring. However, enabling mutable metadata introduces challenges when changes must be replicated across distributed storage systems. Such challenges include handling high volumes of concurrent updates, ensuring eventual consistency, and avoiding system bottlenecks in geographically distributed environments.

[0025] Existing approaches oftentimes attempt to address this through tight synchronization between systems or by relying on costly exactly-once deliver}' guarantees to maintain metadata consistency. However, such solutions are impractical for large-scale distributed systems due to their high computational overhead and reliance on real-time communication. Such methods can degrade performance, especially under conditions of network latency or frequent disruptions, making them unsuitable for modem distributed systems.

[0026] A typical approach to storing mutable metadata is to store the current value of the fields in a database row that represents the version of the object. While straightforward in design, this approach does not address the complexities introduced by asynchronous replication, where changes can arrive out of order or with significant delays.

[0027] One common approach to replicating these changes is to use a message broker. When the metadata change has been made on the source, a message is published to the broker containing the changed metadata field and its new value. A component at the destinationAttorney Docket No. 120179-0589W001receives messages from the broker and applies the new metadata value on the destination. However, this approach falls short in several ways:

[0028] Traditional replication systems that rely on mechanisms like message brokers typically guarantee only at-least-once delivery, leading to potential duplicate messages and updates. Although some message brokers can alleviate this multi-delivery problem and guarantee exactly-once delivery to maintain consistency, that guarantee is computationally expensive and comes at the cost of high latency, which is unsuitable for latency-sensitive applications. Additionally, since message brokers cannot guarantee the order in which messages are published or delivered. Delivery can occur out-of-order or with variable latency, thus causing inconsistent states across systems. Multiple concurrent publishers and consumers in a typical application, thus, render arrival order guarantees meaningless.

[0029] These challenges are magnified in active-active configurations, where multiple systems independently issue updates to the same metadata fields. Without proper coordination, these updates can result in conflicts or inconsistent states, undermining the system’s reliability and correctness.

[0030] Embodiments herein provide solutions that reconcile conflicting updates in a detenninistic manner, are robust against out-of-order delivery, duplicate updates, and concurrent changes, and address the unique challenges of active-active replication configurations. By eliminating the need for synchronization of certain values, arrival order guarantees, or exactly-once delivery, these embodiments enable distributed systems to achieve eventual consistency.

[0031] FIG. 1A - FIG. 1C illustrate an exemplary' asynchronous replication system according to various embodiments of the present disclosure. In embodiments, system 100 is designed to handle the replication of object metadata, both mutable and immutable, across geographically distributed systems in an asynchronous and scalable manner, ensuring consistency and reliability even under conditions of network latency or out-of-order processing. As depicted, system 100 comprises several components organized into source and destination systems, including source-side object initial metadata table 102, source-side object mutable metadata table 110, destination-side object initial metadata table 160, and destination¬ side object mutable metadata table 170. These tables are implemented in database systems (not shown) at respective source and destination locations to enable tracking of state and history of objects and their associated metadata. System 100 further comprises CDC processor 120, CDC stream processor 124, and replication queue processors 130-136, replication receiver 140, and incoming replication processors 150-154.Attorney Docket No. 120179-0589W001

[0032] In embodiments, source-side object initial metadata table 102 may store initial metadata fields for objects. Initial metadata fields may comprise immutable and mutable fields, including name, version, size, hash, ingest time, access control list (ACL), retention time and legal hold, with immutable metadata fields not being subject to change once writen, whereas mutable metadata fields represent attributes that can change over time, such as access permissions or lifecycle policies.

[0033] As depicted in FIG. 1 A, source-side object mutable metadata table 110 comprises columns for name, version, field, field value, and field time. Each entry in table 110 represents a discrete change to a mutable field, which allows for the construction of a complete history of changes over time. In embodiments, table 110 stores modifications as new entries to facilitate lineage tracking and replication of metadata changes and to maintain a history of those changes. Similarly, destination-side object initial metadata table 160 comprises columns for name, version, size, hash, ingest time, ACL, retention time and legal hold, mirroring the structure and function of source-side object initial metadata table 102, Destination-side object mutable metadata table 170 comprises columns for name, version, field, field value, and field time, replicating the structure of source-side object mutable metadata table 110 and maintaining a lineage of changes for mutable fields at the destination.

[0034] In embodiments, source-side object initial metadata table 102 and source-side object mutable metadata table 110 may be implemented in a database system (not shown). Similarly, destination-side object initial metadata table 160 and destination-side object mutable metadata table 170 ay be implemented in a database system. In short, these tables track the state and history of objects and their associated metadata.

[0035] In embodiments, components for processing and transferring metadata changes comprise CDC processor 12.0, which, together with replication queue 126, may be part of a message broker system that captures updates made to source-side metadata tables 102, 110. In embodiments, CDC processor 120 monitors changes detected, e.g., by a CDC mechanism, generates change records, and streams these records downstream for processing. Exemplary change records may comprise detail such as the affected fields, their updated value, timestamps, the source of the changes, and other information that, may be useful for replication operations. CDC processor 120 is configured to access and read source-side object mutable metadata table 110 and process, e.g., in real-time, each to-be-replicated record having entries associated with an object.

[0036] In embodiments, CDC processor 120 may transmit captured changes associated with metadata tables to CDC stream 122. The changes may then be processed by streamAttorney Docket No. 120179-0589W001processor 124, which organizes and adds them to replication queue 126, which holds metadata changes before they are processed for replication.

[0037] In embodiments, replication queue processors 130-136, depicted in Fig. I B, may operate concurrently to process metadata from replication queue 126 to perform operations in any arbitrary order, i.e., independently from each other. Replication queue processors 130-136 processors retrieve updates from replication queue 126 and prepare them for transfer to a destination system). Advantageously, the ability to process changes concurrently enhances throughput and scalability and allows system 100 to efficiently handle large volumes of updates.

[0038] At tire destination side of system 100, replication receiver 140 may process the data from replication queue processors 130-136 in any provided order to generate incoming replication queue 142. Stated differently, any order that may exist is of no great significance since incoming replication processors 150-154 can also each process incoming data in any arbitrary' order. In embodiments, replication receiver 140 retrieves updates from replication queue processors 130-136 and transfers them to incoming replication queue 142. Incoming replication queue 142 may temporarily hold metadata changes before they are processed by incoming replication processors 150-154 and applied to destination-side tables 160, 170. It is understood that any' number of replication queue processors 130-136 and incoming replication processors 150-154 may be employed to increase throughput, as necessary.

[0039] In embodiments, incoming replication processor 150 ( shown m FIG. IB), obtains an item from incoming replication queue 142 and, e.g,, in response to determining that the item is an object (here, object 2 version 1), enters the object into destination -side object initial metadata table 160 (shown in FIG. 1C). Conversely, incoming replication processor 152 may obtains a metadata item (object 1, ACL update) from incoming replication queue 142 and enter replicates of the item verbatim into destination-side object mutable metadata table 170. It is understood that, in embodiments, where the record already exists no action need be taken. It is further understood that data from incoming replication processors 150 and 152 can arrive in any' order to populate respective destination-side object initial metadata table 160 and source¬ side object mutable metadata table 170. As shown in FIG. 1C, table 170 comprises “object 2,” which has not yet been created in table 160. This affords great flexibility' because system 100 is not dependent on a strict sequence of operations or the prior existence of related data in the destination tables. For example, an update to a mutable metadata field, such as an ACL modification, can be processed and inserted into the destination-side object mutable metadata table 170 even if the corresponding immutable metadata entry in destination-side object initialAttorney Docket No. 120179-0589W001metadata table 160 has not yet been created. This asynchronous and decoupled processing allows the system to handle high volumes of updates concurrently without being constrained by dependencies between related data entries.

[0040] Such flexibility is particularly advantageous in active-active configurations, where updates may originate simultaneously from multiple systems or regions. By allowing updates to be processed and applied independently; the system ensures that all changes are captured and replicated accurately, regardless of the order in which they are received or processed. This design significantly improves scalability and resilience, as it avoids bottlenecks that could arise from requiring strict synchronization or sequential processing of related data.

[0041] Additionally, this flexibility simplifies error handling and recovery. If a metadata update arrives before its associated object entry, the system can simply defer any dependent operations until the missing data is eventually replicated. This approach ensures eventual consistency across source and destination systems without requiring complex coordination mechanisms or real-time synchronization.

[0042] As depicted, source-side object mutable metadata table 110 comprises a history' of changes to an object, allowing fortracking and replication of mutable fields. Overtime, lineage tables may be deleted after a certain retention period to manage storage overhead.

[0043] Records in source-side object mutable metadata table 110 may be stored in a sorted fashion, such as to ensure that the most recent entry is always at the top (or bottom) of the table. This sorting simplifies querying for the latest value and facilitates efficient replication, as the ordering guarantees that changes can be identified and applied with minimal processing.

[0044] In embodiments, rather than storing mutable metadata fields along with a row' representing the object version, metadata values for each mutable field may be derived from a replicated historical lineage of records. Each lineage entry represents a specific value assigned to the field along with the time at which the change was applied. By maintaining this lineage in a time-ordered structure, queries tor the most recent value can efficiently retrieve the correct metadata for the corresponding object version. For example, when a field value is updated, a new lineage entry’ is created, recording the updated value and its associated timestamp. This approach ensures that querying the metadata for an object version consistently returns the latest value for that field.

[0045] For example, for an object (Object A) comprising Mutable Field 1, Mutable Field 2, and Immutable Field 1, the following lineage demonstrates the evolution of Mutable Field 1 overtime:

[0046] Object A Mutable Field 1: Value 2, Applied Time: 5- o -Attorney Docket No. 120179-0589W001

[0047] Object A Mutable Field 1: Value 1, Applied Time: 4

[0048] Object A Mutable Field 1: Value 2, Applied Time: 3

[0049] Object A Mutable Field 1: Value 15, Applied Time: 2

[0050] In this example, querying the lineage for Mutable Field 1 retrieves the most recent value. Value 2 at Applied Time 5, as the current value. Tliis method ensures that changes are preserved and that the system can reconstruct the historical state of metadata fields as needed.

[0051] In embodiments, replication involves copying individual lineage records verbatim between systems, e.g., from a source database to a destination database. Both systems may independently sort the lineage records by their timestamps, ensuring that the entry with the latest timestamp is recognized as the “current” value. Advantageously, by replicating lineage records in this manner, updates can be processed and applied in any order, as long as all records eventually reach their destination. Tliis guarantees that both systems agree on the current value and the historical values for each mutable metadata field, significantly simplifying the replication process for mutable metadata.

[0052] In embodiments, lineage records may be published to a common at-least-once message broker in any order, and they may be delivered in any order. Unlike in existing systems, the time it takes for the message to be delivered becomes immaterial when delivering an individual lineage record, as the lineage-based design ensures that the records can be processed in any sequence. Similarly, whether a newer lineage record has already been delivered does not create a problem. Additionally, this schema supports bidirectional replication even when source and destination databases are capable of mutating fields concurrently since the lineage guarantees eventual consistency on both sides. In embodiments, replication queue processors 130-136 operate concurrently to process metadata from replication queue 126.

[0053] Although embodiments herein are framed m the context of active-active replication methods, one skilled in the art shall recognize that the concepts of lineage-based metadata management are not limited to such configurations and may equally be applied in other contexts, including disaster recover}-, hybrid cloud environments, and other distributed environments requiring reliable, consistent metadata replication.

[0054] FIG. 2 illustrates an exemplary asynchronous replication between source and destination systems according to various embodiments of the present disclosure. The example m FIG. 2 demonstrates the lineage-based approach to replicating metadata and how changes to mutable fields, such as “legal hold,” are handled across source and destination systems. Source side 200 in FIG. 2 comprises object table 202 and lineage table 204; and destinationAttorney Docket No. 120179-0589W001side 250 comprises object table 252 and lineage table 254. Object tables 202 and 252 comprise columns name, dime (create time), legal hold, size, and type (file type); and lineage tables 204 and 254 comprise columns for name, field, value, and apply time, which represents the specific clock time at which a change is applied.

[0055] As depicted, the field “legal hold,” which is the only mutable field in object tables 202 and 252, and is initially not set. It is understood that, for demonstration purposes, this field is used as a representative mutable field that may change without creating a new object version. However, the system is equally applicable to other mutable fields that may behave in a similar manner. Immutable fields, such as access control list (shown in FIG. 1A), which can also be changed without affecting object versions, are not considered in this example.

[0056] In operation, lineage table 204 is initially empty, e.g., until a value is set for legal hold. For example, if a legal hold is placed with an apply time of 10 (an arbitrary unit having a value chosen to be greater than the create time of 5), lineage table 204 is updated to reflect this change.

[0057] If source 200 queries the metadata in lineage table 204 at this stage, the result tor “legal hold” would correctly return the value “true.” In contrast, at this point, destination 250 would return no result since bot object table 252 and lineage table 254 are initially empty.

[0058] It is noted that if an entry from lineage table 204 were replicated to lineage table 254 before the corresponding entry from object table 202 is replicated to object table 252, querying destination 250 for legal hold would produce no result because the object entry in table 252 does not yet exist. Conversely, if an entry from object table 202 is replicated to object table 252 before the corresponding entry' from lineage table 204 is replicated to lineage table 254, querying destination 250 would yield results consistent with lineage table 204 once the replication process completes. As a result, regardless of the replication sequence of individual entries, the system ensures that the final state of the replicated data aligns with the source after all related entries are replicated. For example, once object 1 is replicated from source 200 to destination 250, the state of object 1 can be ascertained from replicated lineage table 254, producing the same query’ result as for source 200.

[0059] Assuming, as indicated in the last row of lineage table 204, “legal hold” is subsequently changed back to “false” at the source, with an apply time of 15 (again, a value greater than the create time of 5), lineage table 204 is updated with a new entry reflecting this change. Once the replication process completes, lineage table 254 at the destination is also updated. Querying destination 250 at this point would then correctly return “false” for “legal hold,” since the latest entry in lineage table 254 is identified as having the most recent applyAttorney Docket No. 120179-0589W001time. This process ensures that source 200 and destination 250 systems maintain consistency and agree on the current and historical values of the mutable field. Advantageously, this asynchronous replication embodiment eliminates the need for strict sequencing and synchronization, thereby enabling updates to be applied in any order while maintaining eventual consistency.

[0060] It is understood that, in active-active embodiments, unlike m existing designs, both source 200 and destination 250 can apply a replication process in a bi-directional manner. As a result, changes made at destination 250 can be replicated back to source 200, thus ensuring that the lineage of changes is fully resolved and consistent across both systems.

[0061] FIG. 3A and FIG. 3B illustrate an exemplary asynchronous replication between source and destination databases according to various embodiments of the present disclosure. For clarity, components similar to those shown in FIG. 1 A through FIG. 1C are labeled in the same manner. For purposes of brevity, a description or their function is not repeated here. System 300 comprises source database 302, CDC processor 120; CDC stream 122; stream processor 124; replication queue processor 130; replication receiver 140; incoming replication queue 142; incoming replication processor 154; and destination database 304. It is understood that, in embodiments, any of, e.g., CDC processor 120, CDC stream processor 124, and replication queue processor 130, or their combination, may be integrated into one or more components, without deviating from the scope of the present disclosure.

[0062] In operation, CDC processor 120; CDC stream 122; stream processor 12.4; replication queue processor 130 may be executed different computing systems. In embodiments, all elements in FIG. 3A may be located in a geographically distinct, region (denoted as Region 1) from the components in FIG. 3B (denoted as Region 2), with the two regions being communicatively coupled to each other via the internet or any other WAN. However, this is not intended as a limitation on the scope of the present disclosure since, for example, source database 302 and destination database 304 may reside within the same data center to enable localized replication with reduced network overhead.

[0063] FIG. 4 is a flowchart illustrating an exemplary process for replicating mutable metadata in accordance with various embodiments of the present, disclosure.

[0064] Process 400 may start at step 402, when, for a record comprising a change to a mutable field that is associated with an object, a timestamp that indicates when tire change occurred in a first database system, is generated without creating a new version of the object.

[0065] At step 404, the change may be stored in a first set of records associated with the mutable field. The record may comprise a value and its corresponding timestamp.Attorney Docket No. 120179-0589W001

[0066] At step 406, the first set of records may be queried to identify a record having a iatest timestamp.

[0067] At step 408, the record having the latest timestamp may be asynchronously replicated from the first database system to a second database system regardless of an order or a timing of the change.

[0068] At step 410, the record having the latest timestamp may be stored in a second set of records at the second database system.

[0069] Finally, at step 412, a current value may be obtained using the mutable field from the record that has the latest timestamp.

[0070] One skilled in the art shall recognize that: (1) certain steps may optionally be performed; (2) steps may not be limited to the specific order set forth herein; (3) certain steps may be performed in different orders; and (4) certain steps may be done concurrently.

[0071] FIG. 5 illustrates an example computing environment with an example computer device suitable for use in some example implementations according to various embodiments of the present disclosure.

[0072] Computer device 505 in computing environment 500 can include one or more processing units, cores, or processors 510, memory 515 (e.g., RAM, ROM, and / or the like), internal storage 520 (e.g., magnetic, optical, solid-state storage, and / or organic), and / or I / O interface 525, any of which can be coupled on a communication mechanism or bus 530 for communicating information or embedded in the computer device 505. I / O interface 525 is also configured to receive images from cameras or provide images to projectors or displays, depending on the desired implementation.

[0073] Computer device 505 can be communicatively coupled to input / user interface 535 and output device / interface 540. Either one or both of input / user interface 535 and output device / interface 540 can be a wired or wireless interface and can be detachable. Input / user interface 535 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch-screen interface, keyboard, a pointing / cursor control, microphone, camera, braille, motion sensor, optical reader, and / or the like). Output device / interface 540 may include a display, television, monitor, printer, speaker, braille, or the like. In some example implementations, input / user interface 535 and output device / interface 540 can be embedded with or physically coupled to the computer device 505. In other example implementations, other computer devices may function as or provide the functions of input / user interface 535 and output device / interface 540 for a computer device 505.Attorney Docket No. 120179-0589W001

[0074] Examples of computer device 505 may include highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and / or coupled thereto, radios, and the like).

[0075] Computer device 505 can be communicatively coupled (e.g., via I / O interface 525) to external storage 545 and network 550 for communicating with any number of networked components, devices, and systems, including one or more computer devices of the same or different configurations. Computer device 505 or any connected computer device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special -purpose machine, or another label.

[0076] I / O interface 525 can include wired and / or wireless interfaces using any communication or I / O protocols or standards (e.g., Ethernet, 802.1 lx. Universal System Bus, WiMax, modem, a cellular network protocol, and the like) for communicating information to and / or from at least all the connected components, devices, and network in computing environment 500. Network 550 can be any network or combination of networks (e.g., the Internet, local area network, wide area network, a telephonic network, a cellular network, a satellite network, and the like).

[0077] Computer device 505 can use and / or communicate using computer-usable or computer-readable media, including transitory media and non-transitory media. Transitory media include transmission media (e.g., metal cables, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid-state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.

[0078] Computer device 505 can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some example computing environments. Computer-executable instructions can be retrieved from transitory' media, and stored on and retrieved from non-transitory media. The executable instructions can originate from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).

[0079] Processor(s) 510 can execute under any operating system (OS) (not shown), in a native or virtual environment. One or more applications can be deployed that include logic unit 560, application programming interface (API) unit 565, input unit 570, output unit 575,Attorney Docket No. 120179-0589W001and inter-unit communication mechanism 595 for the different units to communicate with each other, with the OS, and with other applications (not shown). The described units and elements can be varied in design, function, configuration, or implementation and are not limited to the descriptions provided. Processor(s) 510 can be in the fonn of hardware processors such as central processing units (CPUs) or a combination of hardware and software units.

[0080] In some example implementations, when information or an execution instruction is received by API unit 565, it may be communicated to one or more other units (e.g., logic unit 560, input unit 570, output unit 575). In some instances, logic unit 560 may be configured to control tlie information flow among the units and direct the services provided by API unit 565, input unit 570, and output unit 575, in some example implementations described above. For example, the flow of one or more processes or implementations may be controlled by logic unit 560 alone or in conjunction with API unit 565. Hie input unit 570 may be configured to obtain input for the calculations described in the example implementations, and the output unit 575 may be configured to provide output based on the calculations described in example implementati ons.0081 Processor(s) 510 can be configured to execute a method or computer instructions which can involve generating, for a record comprising a change to a mutable field that is associated with an object, a timestamp that indicates when the change occurred m a first database system, without creating a new version of the object. The change may be stored in a first set of records associated with the mutable field, the record comprising a value and its corresponding timestamp, as described, for example, with respect to FIG. I A - FIG. IB, and FIG. 2.0082] Processor(s) 510 can be configured to execute a method or computer instructions which can involve querying the first set of records to identify a record having a late st time stamp and asynchronously replicating the record having the latest timestamp from the first database system to a second database system regardless of an order or a timing of the change, as described, for example, with respect to FIG. 1A - FIG. IB and FIG. 4.

[0083] Processor(s) 10 can be configured to execute a method or computer instructions which can involve storing the record having the latest timestamp in a second set of records at the second database system, and obtaining a current value from the mutable field from the record having the latest timestamp,, as described, for example, with respect to FIG. 3A - FIG.3B and FIG. 4.

[0084] Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions andAttorney Docket No. 120179-0589W001symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities to achieve a tangible result.0085] Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system’s registers and memories into other data similarly represented as physical quantities within the computer system’s memories or registers or other information storage, transmission or display devices.[0086 Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer- readable medium, such as a computer-readable storage medium or a computer-readable signal medium, A computer-readable storage medium may involve tangible mediums such as optical disks, magnetic disks, read-only memories, random access memories, solid-state devices, drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer-readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.

[0087] Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the techniques of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.

[0088] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of theAttorney Docket No. 120179-0589W001example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine -readable medium (software), which if executed by a processor, would cause the processor to perform a method to cany' out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general-purpose computer, based on instructions stored on a computer-readable mediu. If desired, the instructions can be stored on the medium in a compressed and / or encrypted format.0089] Moreover, oilier implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the techniques of the present application. Various aspects and / or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.

Claims

Attorney Docket No. 120179-0589W001CLAIMSWhat is claimed is:

1. A method for replicating mutable metadata, the method comprising: generating, for a record comprising a change to a mutable field that is associated with an object, a timestamp that indicates when the change occurred in a first database system, without creating a new version of the object;storing the change in a first set of records associated with the mutable field, the record comprising a value and its corresponding timestamp;querying the first set of records to identify a record having a latest timestamp; asynchronously replicating the record having the latest timestamp from the first database system to a second database system regardless of an order or a timing of the change;storing the record having the latest timestamp in a second set of records at the second database system; andobtaining a current value from the mutable field from the record having the latest timestamp.

2. The method according to claim 1, wherein the first set of records comprises historical records and is maintained in chronological order based on timestamps, thereby obviating the need for sorting at the time of querying.

3. lire method according to claim 1, wherein asynchronously replicating comprises asynchronously transmitting the record without requiring a synchronization, an ordered delivery, or a guarantee of exact delivery' timing.

4. The method according to claim 1, wherein querying is performed in response to a request for the current value and comprises at least one of maintaining chronological order during insertion, sorting timestamps, or comparing timestamps.

5. The method according to claim 1, wherein storing the record is performed without regard to an order of arrival or a delivery timing and independently of other metadata fields or object versions.

6. The method according to claim 1, wherein the first database system is a destination database and the second database system is a source database both configured to operate in a bidirectional mode.

7. The method according to claim 1, further comprising a unique tie-breaker for equal timestamps.Attorney Docket No. 120179-0589W0018. The method according to claim 7 wherein the unique tie-breaker is a lowest source bucket identifier.b A system for replicating mutable metadata, the system comprising:a first database system configured to:generate, without creating a new version of an object, a timestamp for a record comprising a change to a mutable field associated with the object, wherein the timestamp indicates when the change occurred; andstore the change in a first set of records associated with the mutable field, the record comprising a value and its corresponding timestamp; a querying module configured to query the first set of records to identify a record having a latest timestamp; anda replication mechanism configured to asynchronously replicate the record having the latest timestamp from the first database system to a second database system, regardless of an order or timing of the change, the second database system configured to:store the record having the latest timestamp in a second set of records; and obtain a current value from the mutable field by accessing the record having the latest timestamp.

10. The system of claim 9, wherein the first set of records is maintained in chronological order based on timestamps, thereby obviating the need for sorting at the time of querying,11. Tire system of claim 9, wherein the replication mechanism is configured to asynchronously transmit the record without requiring synchronization, ordered delivery, or a guarantee of exact delivery timing.

12. The system of claim 9, wherein the first database system and the second database system are configured to operate in a bidirectional mode to enable records to be replicated in both directions.

13. The system of claim 9, further comprising a unique tie-breaker mechanism for resolving equal timestamps between records.

14. The system of claim 13, wherein the unique tie-breaker mechanism is configured to select a record based on a lowest source bucket identifier.

15. The system of claim 1, wherein the querying module is configured to perform querying in response to a request for the current value and comprises at least one ofAttorney Docket No. 120179-0589W001maintaining chronological order during insertion, sorting timestamps, or comparing timestamps.

Images