Abstract: Techniques are disclosed relating to managing distributed storage of data with low latency access and durable storage. A distributed storage system may include storage caches distributed across availability zones in front of a shared object storage. Database nodes collocated with the storage caches may handle the storage, retrieval, and manipulation of data in the storage caches and the shared object storage. The shared object storage cache provides persistent storage of data for the distributed storage system while storage of the data in the storage caches is implemented to provide low latency retrieval of the storage. The storage caches across the availability zones may be populated through the shared object storage rather than moving data across availability zones.

Abstract: Techniques are disclosed relating to efficiently processing of concurrent database transactions. In one embodiment, a database system receives a first key-value pair for a database transaction and stores the key-value pair in a data structure for active database transactions. The storing may include indexing into a hash table of the data structure with a key of the key-value pair to identify a hash bucket of the hash table corresponding to the key, acquiring a latch associated with the identified hash bucket, and, based on a state of the acquired latch, appending, to the hash bucket, a record specifying the key-value pair. The database system may cause the key-value pair from the data structure to be committed to persistent storage in response to the database transaction being committed.

Abstract: Techniques are disclosed relating to tracking record writes for keyspaces across a set of database nodes. A first database node of a database system may receive a request to perform a database transaction that includes writing a particular record for a key included in a keyspace. The first database node may access a keyspace reference catalog that stores a plurality of indications of when keyspaces were written to by database nodes of the database system. In response to determining that a second database node has written a record for the keyspace within a particular time frame, the first database node may send a request to the second database node for information indicating whether the second database node has written a record for the key. Based on a response that is received from the second database node, the first database node may determine whether to write the particular record.

Abstract: Techniques are disclosed relating to the distribution of database key permissions. A database system may distribute first permission information to a plurality of database nodes that identifies a distribution of key range permissions to ones of the plurality of database nodes. A given key range permission being distributed to a given database node may permit that database node to write records whose keys fall within a key range associated with the given key range permission. The database system may receive, from a first database node, a request for a first key range permission provisioned to a second database node. The database system may modify the first permission information to derive second permission information that provisions the first key range permission to the first database node instead of the second database node. The database system may distribute the second permission information to ones of the plurality of database nodes.

Abstract: In accordance with embodiments, there are provided mechanisms and methods for facilitating dynamically unified system of record in an on-demand services environment in a multi-tenant environment according to one embodiment. In one embodiment and by way of example, a method includes integrating, by and incorporating into the database system, a plurality of subsystems into a unified system of record (“unified system), where each subsystem is independent of and incompatible with other subsystems of the plurality of subsystems, and collectively managing the plurality of subsystems, where collectively managing includes facilitating common communication within and between and uniform management of the plurality of subsystems based on common communication criteria and unified storage of data associated with the plurality of subsystems.

Abstract: Techniques are disclosed relating to tree data structures capable of storing information indicative of database keys. A computer system may operate a database. The computer system may store a multi-level tree data structure usable to perform key lookups for the database. In various cases, the multi-level tree data structure may be stored in system memory as a plurality of subtree data structures each comprising a set of linked nodes. A given one of the plurality of subtree data structures may be stored as a respective continuous block of information in system memory. The computer system may access the respective continuous block for a first particular subtree data structure encompassing a particular range of levels in the multi-level tree data structure. The accessing may be performed without accessing one or more other subtree data structures encompassing one or more levels within the particular range of levels.

Abstract: Systems and methods are provided for performing a point-in-time restore of data of a first tenant of a multitenanted database system. Metadata can be located to identify an archival version of first data of the first tenant stored in immutable storage of the database system. The archival version includes a most recently committed version of each datum prior to a first point in time. By using the metadata, a restore reference set is mapped into a target database instance of the database system. The mapping can be performed when all existing data for a tenant is to be the archival version, and where versions of data and records committed after the point in time are not available to the target database instance.

Abstract: This disclosure provides various techniques that may allow for accessing values stored in a data structure that stores multiple values corresponding to database transactions using a skip list. A key may be used to traverse the skip list to access data associated with the key. The skip list maintains on ordering of multiple keys, each associated with a particular record in the data structure, using indirect links between data records in the data structure that reference buckets included in hash table. Each bucket includes pointers to one or more records in the skip list.

Abstract: In accordance with embodiments, there are provided mechanisms and methods for facilitating dynamically unified system of record in an on-demand services environment in a multi-tenant environment according to one embodiment. In one embodiment and by way of example, a method includes integrating, by and incorporating into the database system, a plurality of subsystems into a unified system of record (“unified system), where each subsystem is independent of and incompatible with other subsystems of the plurality of subsystems, and collectively managing the plurality of subsystems, where collectively managing includes facilitating common communication within and between and uniform management of the plurality of subsystems based on common communication criteria and unified storage of data associated with the plurality of subsystems.

Abstract: Systems and methods are provided for creating a sandbox for an original tenant at a point in time, the original tenant having original tenant data stored in an immutable storage associated with an original tenant identifier, the original tenant data as of the sandbox creation point in time being a virtual snapshot of the original tenant data accessible by a sandbox tenant, where the sandbox tenant data can be changed without changing the original tenant data, and the original tenant data can be changed without changing the sandbox tenant data. A sandbox tenant is created by associating a sandbox tenant identifier with the virtual snapshot of the original tenant data and with sandbox tenant data created by the sandbox tenant subsequent to the sandbox creation point in time. In some implementations, the original tenant is an original sandbox tenant, and the sandbox tenant is at least one new sandbox tenant.

