# Database as a Service

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The content of this page is a Technical Report: MIT-CSAIL-TR-2010-014 available at: [1]

In this paper, we make the case for databases as a service (DaaS), with two target scenarios in mind: (i) consolidation of data management functionality for large organizations and (ii) outsourcing data management to a cloud-based service provider for small/medium organizations. We analyze the many challenges to be faced, and discuss the design of a database service we are building, called Relational Cloud. The system has been designed from scratch and combines many recent advances and novel solutions. The prototype we present exploits multiple dedicated storage engines, provides high-availability via transparent replication, supports automatic workload partitioning and live data migration, and provides serializable distributed transactions. While the system is still under active development, we are able to present promising initial results that showcase the key features of our system. The tests are based on TPC benchmarks and real-world data from epinions.com, and show our partitioning, scalability and balancing capabilities.

## Introduction

Database systems provide an extremely attractive interface for managing and accessing data, and have proven to be wildly successful in many financial, business, and Internet applications. However, they have several serious limitations:

• Database systems are difficult to scale. Most database systems have hard limits beyond which they do not easily scale. Once users reach these scalability limits, time consuming and expensive manual partitioning, data migration, and load balancing are the only recourse.
• Database systems are difficult to configure and maintain. Administrative costs can easily account for a significant fraction of the total cost of ownership of a database system. Furthermore, it is extremely difficult for untrained professionals to get good performance out of most commercial systems--for example, in \cite{pavlo09comparison}, we found that it took several months for a senior graduate student to tune and configure a commercial parallel database system for a simple 8-query workload.
• Diversification in available systems complicates selection. The rise of specialized database systems for specific markets (e.g., main memory systems for OLTP or column-stores for OLAP) complicates system selection,especially for customers whose workloads do not neatly fall into one category.
• Peak provisioning leads to unneeded costs. Database workloads are often bursty in nature, and thus, provisioning for the peak often results in excess of resources during off-peak phases, and thus unneeded costs.

In this paper, we make the case that databases as a service (DaaS) can address these limitations. Our vision is that users should have access to database functionality without worrying about provisioning hardware and configuring software, while providers should be able to manage several databases without dedicating hardware and administrators to each database. We try to achieve this vision with our Relational Cloud system, that hosts multiple databases on a pool of commodity servers inside one data center. Relational Cloud is appropriate for a single organization with many individual databases (a private cloud), or as a public service (a public cloud) that allows database provisioning and administration to be outsourced to a third-party provider. By centralizing and automating databases, there are substantial opportunities to reduce initial and operational costs while maintaining quality of service---as proven by the successful experience of salesforce.com, an example of ad-hoc multi-tenancy for a specific set of applications.

Table~\ref{tab:desiderata} summarizes a set of key requirements for Database as a Service we have identified after discussions with many researchers and potential users. From the user's perspective, the main need is a DB service with a simple interface that does not need tuning and administration (U1). This is an improvement over traditional solutions that requires provisioning, DBMS selection, installation, configuration, and administration. The user wants good performance, expressed in terms of latency and throughput (U2), that is independent of data sizes and workload changes. This is currently a challenging task that requires extensive human analysis, and costly software and hardware upgrades. High availability is another key requirements (U3), which is typically offered by traditional databases, but requires careful configuration and maintenance. Finally, advanced database management features, such as database checkpointing, time travel, and analytics, should be readily available and easy to use(U4).

The other important perspective is that of infrastructure providers, responsible for managing the hardware and software providing the service. The provider's goal is to meet the service level agreements (P1), despite data and workload changes. The system must be efficient, using hardware resources effectively (P2). The service model provides the opportunity to do this, by multiplexing workloads and dynamically adjusting resource allocations. Finally, the amount of administration should be minimized (P3). This is achievable with sophisticated workload analysis tools and by centralizing the management of many databases. There are additional requirements for providers of a public service, such as pricing schemes (C1), security/privacy (C2), and latency (C3). However, these issues are not specific to databases, and can be addressed with the techniques being devised by the cloud-computing community. Thus, we do not discuss them further.

The above list of requirements drove our design choices and helped shape our architecture, as discussed in the following. The system builds on a collection of specialized storage engines, driven by a custom-built distributed transaction coordinator, which also supports high-availability via fail-over to replicas. To achieve elasticity, scalability, and efficient usage of resources, we face major research challenges in the area of adaptability and workload analysis. The main novelty of our Relational Cloud prototype lies in these analysis and adaptation components, specifically:

