Presently, solid state disks (SSDs) are emerging as a disruptive storage technology and promise breakthroughs for important application properties. They quickly enter the enterprise domain and (partially) replace magnetic disks (HDDs) for database servers. To identify performance and energy use of both types of storage devices, we have built an analysis tool and measured access times and energy needed for them. Associating these measurements to physical IO patterns, we checked and verified the performance claims given by the device manufacturers. Using typical read/write access patterns frequently observed in IO-intensive database applications, we fathomed the performance and energy efficiency potential of a spectrum of differing storage devices (low-end, medium, and high-end SSDs and HDDs).Cross-comparing measurements of identical experiments, we present indicative parameters concerning IO performance and energy consumption. Furthermore, we reexamine an IO rule of thumb guiding their energy-efficient use in database servers. These findings suggest some database-related optimization areas where they can improve performance while energy is saved at the same time.

Abstract. Due to the energy consumption/resource utilization characteristics of todays centralized DB servers, the fastest configuration is also the most energy-efficient one. Extensive use of SSDs alone cannot enable a fundamental change of this overall picture, because the storagerelated energy consumption is typically only a little fraction of the overall energy budget. Even, when this storage-related share is (almost) completely reduced by optimized flash-aware buffer management, the saving effect achieved may be limited by less than ∼10%. Therefore, we have designed a cluster of wimpy computing nodes called WattDB, where the individual nodes are dynamically attached and detached to the cluster on demand -depending on the current workload needs -, thereby aiming at energy-proportional DB management.

The constant growth of data in all businesses leads to bigger database servers. While peak load times require fast and heavyweight hardware to guarantee performance, idle times are a waste of energy and money. Todays DBMSs have the ability to cluster several servers for performance and fault tolerance. Nevertheless, they do not support dynamic powering of the cluster's nodes based on the current workload. In this demo, we propose a newly developed DBMS running on clustered commodity hardware, which is able to dynamically power nodes. The demo allows the user to interact with the DBMS and adjust workloads, while the cluster's reaction is shown in real-time.

We report on the second annual ACM SIGMOD programming contest, which consisted in building an efficient distributed query engine on top of an in-memory index. This article is co-authored by the organizers of the competition (Clément Genzmer, Pierre Senellart) and the students who built the two leading implementations (Volker Hudlet, Hyunjung Park, Daniel Schall). CONTEXTFor the second year in a row, a programming contest was organized in parallel with the ACM SIGMOD 2010 conference. Undergraduate and graduate student teams from over the world were invited to compete to develop an efficient distributed query engine over relational data. Students had several months to work on their implementation, which was judged for their overall performance on a variety of workloads. The teams responsible for the five best systems were invited to present their work during the SIGMOD 2010 conference, and the winning team (one-man team cardinality formed of Hyunjung Park, Stanford University), was awarded a prize of $5,000.In addition to encouraging students to be active in the database research community, the aim is to build over the years, throughout a series of contests, an open source inmemory distributed database management system. Thus, the candidates of this year's contest relied on the inmemory index implementation produced as the outcome of last year's competition.We first describe in more detail the task the contestants were involved in, as well as the workload their implementation was evaluated on. We then report on the outcome of the competition, before describing the key ideas of the systems ranked first and second. TASK DESCRIPTIONAs previously mentioned, the task was to program a simple distributed relational query engine. Contestants had to provide a binary library conforming to a specific interface, along with the corresponding source code. Each submission was evaluated on a dedicated cluster of eight machines, over a series of eight secret query loads. The input provided to the implementation for each workload was the description of which nodes of the cluster stored (parts of) which tables, possibly horizontally partitioned, as well as a set of queries, expressed in a simple subset of SQL. The goal was then to provide the correct output to these queries, as fast as possible. The final score of each submission was computed as a monotonous function of the total time used for running all workloads. Workloads where the submission crashed, did not return the correct output, or ran over the time limit of five to ten minutes (depending on the workload), were assigned penalties.All queries were simple select-project-join queries, of the form: SELECT alias.attribute, ... FROM table AS alias, ... WHERE condition1 AND ... AND conditionN where a condition might be any of: • alias.attribute = constant • alias.attribute > constant • alias1.attribute1 = alias2.attribute2A parser for this subset of SQL was provided.Attribute values were either character strings or integers, and tables were stored in text files on disk. All table...

No abstract