4 ms·

So voltdb is an in memory SQL Db with some durability and replication functionality. Is there any good documents on how it compares with some of its competitors

So voltdb is an in memory SQL Db with some durability and replication functionality. Is there any good documents on how it compares with some of its competitors/ who are its competitors?

huggyface 15y ago
Someone please correct me if I'm wrong, however I believe that VoltDB is highly tuned for a specific usage that benefits lots of small operations on large amounts of data. It is less beneficial, if not detrimental, for large operations on medium or large amounts of data.
- AlisdairO 15y ago
  You're entirely correct - VoltDB is very OLTP focused. Its predecessor, H-Store (decent paper here: http://www.vldb.org/pvldb/1/1454211.pdf http://www.vldb.org/pvldb/1/1454211.pdf ) ran on a single-thread-per-processor model that was very performant for short operations, but could obviously cause high latencies in the presence of long running operations. Presumably Volt runs on a similar model. edit: ah, MichaelGG has explained it much better in another part of the comment thread!
- ams6110 15y ago
  Indeed, I'd never heard about it and found myself intrigued. After a bit of reading, it appears that VoltDB supports a very limited number of DDL and DML operations (essentially, you can create tables an views, and select, insert, update, and delete). There are a few basic aggregate functions like SUM and COUNT and no single-row functions. If you need to do anything at all complicated you're doing it in Java, or returning the results to the client program so it can do it. VoltDB sound like a potentially great thing for an application that's really (and only) OLTP. But it's definitely not ready to replace Oracle, PostgreSQL, etc. for more general-purpose needs.
