This is a short overview of a SIGMOD tutorial.

Describes a transactional key-value store called Pileus which allows applications to define an SLA for each Get operation. SLA describes the application's preferred performance/consistency tradeoff. SLA is a list of latency/consistency/utility triples, with earlier items preferred to later items. System tries to achieve SLA by controlling which and how many replicas to use for each Get request.

Chops transactions into subtransactions, each of which executes at a single site. Uses static conflict analysis to determine whether subtransactions can be executed independently while ensuring the serializability of the whole outer transaction. User intiated aborts can only occur in the first subtransaction, and system acknowledges commit as soon as the first subtransaction succeeds. Implemented in a system called Lynx.

Describes a meta-system intended to abstract different types of NoSQL systems. Apps see the meta-system, which translates operations to underlying NoSQL systems. Uses an abstract schema consisting of structs, sets, and attributes.

Includes a description of Voldemort.

Stores versioned (timestamped) key to value mappings, replicated using Paxos. Paxos leader also implements a lock table and transaction manager. Transactions local to one group (Paxos instance) are handled by that leader, otherwise 2PC is used among group leaders. Groups span zones (datacenters). Underlying data are stored in Colossus (which is local to a data center?) Keys are grouped into common prefix directories, and directories are assigned to groups. (There are also tablets - difference between tablets and directories is not clear.) Responsibility for controlling replication split between apps and admin. Spanner admins specify a set of replication options (number and placement of copies), apps choose which of these options to use for each directory. Quasi-relational data model, with versioned values, is implemented on top of the basic key to value mapping. Relations are organized hierarchically, with rows linkage based on common key prefixes. Each unique key in the top level table corresponds to a directory.

Objective include high write bandwidth and low read latency. Relational data abstraction. Data are vertically partitioned (using a workload), and then horizontally partitioned within each vertical partition, resulting in tablets. Data are versioned. Interface is record oriented, includes get, put, insert, delete, scan. Each server maintains a single log for all tablets it is responsible for. Also, a multi-version index to locate records on reads. Index is checkpointed to disk periodically to reduce recovery time. Multi-version optimistic concurrency control used to provide SI over multiple records.

Discusses data and functional partitioning in fairly generic terms. Also includes a case study of scaleout for MySpace, using SQL Server.

Data is partitioned into entity groups, each independently and sychronously replicated over a wide area. Multiple data centers, each with a NoSQL data store (BigTable). Transactions allowed within entity groups, but not across. Transactions seem to be reads then writes. Uses Paxos to do wide area replication of a log that includes all transactions' updates, and get agreement on their order of execution. Concurrency control is effectively optimistic - if two transactions are writing in the same entity group at the same time, one may be aborted and retried.

Describes Cloud SQL Server, used by SQL Azure DBMS-as-a-service. Uses partitioning, transactions confined to a single partition. Each DBMS instance has private storage. Synchronous master-slave DBMS-level replication for HA.

Multiple multi-tenant DBMS, each hosting one or more workloads. Large workloads can be scaled-out over multiple DBMS using workload-aware partitioning.

RamCloud appears to apps as a simple key-value storage system. Tries to provide low-latency (5-10 us) access times - needs Infiniband to support this. Tables broken into tablets (contiguous ranges of keys in a tablet), each tablet is assigned to a server. Data are organized in memory as a log. On write, insert new record into the log and update a hash table which indicates where the record can be found. Also push the change to several backup copies of the log on other servers. Periodic garbage collection reclaims log segments. Backups buffer their copies of the log in memory and gradually flush it to disk (not on every update). Suggest use of battery backup or capacitors to ensure that unflushed updates can make it to disk in case power is lost to a backup server. Recovery is highly parallelized. Failed server's keys are repartitioned among multiple recovery masters, each of which recovers its part of the key space and becomes the master for that part of the key space.

Describes an abstraction called overlays for data migration in distributed key-value storage systems.

Excellent overview of hardware and high-level language memory models.

Discussion of technical and business strengths and weaknesses of the utility computing model, including security, lock-in and interoperability.

Discusses cloud service pricing, the cloud computing marketplace, and strategies the may be used by vendors to keep costs low, and weaknesses of current cloud SLAs. Then discusses requirements for Cloud 2.0, meaning cloud services intended to support critical enterprise applications. Issues include storage system performance - argues that access randomness and working set size are proportional to the number of applications supported by a shared storage service. Also discusses administration, SLAs and automation.

Writes collected in RAM and batched to SSD in chunks large enough to fill a flash page. Hash table in memory is used to index key,value pairs in the SSD. There is also a read cache in RAM. Berkeley DB is used to index key,value records on disk. Record read checks RAM read cache, then RAM write buffer, then SSD, then disk. All reads are added to the RAM read cache. Records are inserted into the SSD when they are written (after staging). SSD pages are organized as a ring buffer. When SSD fills, records on early pages are recycled - either by reinserting them into the SSD or by destaging them to the disk. A clock like algorithm (with recent-reference bit) is used to determine whether a record is reinserted into SSD or destaged to disk.

