Debunking Myths About the VoltDB In-Memory Database
Myth #1: “VoltDB requires stored procedures.”
This was true for 1.0, but no one seems to notice it’s been false since we shipped 1.1 in 2010. VoltDB supports unforeseen SQL without any stored procedure use. We have users in production who have never used a single stored procedure.
Myth #2: “VoltDB doesn’t support ad-hoc SQL.”
This is just a rephrasing of Myth #1 and is still false.
Myth #3: “VoltDB is slow unless I use stored procedures.”
Well, no. VoltDB can run faster with stored procedures, but it’s still fast if they are not used. In our internal benchmarks on pretty cheap single-socket hardware, we can run about 50k write statements per second, per host with full durability.
Myth #4: “I have to know Java to use VoltDB.”
As of VoltDB 3.0, released over a year ago, (we’re on V4.2 today), a user can build VoltDB apps and run the server without ever directly interacting with the Java CLI tools or any Java code.
Myth #5: “VoltDB has garbage collection problems because it is written in Java.”
The short answer is this is just not true.
First, VoltDB uses native C++ code for all of its data storage and SQL execution paths. This is done to avoid putting long-lived data on the Java heap, but also to allow very fine control of memory use. VoltDB’s special native data structures use less memory than competing systems and actively fight allocation fragmentation.
Myth #6: “VoltDB’s SQL is very limited.”
This misconception is based on historical truth, but is way out of date in 2014. The original H-Store project, upon which VoltDB is based, started with very limited, OLTP-focused SQL, but much has changed in the past years. VoltDB is rapidly approaching SQL-92 functionality for DML and DQL SQL. One of the final holdouts, subselects, shipped in part in 4.2; more functionality will ship in upcoming versions. In addition to this ANSI SQL baseline, we’ve added materialized view support, function-based index support, native JSON functionality and more.
Myth #7: “Yes, VoltDB supports cross-partition transactions, but they are too slow to use.”
Yes we do, and no they aren’t too slow to use. Keep in mind that NoSQL systems often don’t offer cross-partition transactions and many other NewSQL systems have functionality or performance limitations. Few benchmarks stress this functionality, so I’ll be as clear as possible here.
Details: https://dzone.com/articles/debunking-myths-about-voltdb
This was true for 1.0, but no one seems to notice it’s been false since we shipped 1.1 in 2010. VoltDB supports unforeseen SQL without any stored procedure use. We have users in production who have never used a single stored procedure.
Myth #2: “VoltDB doesn’t support ad-hoc SQL.”
This is just a rephrasing of Myth #1 and is still false.
Myth #3: “VoltDB is slow unless I use stored procedures.”
Well, no. VoltDB can run faster with stored procedures, but it’s still fast if they are not used. In our internal benchmarks on pretty cheap single-socket hardware, we can run about 50k write statements per second, per host with full durability.
Myth #4: “I have to know Java to use VoltDB.”
As of VoltDB 3.0, released over a year ago, (we’re on V4.2 today), a user can build VoltDB apps and run the server without ever directly interacting with the Java CLI tools or any Java code.
Myth #5: “VoltDB has garbage collection problems because it is written in Java.”
The short answer is this is just not true.
First, VoltDB uses native C++ code for all of its data storage and SQL execution paths. This is done to avoid putting long-lived data on the Java heap, but also to allow very fine control of memory use. VoltDB’s special native data structures use less memory than competing systems and actively fight allocation fragmentation.
Myth #6: “VoltDB’s SQL is very limited.”
This misconception is based on historical truth, but is way out of date in 2014. The original H-Store project, upon which VoltDB is based, started with very limited, OLTP-focused SQL, but much has changed in the past years. VoltDB is rapidly approaching SQL-92 functionality for DML and DQL SQL. One of the final holdouts, subselects, shipped in part in 4.2; more functionality will ship in upcoming versions. In addition to this ANSI SQL baseline, we’ve added materialized view support, function-based index support, native JSON functionality and more.
Myth #7: “Yes, VoltDB supports cross-partition transactions, but they are too slow to use.”
Yes we do, and no they aren’t too slow to use. Keep in mind that NoSQL systems often don’t offer cross-partition transactions and many other NewSQL systems have functionality or performance limitations. Few benchmarks stress this functionality, so I’ll be as clear as possible here.
Details: https://dzone.com/articles/debunking-myths-about-voltdb
Comments
Post a Comment