AT A GLANCE
Traditional relational databases (Oracle, DB2, MySQL) and most NoSQL data stores keep their data on disk. As the cost of RAM today is significantly less than it used to be and coupled with the advent of 64-bit computing, one can equip a standard, off-the-shelf server with hundreds of gigabytes of main memory.
The size of databases is increasing at the rate that business expands. For example, a purchase order database increases in size at the rate that active purchase orders increase. In almost all database applications, this rate is slower than the rate at which main memory decreases in price. Therefore almost all database applications are (or will soon be) candidates for main-memory deployment – VOltDB Technical Overview
VoltDB is an in-memory database designed by several well-known database system researchers, including A.M. Turing Award winner Michael Stonebraker (who was involved in Ingres and POSTGRES), Sam Madden, and Daniel Abadi. It is an ACID-compliant RDBMS which uses a shared-nothing architecture. It includes both an enterprise and a community edition, which is licensed under the GNU AGPL. Additional features in its commercial enterprise version include durability, high availability, and export integrations. VoltDB implements the design of the academic H-Store project.
A VoltDB database is comprised of a number of partitions spread over a number of sites (servers). Each partition running on a site is single-threaded which eliminates the overheads associated with locking and latching in a typical multi-threaded environment, and transaction requests are executed sequentially.
As such, VoltDB is a main-memory DBMS. In VoltDB, each partition is stored in main memory and processed by its associated, single-threaded execution engine at in-memory speed. In-memory processing eliminates disk waits from within VoltDB transactions, along with the need for buffer management overhead.
VoltDB can save data snapshots and command logs to disk for backup purposes and recovery purposes and also spool data to a data warehouse database for analysis and querying.
VoltDB’s real-time analytics run on each individual event, enabling real time per event decisions and analytics at lower latencies than Spark Streaming. Spark Streaming is sometimes used to batch, sessionize or otherwise transform real time data. VoltDB’s combination of in-memory database, transactional Java + SQL stored procedures and streaming export offer a better, simpler and more performant alternative to Spark Streaming – from highscalability.com
- Main-memory storage. VoltDB stores all its data in RAM. This means there are no buffer pools to manage, so that source of overhead is removed, and there are no blocking disk stalls.
- Run transactions to completion –single threaded –in timestamp order. Based on the model that 200 record updates is a hefty transaction, you might as well run them to completion. By single threading all locking overhead is removed. On multi-core systems they allocate chunks of memory to each CPU and run each CPU single threaded.
- Replicas. Persistence is guaranteed by having the data reside in multiple main memories. There are no logs, so there are no disks, which removes the disk overhead. For high availability an active-active architecture is used. Each transaction is run twice, once on each node in the same time-stamp order, which means the replicas are ACID consistent. Data can be asynchronously shipped to disk for a 5% performance hit. VoltDB replication is not a master/slave or primary/backup replication system. Each replica is a first class, fully capable instance of a partition.
- Tables are partitioned across multiple servers. Partitions are defined in a project XML configuration file that defines the partition keys. Clients can connect through any node. Partitioning is automatic, but you have to decide on the sharding key. They are working on an automated system to give advice on which key to use. If new nodes are added then the data must reloaded to cause the new nodes to be used, the data is not automatically distributed to the new nodes. Not all tables need to be partitioned. Small, mostly read-only tables can be replicated across all of the partitions of a VoltDB database.
- Stored procedures, written in Java, are the unit of transaction. Only data changed within a single invocation of a stored procedure is in a transaction, transactions can’t span multiple rounds of communication with a client. Also, from the same source as the previous link, The vast majority (almost 100%) of your stored procedure invocations must be single partition for VoltDB to be useful to you. If, for example, you partitioned by graph node, updating multiple nodes in a single transaction/procedure will not be a single partition transaction. These and other restrictions show the tradeoff between speed and generality.
- A limited subset of SQL ’99 is supported. DDL operations like ALTER and DROP aren’t supported. Operations having to do with users, groups and security have been moved into XML configuration files. Updating table structure on the fly is convenient, but it’s not fast, so it’s out. You are also discouraged from doing SUM operations because it would take a long time and block other transactions. Single threading means you must quantize your work into small enough chunks that don’t stall the work pipeline. The goal is to have transactions run in under 50 milliseconds. This is all done for speed.
- Design a schema and workflow to use single-sited procedures. Data for a table is stored in a partition that is split onto different nodes. Each set of data on a node is called a slice. When a query can run on a single node it it is said to be single-sited. Performance is clearly best when a query can run on just one node against a limited set of data.
- Challenging operations model. Changing the database schema or reconfiguring the cluster hardware requires first saving and shutting down the database. An exception are stored procedures which can be updated on the fly. In general, choosing speed as the primary design point has made the development and deployment process complicated and limiting. VoltDB, for example, does not support bringing a node back into the cluster while the database is running. All clients must be stopped, the database must be snapshotted, the database must be restarted in a special mode, the data is reloaded, and then clients can be restarted. See Using VoltDB for more details.
- No WAN support. In the case of a network partition VoltDB chooses consistency over availability, so you will see a hiccup until connectivity can be restored. Out of all the possible failures, Mr. Stonebraker argues, network partitioning is one of the least likely failures, especially compared to programmer error, so choosing strong consistency over availability is the right engineering call. Future versions of VoltDB will do more to address this single-data-center catastrophe scenario.
- OLAP is purposefully kept separate. VoltDB is only for OLTP. It’s not for reporting or OLAP because those uses require locks be taken which destroys performance. Every update is spooled to a (optional) companion warehouse system that is a second or two behind the main transaction system (yet is perfectly consistent). The companion system could be something like Vertica, an analytics RDBMS also built by Mr. Stonebraker. The justification for this split of responsibilities is that one size does not fit all. You should run transactions on something that is good at transactions and run reporting on something that’s good at reporting. An specialized transaction architecture will run circles around (50 times to 100 times faster) a one size fits all solution.
- In-memory relational database.
- Can export data into Hadoop
- Supports ANSI SQL
- Stored procedures in Java
- Cross-datacenter replication
- No OLTP
- No WAN support
Best used: Where you need to act fast on massive amounts of incoming data.
For example: Point-of-sales data analysis. Factory control systems.