• Partitioning: To allow workloads to scale across multiple computing nodes, it is important to divide their data into partitions that maximize transaction/query performance. We developed a new graph-based data partitioning algorithm for transaction-oriented workloads that groups data items according to their frequency of co-access within transactions/queries. The idea is to minimize the probability that a given transaction has to access multiple nodes to compute its answer. In the experimental section, we show how this component automatically derives optimal partitionings for the TPC-C benchmark, and how it tackles the harder problem of a social-network test-case derived from epinions.com, with performance gains between 28% and 314% over hash-partitioning.
• Live Migration: One of the key requirements of the cloud is the ability to be {\it elastic}; in the context of a database service, elasticity means adaptively dedicating resources where they are most needed. This is particularly challenging in a database environment where there are large amounts of data that may need to be moved in order to adapt. Our Live Migration component handles this by attempting to predict when adaptation will be needed before any given node is overloaded, and by partitioning and moving data in small chunks and maintaining the ability to execute transactions while movement occurs.
• Workload Analysis and Allocation: To properly co-locate workloads and database instances on machines, it is necessary to analyze and classify their resource requirements. This is the goal of the analysis and allocation component, discussed in Section~\ref{sec:multistorage}. Though we haven't yet built a tool to completely automate this process, we have run experiments that suggest the potential gains from proper storage engine selection and assignment to machines. Experiments show that combining heterogeneous storage engines we can obtain up to almost nine times better performance from the same hardware.

## System Design

Our Relational Cloud design is shown in Figure~\ref{fig:architecture}. The system runs on commodity servers inside a single data center. This has emerged as the most cost-effective way to provide computing, and can be easily scaled by adding and removing individual servers. Each physical server runs potentially multiple database instances, as shown at the bottom of the figure. The database instances may use different storage engines, since specialized engines are often very efficient for specific workloads. Carefully combining workloads and database instances provides an invaluable opportunity to increase efficiency.

Each database is divided into logical partitions, by an automatic partitioning engine, as discussed in Section~\ref{sec:partitioning}. These partitions are stored in k-way redundant replica groups to guarantee high availability and fault-tolerance. A replica group, shown in the middle of the figure, consists of k database instances each storing a copy of the data of a logical partition. Partitioning of the databases and allocation of replica groups to machines is controlled by the the workload analyzer, and is crucial to achieve efficiency, as we discuss in Section \ref{sec:multistorage}.

Applications communicate with Relational Cloud using a standard interface or a known protocol; the current prototype supports core transactional SQL functionality via JDBC and MySQL interfaces. Incoming SQL statements are sent to the router, which analyzes them and consults the metadata database to determine the execution plan. The distributed transaction system then distributes the work while ensuring serializability and handling failures.

By constantly monitoring performance and load, the system validates and adjusts partitioning and placement choices on-line. System failures and workload changes require Relational Cloud to evolve partitioning and allocation schemes at run-time. This requires migration of the data across storage engine instances.

### Current Status

We are actively developing our Relational Cloud prototype. Currently, we have implemented the distributed transaction coordinator along with the routing, partitioning and replication components. We support MySQL and HSQLDB storage engines, and have implemented JDBC and MySQL public interfaces. Given a query trace, we can analyze and automatically generate a good partitioning for it, and then run distributed transactions against those partitions. Our transaction coordinator supports active fail-over to replicas in the event of a failure. We currently do not have complete implementations of the workload analysis, placement, and live migration components, though we have implemented portions of them so that we can demonstrate the potential performance gains that a fully-implemented Relational Cloud system should achieve.

Much of what we have built so far is infrastructure to allow us to research the best partitioning, placement, and migration schemes. Rather than further describing that infrastructure and its engineering challenges (which we feel is not a particularly novel contribution), in the rest of the paper we focus on our ideas and initial implementations of the partitioning, placement, and migration problems.

 Error creating thumbnail: convert: unable to open image /home1/curinous/public_html/relationalcloud/images/3/3f/Relationalcloud_Architecture.jpg': No such file or directory @ error/blob.c/OpenBlob/2638. convert: no images defined /home1/curinous/public_html/relationalcloud/images/thumb/3/3f/Relationalcloud_Architecture.jpg/800px-Relationalcloud_Architecture.jpg' @ error/convert.c/ConvertImageCommand/3044.

