Running emerging main-memory database systems within virtual machines causes huge overhead, because these systems are highly optimized to get the most out of bare metal servers. But running these systems on bare metal servers results in low resource utilization, because database servers often have to be sized for peak loads, much higher than the average load. Instead, we propose to deploy them within light-weight containers that allow to control resource usage and to make use of spare resources by temporarily running other applications on the database server using virtual machines (VMs). The servers on which these VMs would normally run can be suspended, to save energy costs. But current database systems do not handle dynamic changes to resource allocation well and accurate estimates on resource demand are required to maintain SLAs. We focus on emerging main-memory database systems that support the mixed workloads of today's business intelligence applications and propose an cooperative approach in which the DBMS communicates its resource demand, gets informed about currently assigned resources and adapts its resource usage accordingly. We analyze the performance impact on the database system when spare resources are used by VMs and monitor SLA compliance.

On April 21st, 2011, a major outage occurred in Amazon's US east coast data center which led to significant disruptions on customer services. The root cause of the outage was an IT change to route traffic off from a router to a redundant router to conduct a network upgrade. The change was wrongly executed as a router was picked that could not handle the traffic due to capacity constraints. Consequently, network outages occurred, finally leading to unavailability, temporary, and even durable data loss of customers. We propose an object-oriented verification technique to detect conflicts among IT change operations and safety constraints, such as network capacity constraints, in the verification phase before the execution of IT changes. Based on Amazon's incident report different scenarios in static and dynamic routing environments that cause a network overload are shown to be detectable by logical verification. The verification algorithm is proven to be sound and has linear runtime complexity for Amazon's network overload scenarios. A performance analysis confirms the theoretical results and promises scalability to thousands of IT changes and safety constraints.

Today, SLAs for SaaS business applications usually lack stringent service level objectives and significant penalties. Moreover, Operational Business Intelligence features of modern business applications, like analytic dashboards, result in mixed workloads which make it even more difficult to predict execution times accurately due to resource contention. In contrast to the traditional three-tier architecture, an architecture for SaaS business applications should combine application and database layer to allow for processing business transactions and queries according to a queuing approach which enables strict SLAs with stringent response time and throughput guarantees. With stricter SLAs it would be easier to compare different cloud offerings with on-premise solutions and thus cloud computing could become more attractive for potential customers.

Software-as-a-Service applications commonly consolidate multiple businesses into the same database to reduce costs. This practice makes it harder to implement several essential features of enterprise applications. The first is support for master data, which should be shared rather than replicated for each tenant. The second is application modification and extension, which applies both to the database schema and master data it contains. The third is evolution of the schema and master data, which occurs as the application and its extensions are upgraded. These features cannot be easily implemented in a traditional DBMS and, to the extent that they are currently offered at all, they are generally implemented within the application layer. This approach reduces the DBMS to a `dumb data repository' that only stores data rather than managing it. In addition, it complicates development of the application since many DBMS features have to be re-implemented. Instead, a next-generation multi-tenant DBMS should provide explicit support for Extensibility, Data Sharing and Evolution. As these three features are strongly related, they cannot be implemented independently from each other. Therefore, we propose FLEXSCHEME which captures all three aspects in one integrated model. In this paper, we focus on efficient storage mechanisms for this model and present a novel versioning mechanism, called XOR Delta, which is based on XOR encoding and is optimized for main-memory DBMSs.

A multi-tenant database system for Software as a Service (SaaS) should offer schemas that are flexible in that they can be extended different versions of the application and dynamically modified while the system is on-line. This paper presents an experimental comparison of five techniques for implementing flexible schemas for SaaS. In three of these techniques, the database "owns" the schema in that its structure is explicitly defined in DDL. Included here is the commonly-used mapping where each tenant is given their own private tables, which we take as the baseline, and a mapping that employs Sparse Columns in Microsoft SQL Server. These techniques perform well, however they offer only limited support for schema evolution in the presence of existing data. Moreover they do not scale beyond a certain level. In the other two techniques, the application "owns" the schema in that it is mapped into generic structures in the database. Included here are XML in DB2 and Pivot Tables in HBase. These techniques give the application complete control over schema evolution, however they can produce a significant decrease in performance. We conclude that the ideal database for SaaS has not yet been developed and offer some suggestions as to how it should be designed.