fredholahan 15y ago
As an in-memory RDBMS, VoltDB competes directly against products like Oracle TimesTen and IBM's SolidDB. Comparatively, VoltDB's architecture is designed specifically to scale out on clusters of commodity servers (TimesTem and SolidDB are single-node datastores), giving Volt access to larger amounts of inexpensive main memory. VoltDB also competes indirectly with NoSQL products like Cassandra, which achieve performance and scale primarily by sacrificing SQL and ACID transactions (Volt preserves both). As an in-memory database, VoltDB offers durability through command logging and disaster recovery via a recently-introduced feature called database (WAN) replication. Hope this helps.
MichaelGG 15y ago
I think durability should not be defined in terms of actual backing hardware. VoltDBs transactions commit and stay committed. If you restore from a backup, just like any other database, you'll have data loss until the backup point. What if my hard drive crashes when it loses power? At that point I'm in the same position as when I lose RAM. VoltDB is often compared to other in-memory NoSQL systems, although I'm not aware of any that actually offer cross-server transactions. VoltDB is best when you have a high volume OLTP workload and need to really scale beyond what traditional RDBMS can do. Edit: Here's a benchmark using VoltDB as a key-value store: http://voltdb.com/company/blog/key-value-benchmarking http://voltdb.com/company/blog/key-value-benchmarking
- maratd 15y ago
  > What if my hard drive crashes when it loses power? At that point I'm in the same position as when I lose RAM. Oh sure, except that the probability of losing your hard drive when you lose power is about 1 in a very big number. Whereas, the probability of losing the contents of your RAM when you lose power is 100%. Now, MySQL (and in fact, most RDBMS outfits) provide tools for fixing corrupt data. But you actually need corrupt data to fix. That's the entire point of a hard drive. I'm sure VoltDB would be perfect for a chat application or something of that nature. It would be terrible for anything that involved the transfer of $$$ (banking, ecommerce, etc).
  - MichaelGG 15y ago
    I was making a more theoretical point that defining "durable" in terms of specific hardware isn't a very elegant definition. In practice with VoltDB, you'll replicate to multiple machines synchronously (so you'd need to lose power to separate servers to lose data). VoltDB enterprise has command logging. For a chat messages, I'm not sure VoltDB would be the _best_ choice, perf wise. Chat messages are usually more ephemeral - why go through the overhead of ACID for those? For real $$$ transfers, you'll probably want synchronous WAN replication, to really ensure you never lose transactions.
  - jhugg 15y ago
    VoltDB Community Edition uses synchronous intra-cluster replication, as well as rolling on-disk snapshots for durability. The Enterprise Edition adds a synchronous or asynchronous command log (a logical journal) as well as asynchronous multi-cluster replication. The VoltDB blog has a series of posts covering command logging in detail: http://voltdb.com/company/blog/intro-voltdb-command-logging http://voltdb.com/company/blog/intro-voltdb-command-logging http://voltdb.com/company/blog/voltdb-command-logging-replay http://voltdb.com/company/blog/voltdb-command-logging-replay http://voltdb.com/company/blog/voltdb-command-logging-options http://voltdb.com/company/blog/voltdb-command-logging-option... In short, VoltDB offers tunable durability from single-node purely in-memory, all the way up to synchronous disk storage on multiple local nodes and multiple asynchronous copies in another data center. All options are fully transactional. All options are extremely performant. We've worked very hard to make durability and performance not mutually exclusive. We have internally achieved six-figure TPS numbers using synchronous writes (requires a disk controller with a BBU, or a decent SSD).

So voltdb is an in memory SQL Db with some durability and replication functionality. Is there any good documents on how it compares with some of its competitors/ who are its competitors?

huggyface 15y ago

Someone please correct me if I'm wrong, however I believe that VoltDB is highly tuned for a specific usage that benefits lots of small operations on large amounts of data. It is less beneficial, if not detrimental, for large operations on medium or large amounts of data.

AlisdairO 15y ago
You're entirely correct - VoltDB is very OLTP focused. Its predecessor, H-Store (decent paper here: http://www.vldb.org/pvldb/1/1454211.pdf http://www.vldb.org/pvldb/1/1454211.pdf ) ran on a single-thread-per-processor model that was very performant for short operations, but could obviously cause high latencies in the presence of long running operations. Presumably Volt runs on a similar model. edit: ah, MichaelGG has explained it much better in another part of the comment thread!
ams6110 15y ago
Indeed, I'd never heard about it and found myself intrigued. After a bit of reading, it appears that VoltDB supports a very limited number of DDL and DML operations (essentially, you can create tables an views, and select, insert, update, and delete). There are a few basic aggregate functions like SUM and COUNT and no single-row functions. If you need to do anything at all complicated you're doing it in Java, or returning the results to the client program so it can do it. VoltDB sound like a potentially great thing for an application that's really (and only) OLTP. But it's definitely not ready to replace Oracle, PostgreSQL, etc. for more general-purpose needs.

fredholahan 15y ago

As an in-memory RDBMS, VoltDB competes directly against products like Oracle TimesTen and IBM's SolidDB. Comparatively, VoltDB's architecture is designed specifically to scale out on clusters of commodity servers (TimesTem and SolidDB are single-node datastores), giving Volt access to larger amounts of inexpensive main memory. VoltDB also competes indirectly with NoSQL products like Cassandra, which achieve performance and scale primarily by sacrificing SQL and ACID transactions (Volt preserves both). As an in-memory database, VoltDB offers durability through command logging and disaster recovery via a recently-introduced feature called database (WAN) replication. Hope this helps.

MichaelGG 15y ago

I think durability should not be defined in terms of actual backing hardware. VoltDBs transactions commit and stay committed. If you restore from a backup, just like any other database, you'll have data loss until the backup point. What if my hard drive crashes when it loses power? At that point I'm in the same position as when I lose RAM. VoltDB is often compared to other in-memory NoSQL systems, although I'm not aware of any that actually offer cross-server transactions. VoltDB is best when you have a high volume OLTP workload and need to really scale beyond what traditional RDBMS can do. Edit: Here's a benchmark using VoltDB as a key-value store: http://voltdb.com/company/blog/key-value-benchmarking http://voltdb.com/company/blog/key-value-benchmarking

maratd 15y ago
> What if my hard drive crashes when it loses power? At that point I'm in the same position as when I lose RAM. Oh sure, except that the probability of losing your hard drive when you lose power is about 1 in a very big number. Whereas, the probability of losing the contents of your RAM when you lose power is 100%. Now, MySQL (and in fact, most RDBMS outfits) provide tools for fixing corrupt data. But you actually need corrupt data to fix. That's the entire point of a hard drive. I'm sure VoltDB would be perfect for a chat application or something of that nature. It would be terrible for anything that involved the transfer of $$$ (banking, ecommerce, etc).
- MichaelGG 15y ago
  I was making a more theoretical point that defining "durable" in terms of specific hardware isn't a very elegant definition. In practice with VoltDB, you'll replicate to multiple machines synchronously (so you'd need to lose power to separate servers to lose data). VoltDB enterprise has command logging. For a chat messages, I'm not sure VoltDB would be the _best_ choice, perf wise. Chat messages are usually more ephemeral - why go through the overhead of ACID for those? For real $$$ transfers, you'll probably want synchronous WAN replication, to really ensure you never lose transactions.
- jhugg 15y ago
  VoltDB Community Edition uses synchronous intra-cluster replication, as well as rolling on-disk snapshots for durability. The Enterprise Edition adds a synchronous or asynchronous command log (a logical journal) as well as asynchronous multi-cluster replication. The VoltDB blog has a series of posts covering command logging in detail: http://voltdb.com/company/blog/intro-voltdb-command-logging http://voltdb.com/company/blog/intro-voltdb-command-logging http://voltdb.com/company/blog/voltdb-command-logging-replay http://voltdb.com/company/blog/voltdb-command-logging-replay http://voltdb.com/company/blog/voltdb-command-logging-options http://voltdb.com/company/blog/voltdb-command-logging-option... In short, VoltDB offers tunable durability from single-node purely in-memory, all the way up to synchronous disk storage on multiple local nodes and multiple asynchronous copies in another data center. All options are fully transactional. All options are extremely performant. We've worked very hard to make durability and performance not mutually exclusive. We have internally achieved six-figure TPS numbers using synchronous writes (requires a disk controller with a BBU, or a decent SSD).