### Database Partitioning

Partitioning is crucial to enable: (i) scalability beyond a single node and (ii) finer-grained replication, migration and balancing.

Different classes of workloads necessitate different partitioning strategies. For example, OLTP is characterized by short-lived transactions with little internal parallelism, that are best executed in a single location to minimize distributed transaction overhead, while long-running OLAP queries often benefit from the parallelism enabled by distributing the work across many machines (e.g., large sequential scans from disk). We plan to include multiple algorithms targeting different types of workloads in our partitioning engine.

We started by developing a partitioning strategy for OLTP and Web workloads that uses detailed workload execution traces. The traces are processed in two steps: an agnostic partitioning phase, and a justification phase. The agnostic partitioning phase creates a graph with a node for each tuple in the database. For every transaction in the trace, edges are drawn between each tuple that is accessed, forming a clique. An alternative hypergraph formulation is also available, where hyperedges represent individual transactions. We then apply state of the art graph partitioning techniques \cite{partitioning-icpp95} to find k balanced partitions while minimizing the number of cut edges. Node and edge weights are used to account for skewed workloads or to assign different priorities to transactions. The resulting partitioning minimizes distributed transactions for the workload trace. This phase assigns individual tuples to partitions, this can be represented as look-up tables. However, for naturally partitionable databases a more efficient representation exists.

The goal of the justification phase is to find such representation as a set of predicates on the tuple attributes. The system extracts a set of candidate attributes from the predicates used in the trace (e.g., the predicates appearing in the {\tt WHERE} clauses), tests their correlation to the partitioning labels derived by the agnostic partitioning, and selects the highly correlated attributes. The values of this reduced set of attributes are fed into a decision tree algorithm together with the partitioning labels. If the decision tree successfully generalizes the partitioning via few simple rules, we have found a good justification for the agnostic partitioning. If no predicate-based explanation is found, the system falls back to look-up tables or bloom filters to represent the partitioning scheme.

The strength of this approach is its independence from schema layout and foreign keys information, which allows us to discover intrinsic correlations hidden in the data. As a consequence, this approach is effective (see experiments in Section~\ref{sec:partexp}) in partitioning databases containing multiple n-to-n relationships---typical in social-network scenarios. The system is also capable of suggesting replication for read-mostly tables and hash-based partitioning for tables accessed mainly via primary keys.

The primary disadvantage is the difficulty in scaling the graph representation. The naive approach leads to a graph with N nodes and up to N*N edges, where N is the cardinality of the database. Unfortunately, most graph partitioning algorithms scale only up to few tens of millions of nodes. For this reason, we devised a series of heuristics that effectively limit the graph size with minimal impact on the quality of the partitioning. Among the most effective heuristics we implemented are: (i) blanket statement removal: i.e., the exclusion from the graph of statements that are uncommon and scan large portions of the DB, since they explode the graph size without contributing with much information, (ii) low relevance filter: i.e., the removal of tuples that are never or rarely accessed (This is possible thanks to the generalization step of the justification phase, and similarly by a default partition assignment for tuples not listed in the look-up tables.), (iii) grouping of tuples with similar access patterns, (iv) sampling (both for tuples and transactions) and (v) summarization. This allows us to represent the workloads of databases with billions of tuples within the scalability limits of graph partitioning algorithms.

The initial validation of this approach on the TPC-C benchmark and a real-world workload shows very encouraging results, as discussed in Section~\ref{sec:experiments}.

### Live Migration

The capability to reorganize the resources allocated to a workload, e.g., by moving a workload or a portion of a workload to a new machine, is a key feature that enables elasticity and scalability, two essential features of a cloud-based database service. Although migration is important in other replicated database environments (e.g., when adding a new replica), in a cloud setting it is particularly important for migration to be performed efficiently as it may be used frequently.

While moving data in a network environment is in itself not a difficult problem, supporting transparent live migration is hard to achieve. By transparent migration we mean migration that is: (i) transactionally consistent, (ii) fault tolerant, and (iii) does not substantially affect running transactions and perceived performance. Storage engine heterogeneity further complicates the process.

The naive migration solution involves suspending the service (quiescing running transactions or waiting for them to finish), taking a snapshot of the portion of the database to be moved, moving and loading the data onto the new node, and restarting processing with the new configuration. We believe the performance overhead of this solution is unacceptable, especially when migration is used to adapt to short-lived spikes in load. In fact, significant research has been devoted to this problem, as recently surveyed in \cite{sockut09online}.

