Sequential parallel unique number generation in a multi-master replication environment
Publication Date: 2017-Jul-13
The IP.com Prior Art Database
Sequential Parallel Unique Number Generation in a Multi-Master Replication Environment
Disclosed is a method to generate user-friendly IDs in a multi-mastered no-Structured Query Language (SQL) database by adding “count documents”, one or more documents that contains one or more numbers.
An existing multi-mastered no-Structured Query Language (SQL) database is based on CouchDB*. For applications transitioning from SQL databases, the transition to a no-SQL database is difficult because not all functions are available. Considering a specific transition example, it is useful to generate unique sequential numbers for documents (records) in the database; however, it is not possible to do so directly in CouchDB**.
A unique, sequential number (rather than an easily-obtained ID, for example) is particularly useful in applications that need to display this number to end users to uniquely identify an object in the application. As an example, an application that scans and displays vulnerabilities of some other application contains a set of vulnerabilities. End users of the application find it easier to refer to vulnerabilities using a low value sequential unique number (e.g., vulnerability number 5) than an automatically generated ID (e.g., vulnerability 56301f3db307849255e623d82c7bab0f). Further, a simple sequential number is preferable when included in human readable representational state transfer (REST) resource uniform resource locators (URLs).
Several mechanisms to generate such a unique, sequential number have been proposed, but all have shortcomings, and none describe a solution with numbers that can correspond to items which will be deleted or a set of sequential numbers. Current approaches do not work in a multi-mastered environment where conflicts can occur. The try and check method is not suitable for an application which uses those numbers as part of a REST resource, because it would result in unpredictability when resolving REST resources, which is fundamentally inconsistent with REST principles. Using a “date” string or timestamp as the unique “number” is cumbersome when the number is to be displayed in the user interface (UI), and the “date” or timestamp is not guaranteed to be unique when two clients running on different systems (such as different servers) make such a request at the same time, or when two clients running on different systems have unsynchronized clocks with a time difference of delta D and the request is made at different times with the same time difference of delta D. A function that works in a single-master environment is unsuitable when there are multiple masters. Deriving the number from the index results in the number changing when the documents in the database are updated; thus, the number is not stable and is again unsuitable to resolve REST resources. Furthermore, none of the methods address reserving a block of numbers. For example, an application that allows multiple clients to simultan...