Abstract: Various embodiments of systems, computer program products, and methods for encrypting data in a multi-tenant cloud environment are described herein. In an aspect, an encryption time frame to encrypt data associated with a user in a multi-tenant cloud environment may be retrieved. Based on the encryption time frame, a list of object types to be encrypted may be identified. A batch encryption period may be determined for encrypting data corresponding to the list of object types. Further, batches are sequentially selected based on the batch encryption period, for a selected batch: one or more data records may be retrieved based on the batch encryption period and the one or more data records may be encrypted in groups based on at least one throttling value.

Abstract: In an example embodiment, data communications to a first database intercepted and divided based on tenant. For each tenant of multiple tenants sharing the first database, the commands to update the one or more records in the first database within the data communications corresponding to the tenant are translated into commands to update one or more records in a second database of a different type than the first database, the translated commands corresponding to the tenant are replayed against a copied version of the first database in the second database, and the performance of the second database in handling the translated commands during the replaying is tracked. Serialization and timely execution, among the translated commands corresponding to the tenant, of execution of the translated commands is maintained during the replaying and synchronization of execution of translated commands between multiple tenants is maintained.

Abstract: Various embodiments of systems, computer program products, and methods for encrypting data in a multi-tenant cloud environment are described herein. In an aspect, an encryption time frame to encrypt data associated with a user in a multi-tenant cloud environment may be retrieved. Based on the encryption time frame, a list of object types to be encrypted may be identified. A batch encryption period may be determined for encrypting data corresponding to the list of object types. Further, batches are sequentially selected based on the batch encryption period, for a selected batch: one or more data records may be retrieved based on the batch encryption period and the one or more data records may be encrypted in groups based on at least one throttling value.

Abstract: A persistent storage device includes both persistent storage, which includes a set of persistent storage blocks, and NVRAM, and in particular a set of NVRAM blocks. The persistent storage device also typically includes a storage controller. The persistent storage device, in addition to responding to commands to write data directly to and to read data directly from persistent storage blocks is also configured to write data to specified NVRAM blocks (e.g., specified by a host NVRAM write command) and to transfer data from a specified NVRAM block to a specified persistent storage block. As a result, multiple writes to a particular persistent storage block can be replaced with multiple writes to an NVRAM block and a subsequent single write to the particular persistent storage block. This reduces the number of writes to persistent storage and also reduces the number of corresponding block erase operations.

Abstract: In an example embodiment, data communications to a first database intercepted and divided based on tenant. For each tenant of multiple tenants sharing the first database, the commands to update the one or more records in the first database within the data communications corresponding to the tenant are translated into commands to update one or more records in a second database of a different type than the first database, the translated commands corresponding to the tenant are replayed against a copied version of the first database in the second database, and the performance of the second database in handling the translated commands during the replaying is tracked. Serialization and timely execution, among the translated commands corresponding to the tenant, of execution of the translated commands is maintained during the replaying and synchronization of execution of translated commands between multiple tenants is maintained.

Abstract: A method for retrieving versioned data in a non-volatile memory is provided. The method includes: (1) receiving a read request for a data object, (2) in response to the request, determining, via an object table, whether one or more versions of the data object exist in memory, (3) in accordance with a determination that one or more versions exist in memory, obtaining, via the object table, a respective location where each of the one or more versions of the data object are stored, and (4) reading at least one of the one or more versions of the data object from the respective location into volatile memory.

Abstract: Approaches for a non-volatile, solid-state storage system that is capable of supporting high bandwidth and/or random read/write access. The storage system may include a chassis having a bus slot and a disk bay, a master card mounted in the bus slot, and a flash memory card stacked in the disk bay and cabled to the master card. The master card enables one or more flash memory cards to be communicatively coupled to a single PCI Express bus. The master card may split a multi-lane PCI Express bus into a plurality of lanes, where one or more of the flash memory cards communicate over each of the plurality of lanes. Alternately, the master card may includes active circuitry for processing, switching, routing, reformatting, and/or converting the PCI Express bus into one or more busses for a plurality of flash memory cards. The stacked flash memory card is not in an enclosure.

Abstract: Approaches for throttling backgrounds processes to a high degree of precision. The utilization of a shared resource that is used by one or more background processes is monitored. A frequency at which the one or more background processes are executed is dynamically adjusted based on the current utilization of the shared resource without adjusting the frequency in which one or more foreground processes are executed to ensure that the utilization of the shared resource does not exceed a threshold value. The monitoring of the utilization of the shared resource may be performed more often than the adjusted of the frequency at which the background processes are executed, and the utilization of the shared resources may be performed many times a second. Consequently, the utilization of the shared resource may be above a certain level (such as 65%) and less than another level, such as 90%, when background processes are executing.

Abstract: Approaches for a distributed storage system that comprises a plurality of nodes. Each node, of the plurality of nodes, executes one or more application processes which are capable of accessing persistent shared memory. The persistent shared memory is implemented by solid state devices physically maintained on each of the plurality of nodes. Each the one or more application processes, maintained on a particular node, of the plurality of nodes, communicates with a shared data fabric (SDF) to access the persistent shared memory. The persistent shared memory comprises a scoreboard implemented in shared DRAM memory that is mapped to a persistent storage. The scoreboard provides a crash tolerant mechanism for enabling application processes to communicate with the shared data fabric (SDF).

Abstract: Approaches for recovering a node of a distributed transactional system. When a recovering node is being brought on-line, a copy of at least a portion of a first data store maintained by an existing node is created without ceasing to process transactions against the first data store at the existing node. The recovering node creates a second data store based on the copy of the first data store. While the recovering node creates the second data store, the recovering node stores committed transaction data received from a plurality of nodes. The committed transaction data describes transactions committed against data stores maintained by the sender of the committed transaction data. The recovering node may thereafter replay, against the second data store, any transactions identified by the committed transaction data that are associated with a global transaction number that is more recent than is a reference commit number.

