Microsoft Technology Licensing, LLC

Mikhail Mikhailovich Koltachev

Dharma Kiritkumar Shukla

Karthik Raman

Momin Mahmoud Al-Ghosien

Shireesh Kumar Thota

Madhan Gajendran

Pankaj Sharma

Ankur Savailal Shah

Ji Huang

Atul Katiyar

Bhalakumaaran Erode Ranganathan

Sujit Vattathil Kuruvilla

Shreshth Singhal

Ovidiu Constantin Platon

Digvijaysinh Govindbhai Makwana

Subramanyam Pattipaka

Hari Sudan Sundar

Samer Boshra

Liang Li

Adrian Ilcu Predescu

Krishnan Sundaram

Brandon Chong

Aravind Ramachandran Krishna

Karan Vishwanath Popali

Nikhil Khandelwal

Jayanta Mondal

Akrosh Gandhi

Vinod Sridharan

Oliver Drew Leonard Towers

Siddhesh Dilip Vethe

Emily Lawton

Orestis Kostakis

Balachandar Perumalswamy

Vivek Ravindran

Ashwini Singh

A server set for a data set may designate a subset of 'master' servers that update the data set in order to reduce data version conflicts involving mutually exclusive updates of the data set. Multi-master configurations may fulfill the performance constraints, and the subset of masters may detect and resolve data version conflicts. However, if multiple masters perform conflict resolution for a particular data version conflict, the resolution may produce inefficiency and redundancy (if the masters reach the same outcome) or additional data version conflicts (if the masters reach different outcomes). Instead, among the masters, a merge master may be identified that applies conflict resolution techniques to data version conflicts and forwards the conflict resolution outcome to the other masters for application to the data set to resolve the data version conflict. The other masters may temporarily store updates in a tentative update set until data version conflicts are resolved.

Merging conflict resolution for multi-master distributed databases

Data services for workloads are often provided with a service level agreement specifying various performance guarantees (e.g., latency, availability, scalability, and consistency). Single-master architectures, in which updates to the data set are constrained to a single server, may limit the fulfillment of some performance guarantees. Presented herein are multi-master architectures, in which the server set is partitioned into at least two masters are permitted to update the data set and at least one non-master that is not permitted to update the data set. Non-masters that receive a request to update the data set forward the request to a master server for application to the data set. A master that receives the request applies it to the data set and propagates the update to other master and non-master servers. Conflicting updates may be resolved through a variety of conflict resolution techniques, optionally designating one master server as a conflict resolution server.

Multi-master architectures for distributed databases

Data services are often provided with various performance guarantees. Multi-master architectures, in which multiple master servers are permitted to update a portion of the data set, may facilitate some performance requirements, but may also lead to data version conflicts in which different masters have written different versions of one or more data items. Moreover, conflicts involving different data items may have to be resolved using different conflict resolution techniques. Therefore, various data items of the data set may be associated with a conflict resolution technique selected from a conflict resolution technique set, such as manual conflict resolution; a write order policy, such as last writer wins; a conflict resolution logic; and conflict resolution based on data types. A data version conflict may be resolved by identifying and invoking the selected conflict resolution technique that is associated with the data item, and applying the conflict resolution outcome to the data item.

Conflict resolution for multi-master distributed databases

Data sets such as databases are often distributed over a number of servers, where each server stores a subset of records and an index that enables the server to locate the records in response to queries. However, tight coupling of indexing and storage may limit load-balancing, fault recovery, and distribution. Instead, the set of servers may be partitioned into a set of storage servers that store the records and a set of index servers of the index over the records. In a set that is decoupled in this manner, load-balancing may involve provisioning and locating index servers independently of the provisioning and locating of the storage servers in view of the particular sensitivities and tolerances of various applications. Additionally, the index servers may also utilize a data layout that is selected and adapted independent of the data layout of the storage servers and/or the schema of the data stored thereby.

Schema-agnostic indexing of distributed databases

Databases are often provided according to various organizational models (e.g., document-oriented storage, key/value stores, and relational database), and are accessed through various access models (e.g., SQL, XPath, and schemaless queries). As data is shared across sources and applications, the dependency of a data service upon a particular organizational and/or access models may become confining. Instead, data services may store data in a base representation format, such as an atom-record-sequence model. New data received in a native item format may be converted into the base representation format for storage, and converted into a requested format to fulfill data requests. Queries may be translated from a native query format into a base query format that is applicable to the base representation format of the data set, e.g., via translation into an query intermediate language (such as JavaScript) and compilation into opcodes that are executed by a virtual machine within the database engine.

Unified data organization for multi-model distributed databases

A dual-mode debugger can debug native code or interpreted code. Transitioning between modes can be triggered by defined bailout conditions. A program can be debugged by attaching a debugger and compiling the program into native code under the debugger. At defined points in the program, debugging can transition from native mode to interpreted mode. Debugging the native code can stop, current state can be captured, and an interpreter can be instantiated. An interpreter stack can be created and can be populated with the captured current state. Debugging operations which involve execution control: pausing execution, continuing execution, stepping into, out of or over a section of code and so on, can occur in interpreted mode, which is typically easier to implement. Debugging operations which involve inspection and modification of variables can occur in native mode.

Debugging native code by transitioning from execution in native mode to execution in interpreted mode

Growing community of inventors

Redmond, WA, United States of America

Mikhail Mikhailovich Koltachev