10 rules for scalable performance in 'simple operation' datastores

Abstract

72 Co MMuniCAT ions of T h e AC M | j uNe 2 0 1 1 | vo L. 5 4 | No. 6 contributedarticles sharing the following features: ˲ ˲ Disk-oriented storage; ˲ ˲ Tables stored row-by-row on disk, hence, a row store; ˲ ˲ B-trees as the indexing mechanism; ˲ ˲ Dynamic locking as the concurrency-control mechanism; ˲ ˲ A write-ahead log, or WAL, for crash recovery; ˲ ˲ SQL as the access language; and ˲ ˲ A "row-oriented" query optimizer and executor, pioneered in System R. 7 The 1970s and 1980s were characterized by a single major DBMS market-business data processing-today called online transaction processing, or OLTP. Since then, DBMSs have come to be used in a variety of new markets, including data warehouses, scientific databases, social-networking sites, and gaming sites; the modern-day DBMS market is characterized in the figure here.The figure includes two axes: horizontal, indicating whether an application is read-focused or write-focused, and vertical, indicating whether an application performs simple operations (read or write a few items) or complex operations (read or write thousands of items); for example, the traditional OLTP market is write-focused with simple operations, while the data warehouse market is read-focused with complex operations. Many applit he relatioN a l M oD e l of data was proposed in 1970 by Ted Codd 5 as the best solution for the DBMS problems of the day-business data processing. Early relational systems included System R 2 and Ingres, 9 and almost all commercial relational DBMS (RDBMS) implementations today trace their roots to these two systems.As such, unless you squint, the dominant commercial vendors-Oracle, IBM, and Microsoft-as well as the major open source systems-MySQL and PostgreSQLall look about the same today; we term these systems general-purpose traditional row stores, or GPTRS, key insightsMany scalable sQL and nosQL datastores have been introduced over the past five years, designed for Web 2.0 and other applications that exceed the capacity of single-server RDBMss.Major differences characterize these new datastores as to their consistency guarantees, per-server performance, scalability for read versus write loads, automatic recovery from failure of a server, programming convenience, and administrative simplicity.Applications must be designed for scalability, partitioning application data into "shards," avoiding operations that span partitions, designing for parallelism, and weighing requirements for consistency guarantees.

Skew-aware automatic database partitioning in shared-nothing, parallel OLTP systems

“…We first note that many OLTP applications utilize stored procedures to reduce the number of round-trips per transaction between the client and the DBMS [42]. Each procedure contains control code (i.e., application logic) that invokes pre-defined parameterized SQL commands.…”

“…These systems are designed to take advantage of the partitionability of OLTP workloads to achieve scalability without sacrificing ACID guarantees [9,43]. The OLTP workloads targeted by these NewSQL systems are characterized as having a large number of transactions that (1) are short-lived (i.e., no user stalls), (2) touch a small subset of data using index look-ups (i.e., no full table scans or large distributed joins), and (3) are repetitive (i.e., typically executed as pre-defined transaction templates or stored procedures [43,42]. ) The scalability of OLTP applications on many of these newer DBMSs depends on the existence of an optimal database design.…”

Uniform Access to Non-relational Database Systems: The SOS Platform

“…First, it has been argued that there are cases where their performances are not adequate, while dedicated engines, tailored for specific requirements (for example decision support or stream processing) behave much better [12] and provide scalability [11]. Second, the structure of the relational model, while being effective for many traditional applications, is considered to be too rigid or not useful in other cases, with arguments that call for semistructured data (in the same way as it was discussed since the first Web applications and the development of XML [1]).…”

“…Second, the structure of the relational model, while being effective for many traditional applications, is considered to be too rigid or not useful in other cases, with arguments that call for semistructured data (in the same way as it was discussed since the first Web applications and the development of XML [1]). At the same time, the full power of relational databases, with complex transactions and complex queries, is not needed in some contexts, where "simple operations" (reads and writes that involve small amount of data) are enough [11]. Also, in some cases, ACID consistency, the complete form of consistency guaranteed by RDBMSs, is not essential, and can be sacrificed for the sake of efficiency.…”

“…There is a variety of systems in the NoSQL arena [6,11], more than fifty, and each of them exposes a different interface (different model and different API). Indeed, as it has been recently pointed out, the lack of standard is a great concern for organizations interested in adopting any of these systems [10]: applications and data are not portable and skills and expertise acquired on a specific system are not reusable with another one.…”