Under the leadership of Postgres and Ingres co-founder, Mike Stonebraker, VoltDB has been developed as a next-generation, open-source DBMS that has been shown to process millions of transactions per second on inexpensive clusters of off-the-shelf servers. It has outperformed traditional OLTP database systems by a factor of 45 on a single server, and unlike NoSQL key-value stores, VoltDB can be accessed using SQL and ensures transactional data integrity (ACID). VoltDB is ideal for developers of ad serving, gaming, software as a service (SaaS), financial trading, on-line businesses and other systems with large, fast-growing transaction volumes because VoltDB scales out easily on low-cost servers while providing automatic high availability for 24x7 operation.
We had a lovely talk last month at LA Perl Mongers on Cassandra, a highly distributed, eventually correct key-value store with just a touch of metadata. This is just one of the current crop of key-value stores discussed as "NOSQL" (what a terrible moniker, but interesting ideas in the distributed key-value space).
I'm exciting to see an ACID compliant fast db. I do wonder what has been skipped to make it speedy. Can it persist to disk? snapshot to disk? Or do I just have to maintain enough of my live servers to keep the data up?
What project can I test this out with?
Postgres and Ingres father Michael Stonebraker is answering NoSQL with a variant of his relational baby for web-scale data — and it breaks some of the rules he helped pioneer.
On Tuesday, Stonebraker’s VoltDB company is due to release its eponymous open-source OLTP in-memory database. It ditches just enough DBMS staples to be faster than NoSQL while staying on the right side of the critical ACID database compliance benchmark for atomicity, consistency, isolation and durability of data.
Another question: how do I interact with the DB? I don't see a DBD::Volt namespace yet, and the db *really* wants to be called via stored procedures. From the FAQ:
3.4. Why doesn't VoltDB support ODBC/JDBC?
The primary interaction with a VoltDB database is through stored procedures, and the stored procedure interface (callProcedure) is easy to understand and interpret for those who are familiar with procedure calls through ODBC.
More importantly, although it is possible to perform occasional ad hoc queries on a live VoltDB database, you cannot modify the schema or perform other arbitrary actions through interactive SQL statements. Therefore a generic database connector is not useful when dealing with VoltDB.
Some comparisons also from the FAQ:
2.2. How does VoltDB differ from MySQL used with memcached?
Memcached is a distributed in-memory cache. It provides none of the reliability or consistency of an ACID-compliant SQL database. Memcached is often used as a cache in front of MySQL to improve performance of frequent transactions. But this requires the client application to manage the hash algorithms for both memcached and MySQL, as well as all of the transactional consistency and reliability between the two systems and across the cluster.
VoltDB automates all of these functions with none of the penalties, while providing similar or better performance. In addition, caching can help improve read performance for products such as MySQL, but does not help scale write performance. VoltDB scales linearly for both read and write performance.
2.3. How does VoltDB differ from a Key-Value Store (such as Cassandra)?
Key-Value stores are a mechanism for storing arbitrary data (i.e. values) based on individual keys. Distributing Key-Value stores is simple, since there is only one key. However, there is no structure within the data store and no transactional reliability provided by the system.
VoltDB provides the ability to store either structured or unstructured data, while at the same time providing full transactional consistency, reliability, and standard data access syntax through ANSI SQL. VoltDB can even define a transaction that includes reads and writes across multiple keys. Finally, VoltDB provides comparable or better performance in terms of throughput.