In the Relational Cloud effort we are considering various strategies to improve this naive approach, including: (i) partitioning the data to be moved into a number of small partitions, and incrementally migrating these smaller partitions, (ii) migrating an existing snapshot/checkpoint and selectively rolling-forward logs, (iii) exploiting existing replicas to serve read-only queries during migration, (iv) prefetching of data to prepare warm stand-by copies.

Resource allocation is a recurring challenge in the engineering of efficient software systems. In Relational Cloud, the primary resource-related problems include: (i) static and dynamic characterization of workloads, (ii) selection of optimal storage engines, (iii) assignment of workloads to database instances, and (iv) assignment of database instances to physical nodes.

Each of these requires the ability to characterize the demands of workloads and to understand storage engine interactions (e.g., whether two storage engines can co-exist without conflicts on physical node). As we show in Section~\ref{sec:packdb}, understanding these factors is crucial to efficiently using all available resources. Furthermore, different tenants have service level agreements imposing constraints on performance, replication, and data placement.

The resource allocator must take into consideration all of these concerns---hardware resources, storage engines, user workloads, workload interactions, service level agreements, and replication policies---and produce optimal allocations. We believe this problem can be effectively modeled as a linear programming optimization problem, however deriving faithful cost models for all of the above is an incredibly hard challenge. In practice, we believe that tackling this problem requires both analytical models and on-line dynamic adaptation. The large scale at which we operate exacerbates the challenges, but also enables interesting new opportunities, as we anticipate having many different workloads with different requirements, and a large, heterogeneous collection of hardware and software that will enable fine-grained packing of workloads.

We have not begun to seriously address the problems of workload analysis and resource allocation, although they are a key part of our research agenda. Instead, we have focused on measuring the potential benefits of effective resource allocation (in particular, intelligent selection of storage engines and workload placement). As shown in Section~\ref{sec:packdb}, those benefits are substantial.

## Experiments

In this section, we describe several experiments we have run on our Relational Cloud prototype.

### Partitioning

We validated the partitioning technique introduced in Section~\ref{sec:partitioning} on two cases studies, an OLTP benchmark derived from TPC-C and a benchmark based on a real dataset from epinions.com \cite{massa05controversial}. These two tests aim at stress-testing two different aspects of our technique. The TPC-C workload is amenable to partitioning as shown in prior literature \cite{stonebraker2007end} via manual partitioning. The goal of this test is thus to show that our partitioning scheme is capable of completely automating the partitioning task with results similar to careful manual partitioning, as demonstrated in the context of a scalability test in Section~\ref{sec:scaleexp}.

The epinions.com experiment aims at challenging our system in a case where no clear good partitioning exists, and thus is a way of verifying our effectiveness in discovering intrinsic correlations between data items that are not visible at the schema/query level. The simplified epinions.com schema we consider contains four relations: {\tt users}, {\tt items}, {\tt ratings}, {\tt trust}, where the {\tt ratings} relation represents an n-to-n relationship between users and items (capturing user ratings of items), and the {\tt trust} relation represents a n-to-n relationship between pairs of users indicating a binary trust value. The data was obtained in \cite{massa05controversial} via scraping of the epinions.com website.

We consider three common queries:

• For logged-in users: given an item provide ratings from the trusted users
• Given a user show the list of the users (s)he trusts
• For anonymous users: given an item provide the weighted average of all the ratings

The partitioning is non trivial, since the access queries involve multiple n-to-n relations with opposite requirements on how to group tables and tuples (e.g., Q1 will access a single partition if the data is partitioned by item and ratings and trust are stored with items, while Q2 will access a single-partition if data is partitioned by user and trust is stored with users.)

 Error creating thumbnail: convert: unable to open image /home1/curinous/public_html/relationalcloud/images/6/6d/Relationalcloud_Partitioning.jpg': No such file or directory @ error/blob.c/OpenBlob/2638. convert: no images defined /home1/curinous/public_html/relationalcloud/images/thumb/6/6d/Relationalcloud_Partitioning.jpg/800px-Relationalcloud_Partitioning.jpg' @ error/convert.c/ConvertImageCommand/3044.

Figure~\ref{fig:partepinionins} shows the result of executing a uniform mix of 40 million instances of queries Q1--Q3 against two equal-sized partitions generated via hash-partitioning and semi-automatically by our tool.