Includes a performance evaluation of Early Lock Release (release locks before commit record goes to disk, but do not return results to client and ensure subsequent transaction's commits are dependent on this one). Also asynchronous log flushing (called flush pipelining) so that threads don't context-switch while waiting for log I/O. Also a technique for parallelizing log buffer insertion.

Describes Percolator, used to incrementally maintain Google's web search index. Provides multi-row transactions and snapshot isolation, using multi-versioning in BigTable. Some transactions may have high latency.

A whitepaper presenting motivation for the RAMCloud project.

Argues for modular and configurable DBMS to address new applications: warehousing, directory services, web search, mobile device caching, XML, streams.

Considers architecture with both flash and magnetic disk available for persistent storage. Each block lives persistently either on disk or on flash, not both. Assumes there is a demand-paged in-memory block cache that makes a placement decision on eviction of a dirty page. Proposed placement algorithms count page reads and writes uses the counts, as well as the costs of read and write operations on disk and flash, to decide where to place an evicted page. Placement decisions are made independently for each page. In particular, there are no capacity constraints and thus the algorithms may choose to place all blocks on the same device. Proposed cache replacement algorithm keeps some number of least-recently-used pages in four queues corresponding to whether the page is clean or dirty and whether the page is located on flash or disk. Always evict the page with the lowest eviction cost from among these least-recently used pages.

Power management for groups (ensembles) of servers, under the assumption that the servers in a group are likely to require peak power at different times. Goal is to reduce the amount of power overprovisioning required for the group.

CQL is the query language implemented by the Stanford STREAM database system.

Chubby cell has a primary and secondaries. Primary handles all reads and writes. Writes are replicated to secondaries and acked when a majority have acked. Primary holds master lease, which it will renew unless it fails. Primary failure causes election of new primary via distributed consensus protocol. Chubby exports a simple Unix-like file system interface. File's can act as reader/writer locks. Chubby also provides notifications of various events, such as modification of file contents or master failover. Clients maintain sessions, which a terminated if the client dies or the session becomes idle. Server guarantees a minimum idle lease time before it will determine session is idle and terminate it. Client also maintains a (conservative) session timeout and will eventually decide its session is expired. Sessions can potentially be preserved across master failovers.

Defines a fault-tolerant commit protocol called Paxos Commit, which makes progress as long as a majority of participants are available. Does not block on failure of a coordinator, as in standard 2PC.

Block level storage virtualization targeted at virtual machines. Uses copy-on-write and trie-based block indexing to support versioned device images. Virtualization is implemented in dedicated virtual machines, one for each node in a cluster.

How to distribute work in a cluster given that different nodes may have different performance and power characteristics. Objective is to minimize power consumption per unit of throughtput. Test implementation is in a cluster web server, and control is achieved by re-distributing the workload among the cluster nodes. Two distribution mechanisms are used: a simple front-end load balancer, and a peer-to-peer mechanism for redistributing requests among servers.

Builds a cost model by tracking costs of recent UDF invocations, including their costs and values of cost-related parameters, and then fitting a model to these data. Includes discussion of statistical issues like collinearity and removal of outliers and collinearity.

Considers cost models as linear functions of a set of explanatory variables for each query class. Initial model is constructed by regression over an initial set of labeled cost samples. Proposes two methods to incrementally maintain such models by folding in new samples and removing the effects of old samples. Assumes that queries from the application workload are labeled and used to train the model.

Discusses file system optimized for relatively small number of large files. Workload is large sequential reads and appends. Node failures are normal. Throughtput is more important than latency. Architecture has a single master and many chunk servers. Master stores metadata (namespace, access controls). Chunks are replicated. Local storage on each chunk node is via a Linux file system. Clients do metadata operations through master, then go directly to chunk servers for data retrieval. Implements a weak consistency model. Metadata operations are atomic and serialized. Concurrent writes of the same file range may get mixed, not serialized. Concurrent appends may lead to duplication. To update a chunk, client first determines (from the master or its cache) the locations of all replicas of the chunk. It first send the update to all replicas. It then sends a write request to the master replica, which serializes all such requests. The master forwards the request serialization order to the other replicas, which apply the updates (they already have) in master-chosen order.

Assumes joined tuples are ranked according to a monotone function of tuple ranks of join inputs. Defines physical join operators that can produce join results in rank order. Operator needs to queue up join results until it can be certain that it will produce them in the proper order.

Describes a methodology for thermal load balancing in server rooms. Thermal imbalances can be caused by imbalanced distribution of server workload and by peculiarities of the airflow in the server room, e.g., racks at the end of a row may be hotter than racks in the middle. Input includes server exhaust temperature readings and cold air temperature. Local thermal imbalances can be corrected by adjusting the allocation of work to the various servers.

A technique for finding twig query matches without first matching individual binary subrelationships in the twig, i.e., this is an N-way structural join. Description of related work is a succinct classification of previous work on twig query processing.

Automatic power management in a cluster of servers by concentrating load on as few machines as possible and turning others off. Implemented in a web server and in a cluster operation system.

A brief general overview of the the problem of energy conservation in data centers.

Presentation of the CAP conjecture.

Incremental, page-at-a-time database recovery on demand, rather than recovery of entire DB before transaction processing resumes. Disk portion of log has redo records only, grouped by the page they refer to. Parallel processes flush log records to disk and also apply logged updates to disk version of the page. Buffer manager also does page flushes (no steal policy). Safe-fetch rule says log updates are only applied to (disk copies) of pages that are in the buffer pool - not clear how this helps. Relies on non-vol RAM to store a map indicating which pages may be stale after a crash, so that they can be brought up to date before being read in after a failure. Targets shared memory multiprocessor, where logger and propagator (applies log updates to pages) can run on their own processors. Seems to rely on page-level locking for correctness.

Discusses scale-up and speed-up as two distinct parallelism objectives. Discusses shared-memory, shared-disk, and shared-nothing architectures and argues that the latter will provide the best scalability because it places the least demands on the interconnection network because interaction is minmized. Discusses data partitioning and parallelization of relational query operators.

Includes a proof of optimality of the MIN algorithm.

Multiple MySQL front ends, replicated partitioned data. Assignment of partitions to nodes can be adjusted to support elastic scale-out. Supports distributed query execution. Company offers database service, rather than software.