3 ms·

> 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

by 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).

by maratd 15y ago

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).