The hard problem is the relative placement of users and items in order to minimize cross-partition queries/transactions---we fully automate this task. Our system succeeds in capturing the intrinsic correlations between certain groups of users and between certain users and items. In fact, assigning tuples to partitions as our tool suggested (and directing queries to partitions via look-up tables in the router) we win significantly against hash-based partitioning with average improvements ranging from 28% to 314%. We also tried standard predicate-based range partitioning, which yielded to results comparable to hash-partitioning.

### Scaling a Database

In order to show how Relational Cloud can scale a workload, we ran an OLTP benchmark derived from TPC-C across a cluster of machines. Each system has two 3.2 GHz Intel Xeon processors, based on Intel's Netburst architecture, and 2 GB of RAM. Each system uses a single 7200 RPM SATA hard drive with 8 MB cache, 4.2 ms average seek time and 120 MB/s maximum data transfer rate, according to the manufacturer's specifications. The systems are interconnected by a single gigabit Ethernet switch. We used MySQL 5.4 as the underlying storage engine.

The workload is based on TPC-C scaled to 10 warehouses. We used the partitioning algorithm described in Section~\ref{sec:partexp} to divide the database into 1, 2, and 5 partitions, with results almost indistinguishable from careful manual partitioning/replication. Each partition is hosted on a separate server. These partitions are very close to the same size, and the TPC-C workload is uniform across them. We then generated load at a fixed rate of desired transactions per second, measuring the sustained throughput and the average latency for each request. Latency and throughput are shown in Figure~\ref{fig:performance}.

 Error creating thumbnail: convert: unable to open image /home1/curinous/public_html/relationalcloud/images/7/7f/Relationalcloud_MysqlScale.jpg': No such file or directory @ error/blob.c/OpenBlob/2638. convert: no images defined /home1/curinous/public_html/relationalcloud/images/thumb/7/7f/Relationalcloud_MysqlScale.jpg/800px-Relationalcloud_MysqlScale.jpg' @ error/convert.c/ConvertImageCommand/3044.

The throughput shows that a single server is able to achieve approximately 230 transactions per second, and the throughput scales approximately linearly (2 X speed-up for 2 servers, 3.5 X for 5). This shows that for a workload that can be partitioned cleanly, Relational Cloud can scale with demand by distributing it across more servers. Approximately 6% of the transactions access multiple servers, which shows that the cost of distributed transactions is not limiting our scalability for this experiment.

With very low load, the average latency is minimized with a single database instance. Splitting the workload across two databases increases the average latency, due to the additional latency of distributed transactions. For example, at 5 requests per second, one partition has an average latency of 10 ms, while with two partitions this increases to 14 ms. The latency generally increases linearly with load, until the system approaches saturation. At this point, for 1 and 2 servers, the latency increases sharply. This suggests that average latency may be a useful leading indicator" to trigger corrective actions, such as redistributing data. Unfortunately, we do not see this pattern for 5 servers, which leads us to believe that there may be other bottlenecks in our experimental evaluation. We are currently investigating latency and other indicators of database overload over a range of workloads. \vspace{-1mm}

To illustrate the potential gain from effective workload analysis and resource allocation, we compared the performance of heterogeneous storage engine configurations running a fixed workload on a single hardware configuration. The workload simulates a skewed TPC-C workload over 50 warehouses. The target transaction load of our hypothetical customer is 635 TPS with 95% of the load targeting 8 hot warehouses. The hardware consists of a single eight-core x64 server with 12 GB memory and a single 7200 RPM SATA hard drive. The results are shown in Figure~\ref{fig:packdb}.