Abstract: Data versioning in a non-volatile memory. An object key associated with a data object is created. An index into an object table is generated using the object key. A version number is stored in conjunction with the data object stored in the non-volatile memory. In an object linked-list, the object key and the location information of the data object in the non-volatile memory are stored. A record associated with the data object is created in an object table. The record includes an index, a reference to the object linked-list, and the version number. The index is generated based on the object key.

Abstract: Approaches for processing an event in an objects store, such as an MySQL database management system or a memcached caching system, that are maintained on one or more solid state devices. A plurality of threads may be instantiated. Each of the threads may be configured to retrieve items from a queue of items. Each item in the queue of items may be associated with a particular event occurring within the object store. Each event is a message that indicates an activity requiring work has occurred within the object store. When a particular thread retrieves an item from the queue of items, the particular thread processes the particular event associated with the item retrieved by the particular thread. In this way, event handling in object stores such as MySQL and memcached may be performed more efficiently on a solid state device.

Abstract: A method for retrieving versioned data in a non-volatile memory is provided. The method includes: (1) receiving a read request for a data object, (2) in response to the request, determining, via an object table, whether one or more versions of the data object exist in memory, (3) in accordance with a determination that one or more versions exist in memory, obtaining, via the object table, a respective location where each of the one or more versions of the data object are stored, and (4) reading at least one of the one or more versions of the data object from the respective location into volatile memory.

Abstract: A persistent storage device includes both persistent storage, which includes a set of persistent storage blocks, and NVRAM, and in particular a set of NVRAM blocks. The persistent storage device also typically includes a storage controller. The persistent storage device, in addition to responding to commands to write data directly to and to read data directly from persistent storage blocks is also configured to write data to specified NVRAM blocks (e.g., specified by a host NVRAM write command) and to transfer data from a specified NVRAM block to a specified persistent storage block. As a result, multiple writes to a particular persistent storage block can be replaced with multiple writes to an NVRAM block and a subsequent single write to the particular persistent storage block. This reduces the number of writes to persistent storage and also reduces the number of corresponding block erase operations.

Abstract: A Sharing Data Fabric (SDF) causes flash memory attached to multiple compute nodes to appear to be a single large memory space that is global yet shared by many applications running on the many compute nodes. Flash objects stored in flash memory of a home node are copied to an object cache in DRAM at an action node by SDF threads executing on the nodes. The home node has a flash object map locating flash objects in the home node's flash memory, and a global cache directory that locates copies of the object in other sharing nodes. Application programs use an applications-programming interface (API) into the SDF to transparently get and put objects without regard to the object's location on any of the many compute nodes. SDF threads and tables control coherency of objects in flash and DRAM.

Abstract: Approaches for an object store implemented, at least in part, on one or more solid state devices. The object store may store objects on a plurality of solid state devices. The object store may include a transaction model means for ensuring that the object store performs transactions in compliance with atomicity, concurrency, isolation, and durability (ACID) properties. The object store may include means for providing parallel flushing in a write cache maintained on each of the solid state devices. The object store may include means for maintaining one or more double-write buffers, for the object store, at a location other than the solid state devices. The object store may optionally comprise means for maintaining one or more circular transaction logs, for the object store, at a location other than the solid state devices. The object store may operate to minimize write operations performed on the solid state devices.

Abstract: Approaches for minimizing the amount of write transactions issued to an object store maintained on a solid state device (SSD). Transactions requested against an object store maintained on a SSD may be committed once transaction information for the transaction is durably stored in a non-volatile dynamic random access memory (DRAM), which may be maintained in a HDD controller. Further, data blocks stored in a volatile cache of a database server that issues write requests to an object store maintained on one or more SSDs may be considered persistent stored once confirmation is received that the data blocks are written to a double-write buffer stored on a non-volatile medium, such as NV RAM in a HDD controller. Additionally, any data blocks that are to be written over in a non-volatile DRAM are first ensured to be no longer present within the volatile write cache maintained a the solid state device.

Abstract: Approaches for replicating data in a distributed transactional system. At a first node of a cluster, a per-transaction write set, comprising a plurality of write operations, is committed against a first MySQL database. One or more per-transaction write sets are replicated from the first node to a second node. Upon receiving a read query, the second node parses the read query to identify a read set, calculates a write set conflict window for the read query, and upon determining that the read set conflicts with one or more write sets in the write set conflict window, waits to process the read query until all conflicting write sets are committed. However, upon determining that the read set does not conflict any write sets in the write set conflict window, the read query is processed without first committing any write transactions in the write set conflict window for the read query.

Abstract: Approaches for performing a write operation on a solid state device (SSD). One or more containers are maintained on the solid state device. Each container is a logical grouping of objects independent from where the logical grouping of objects are physically stored on the solid state device. When a write operation is received at the SSD, the manner is which changes requested by the write operation should be stored are determined based on which container is being written. Containers provide a flexible approach for specifying attributes of how data should be stored and accessed which is independent from where the data is physically stored. Containers also have particular utility in performing load balancing and ensuring high availability and recovery.

Abstract: Approaches for replicating data in a distributed transactional system. At a first node of a cluster, a per-transaction write set that comprises a plurality of write operations that are performed against a first data store maintained by the first node is committed. The per-transaction write set is replicated from the first node to a second node of the cluster. At the second node, the plurality of write operations, specified by the per-transaction write set, may be performed in parallel against a second data store maintained by the second node. At the second node, two or more threads may perform a portion of the plurality of write operations against data blocks stored within an in-memory buffer.