Salesforce Com, Inc.

Salesforce, Inc.

International Business Machines Corporation

Sybase, Inc.

Jameison Bear Martin

Thomas Fanghaenel

Terry Chong

Nathaniel Wyatt

Patrick James Helland

Subho Sanjay Chatterjee

Atish Agrawal

Gary J Baker

Weipeng Paul Yan

Diaz Nesamoney

Fayyaz Ahmad Younas

Maurice Mate Radalj

Diego Ongaro

William Charles Mortimore, Jr

Raghavendran Hanumantharau

Simon Y Wong

Venkateswararao Jujjuri

James E Mace

Nagavamsi Ponnekanti

Assaf Ben Gur

Randy Philip Spalten

Andrew Stewart Tucker

Assaf Ben-Gur

Robert Frankus

Ponnekanti Nagavamsi

Andrew Tucker

Techniques are disclosed relating to providing and using probabilistic data structures to at least reduce requests between database nodes. In various embodiments, a first database node processes a database transaction that involves writing a set of database records to an in-memory cache of the first database node. As part of processing the database transaction, the first database node may insert, in a set of probabilistic data structures, a set of database keys that correspond to the set of database records. The first database node may send, to a second database node, the set of probabilistic data structures to enable the second database node to determine whether to request, from the first database node, a database record associated with a database key.

Reducing requests using probabilistic data structures

Techniques are disclosed relating to orchestrating locking between database nodes of a database system. A database node can determine that an execution of a database transaction at the database node involves acquiring a lock. The database node acquires, from a separate lease manager node, a lease object that permits the database node to create the lock for the database transaction. As a part of provisioning that lease object to the database node, the lease manager node ensures that a lease object for creating locks that conflict with the lock is not held by another database node. The database node creates the lock for the database transaction based on the acquired lease object. As a part of creating that lock, the database node ensures that the lock does not conflict with a lock held by another database transaction executing at the database node.

Distributed database locking

System and methods of the disclosed subject matter provide segregating, at a memory storage coupled to a multitenant database system, first tenant data of a first tenant from at least second tenant data of a second tenant, based on a first tenant identifier. A first encryption key associated with the first tenant may be retrieved from a key cache memory based on the first tenant identifier, to encrypt one or more fragments of the first tenant data. The fragments of the first tenant data may be encrypted based on the retrieved encryption key. Non-encrypted header information may be generated for each of the encrypted fragments of the first tenant data, where the header information may have metadata including the first tenant identifier. The encrypted fragments of the first tenant data and the corresponding non-encrypted header information may be stored in the immutable storage.

Systems and methods of database encryption in a multitenant database management system

Systems and methods are provided for migrating a tenant of a database system from a source database instance to a destination database instance. The systems and methods include quiescing the tenant data of the tenant to be migrated from the source database instance to the destination database instance so that no new data is written to the storage of the database system associated with the tenant identifier at the source database instance, transmitting metadata of the tenant to be migrated from the source database instance to the destination database instance, and modifying, at the destination database instance, the metadata of the tenant so that the destination database instance has information to point to groupings of data in the storage for the destination database to access the tenant data.

Systems and methods of database tenant migration

Techniques are disclosed relating to maintaining a cache usable to locate data stored in a data structure. A computer system, in various embodiments, maintains a data structure having a plurality of levels that store files for a database. The files may include one or more records that each have a key and corresponding data. The computer system may also maintain a cache for the database whose entries store, for a key, an indication of a location of a corresponding record in a file of the data structure. In some embodiments, the computer system receives a request to access a particular record stored in the data structure where the request specifies a key usable to locate the particular record. The computer system may retrieve, from the cache via the key, a particular indication of a location of the particular record and may use the particular indication to access the particular record.

Cache for efficient record lookups in an LSM data structure

Techniques are disclosed relating to managing distributed storage of data for various entities according to classifications for these entities. A database node of a distributed storage system may receive, from a first entity of a plurality of entities, a request to store a set of data. The database node may further obtain metadata associated with the first entity, wherein the metadata specifies one of a plurality of classifications for the entities. The database node may provide the set of data to one or more of a plurality of caches for storage. The caches may be located in two or more availability zones and are configured to store the set of data based on the classification for the first entity identified in the metadata associated with the first entity. The database node may also store the set of data in a shared object storage coupled to the database node.

Cloud storage class-based variable cache availability

System and methods are provided for creating a tenant of a database system, the tenant to have tenant data stored in an immutable storage of the database system associated with a tenant identifier. A request may be received at the database system to create a new tenant. A template tenant metadata of a template tenant may be selected at the database system to create the new tenant based on the received request. A new tenant identifier may be created at the database system based on the selected template tenant metadata. The new tenant may be created by associating the new tenant identifier with a snapshot of at least a portion of the template tenant metadata at a point in time when the template tenant metadata is made accessible to the new tenant. Systems and methods are also provided for removing a tenant of a database system by removing references to a tenant identifier.

Systems and methods of creation and deletion of tenants within a database

A method of deleting tombstones early includes setting an initial-flag in a first record in the storage system, setting a delete-flag in a second record in the storage system, selecting a set of one or more records in the storage system to be written to an extent of the storage system in a merge operation, each of the one or more records being associated with the first key, and performing the merge operation, wherein the second record is not written to the extent during the merge operation based at least in part on a determination that the first record having the initial-flag set is the oldest record in the set and the second record having the delete-flag set is the newest record in the set.

System and method for early removal of tombstone records in database

Systems and methods are provided for receiving, at a database system having a memory and at least one persistent storage device to store records, a query for a least one record, where the query uses a first version of a manifest, and where each version of the records that are stored in the at least one persistent storage device are represented by metadata that is part of the first version of the manifest. A first operation may be performed based on a scan operation. The database system may determine whether a purge of the memory has occurred after the first operation. When it is determined that the memory purge has occurred, the scan operation may be restarted from a last position of the scan operation prior to the memory purge using a second version of the manifest.

Systems and methods of managing manifest refresh in a database

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.

Systems and methods of restoring a dataset of a database for a point in time

Growing community of inventors

Oakland, CA, United States of America

Jameison Bear Martin