Abstract: This disclosure provides various techniques that may allow for accessing values stored in a data structure that stores multiple values corresponding to database transactions using a skip list. A key may be used to traverse the skip list to access data associated with the key. The skip list maintains on ordering of multiple keys, each associated with a particular record in the data structure, using indirect links between data records in the data structure that reference buckets included in hash table. Each bucket includes pointers to one or more records in the skip list.

Abstract: Systems and methods are provided for performing a point-in-time restore of data of a first tenant of a multitenanted database system. Metadata can be located to identify an archival version of first data of the first tenant stored in immutable storage of the database system. The archival version includes a most recently committed version of each datum prior to a first point in time. By using the metadata, a restore reference set is mapped into a target database instance of the database system. The mapping can be performed when all existing data for a tenant is to be the archival version, and where versions of data and records committed after the point in time are not available to the target database instance.

Abstract: Systems and methods are provided for creating a sandbox for an original tenant at a point in time, the original tenant having original tenant data stored in an immutable storage associated with an original tenant identifier, the original tenant data as of the sandbox creation point in time being a virtual snapshot of the original tenant data accessible by a sandbox tenant, where the sandbox tenant data can be changed without changing the original tenant data, and the original tenant data can be changed without changing the sandbox tenant data. A sandbox tenant is created by associating a sandbox tenant identifier with the virtual snapshot of the original tenant data and with sandbox tenant data created by the sandbox tenant subsequent to the sandbox creation point in time. In some implementations, the original tenant is an original sandbox tenant, and the sandbox tenant is at least one new sandbox tenant.

Abstract: Systems and methods are provided for performing a point-in-time restore of data of a first tenant of a multitenanted database system. Metadata can be located to identify an archival version of first data of the first tenant stored in immutable storage of the database system. The archival version includes a most recently committed version of each datum prior to a first point in time. By using the metadata, a restore reference set is mapped into a target database instance of the database system. The mapping can be performed when all existing data for a tenant is to be the archival version, and where versions of data and records committed after the point in time are not available to the target database instance.

Abstract: Systems and methods provide multi-version concurrency control of database records with uncommitted transactions. The system and methods may include receiving a query regarding a transaction counter number. When a transaction header identifying data is updated with the assigned transaction counter number, the updated transaction header may be used in identifying data as an instance of multiversion concurrency control information by the received query. A key lookup may be performed, and when the key lookup encounters an uncommitted row for a transaction number, a corresponding transaction header identifying data to identify a data array element to determine whether the transaction number is committed, and determining the transaction counter number when the transaction number is committed. The transaction counter number may be stamped on the row version record when it is determined that the row is committed.

Abstract: Systems and methods provide multi-version concurrency control of database records with uncommitted transactions. The system and methods may include receiving a query regarding a transaction counter number. When a transaction header identifying data is updated with the assigned transaction counter number, the updated transaction header may be used in identifying data as an instance of multiversion concurrency control information by the received query. A key lookup may be performed, and when the key lookup encounters an uncommitted row for a transaction number, a corresponding transaction header identifying data to identify a data array element to determine whether the transaction number is committed, and determining the transaction counter number when the transaction number is committed. The transaction counter number may be stamped on the row version record when it is determined that the row is committed.

Abstract: Systems and methods are provided for creating a sandbox for an original tenant at a point in time, the original tenant having original tenant data stored in an immutable storage associated with an original tenant identifier, the original tenant data as of the sandbox creation point in time being a virtual snapshot of the original tenant data accessible by a sandbox tenant, where the sandbox tenant data can be changed without changing the original tenant data, and the original tenant data can be changed without changing the sandbox tenant data. A sandbox tenant is created by associating a sandbox tenant identifier with the virtual snapshot of the original tenant data and with sandbox tenant data created by the sandbox tenant subsequent to the sandbox creation point in time. Original tenant data is subsequently created and associated with the original tenant identifier, and is not accessible to the sandbox tenant.

Abstract: Systems and methods are provided for creating a sandbox for an original tenant at a point in time, the original tenant having original tenant data stored in an immutable storage associated with an original tenant identifier, the original tenant data as of the sandbox creation point in time being a virtual snapshot of the original tenant data accessible by a sandbox tenant, where the sandbox tenant data can be changed without changing the original tenant data, and the original tenant data can be changed without changing the sandbox tenant data. A sandbox tenant is created by associating a sandbox tenant identifier with the virtual snapshot of the original tenant data and with sandbox tenant data created by the sandbox tenant subsequent to the sandbox creation point in time. Original tenant data is subsequently created and associated with the original tenant identifier, and is not accessible to the sandbox tenant.

Abstract: Systems and methods are provided for creating a sandbox for an original tenant at a point in time, the original tenant having original tenant data stored in an immutable storage associated with an original tenant identifier, the original tenant data as of the sandbox creation point in time being a virtual snapshot of the original tenant data accessible by a sandbox tenant, where the sandbox tenant data can be changed without changing the original tenant data, and the original tenant data can be changed without changing the sandbox tenant data. A sandbox tenant is created by associating a sandbox tenant identifier with the virtual snapshot of the original tenant data and with sandbox tenant data created by the sandbox tenant subsequent to the sandbox creation point in time. In some implementations, the original tenant is an original sandbox tenant, and the sandbox tenant is at least one new sandbox tenant.

Abstract: Systems and methods are provided for performing a point-in-time restore of data of a first tenant of a multitenanted database system. Metadata can be located to identify an archival version of first data of the first tenant stored in immutable storage of the database system. The archival version includes a most recently committed version of each datum prior to a first point in time. By using the metadata, a restore reference set is mapped into a target database instance of the database system. The mapping can be performed when all existing data for a tenant is to be the archival version, and where versions of data and records committed after the point in time are not available to the target database instance.