In the baseline configuration, the workload is executed by a single MySQL instance given complete system resources, which yields 73 TPS (The performance difference from the previous experiments are well-justified due to different test-machines, different TPC-C implementations (trace-based vs clients), skewed/uniform workloads, and different scale factors.). Even ignoring distributed transactions we would need more at least 9 machines to meet the user requirements. The system is disk-bound, and there is plenty of CPU and RAM that could be used more effectively. In our second configuration, the workload is partitioned using the same strategy as the previous experiment, and the hot partitions are stored into an increasing number of HyperSQL (See http://hsqldb.org/) main-memory storage engine instances (Notice that the underlying replication guarantees persistency.)---the limit of 8 instances is due to RAM availability. This allows us to meet the customer requirement of 635 TPS with no additional machines. It is important to notice that the entire database cannot fit in RAM, thus, a pure main-memory approach is not a viable option. We also tested stacking multiple MySQL instances on the same machine. This yielded no improvement, since MySQL is disk limited in this configuration. The performance of each storage instance degrades slightly as more instances are added due to processor and memory bandwidth contention. At the final configuration, we nearly saturate all the machine's resources. Not only is this the highest performance configuration, it will also be very power-efficient. This experiment is designed to show how careful workload analysis and allocation allows to increase performance/efficiency of almost a factor nine, thus, showcasing the potential benefits of a fully developed workload analysis and allocation engine and justifying our research effort in this direction.

## Related Work

We group related work into three categories: (i) scalable database services, (ii) partitioning schemes, (iii) workload analysis.

#### Scalable database services

This is a widely researched area, where substantial research and development efforts have been made by academia as well as commercial and open-source communities. The conflicting goals of providing expressive query languages, consistency, scalability, high-availability, ease of use and low operational costs have been approached from various angles, often significantly favoring one of this requirements over the others. We place ourself in the center of this rich solution space, trying to combine many recent advances in a balanced solution that aims at answering Gassner's call for a cloud-based fully-consistent relational database service for the masses~\cite{gassner09highperformance}. In contrast, BigTable~\cite{chang2006bigtable}, PNUTS \cite{cooper08pnuts}, Dynamo~\cite{amazon-dynamo}, S3, and their academic counterparts~\cite{bratner08building,kraska09consistency} choose to sacrifice expressive power and/or consistency in favor of extreme scalability. Similarly Helland suggests a way of designing applications to avoid distributed transactions in order to better scale systems~\cite{apostate-cidr07}. ElasTraS \cite{elastras-hotcloud09} aims at providing a scalable and elastic data store in the cloud by limiting the type of transactions. Recently Hyder promises to scale a database across multiple servers by relying on a very high performance shared disk built from flash~\cite{hyder-hpts}. Commercial cloud-based relational services are also starting to appear, as Amazon RDS, Microsoft SQL Azure, and offerings from startups like Vertica. These services are a step in the right direction, however they are effectively offering existing relational DBMSs virtualized in a public cloud, and thus lack the elasticity and scalability features we are seeking to achieve.

#### Partitioning Schemes

While we are designing our own workload partitioning algorithms, we plan to make use of several state of the art algorithms for graph partitioning and clustering. Interesting approaches include, but are not limited to: classical work on physical design and partitioning \cite{zilio98physical}, recent works on workload-aware partitioning~\cite{scholl09workload}, graph partitioning algorithms~\cite{partitioning-icpp95}, the comprehensive study on clustering of Tsangaris and Naughton~\cite{clustering-sigmod92}, and recent efforts to scale social networks~\cite{osn-netdb09,armbrust09scads}. Our approach differs from the above by limiting distributed transactions in a multi-node system through the use of novel schema-agnostic partitioning algorithms that simplify attribute selection and handles n-to-n relations.

As already mentioned, the workload analysis engine in our system is still in the early stages. We are investigating several research directions inspired by recent advances on workload optimization~\cite{aragao09optimizing,gmach08integrated, elnaffar09psychic}, allocation and prediction~\cite{ganapathi09predicting}, automatization of virtual machine configuration~\cite{aboulnaga09deploying, soror08automatic, shivam07automated}, and sophisticated caching strategies~\cite{dash09economic}. The problem we face combines many of the above, plus storage-engine heterogeneity, inter-engine interactions, and multi-tenancy in ways that call for novel solutions.

## Conclusions

Cloud-based database services offer the potential to address several serious limitations of existing relational databases related to scalability, ease of use, and provisioning in the face of peak load. In this position paper, we explored the main requirements and technical challenges to make the vision of a database service into a reality and introduced the design and initial evaluation of our system.

Relational Cloud has been designed from scratch to adapt to the peculiarities of the cloud-computing environment. By exploiting multiple dedicated storage engines, providing high-availability via replication, automating workload partitioning and balancing, automating data migration, and supporting distributed transactions we showed that our initial prototype is able to effectively scale OLTP workloads and achieve high-efficiency.

We see these results as an encouraging first step towards providing transactional relational databases as a service, and plan to develop and evaluate our architecture into a full-fledged, open-source cloud-based database platform.