3 ms·
In-memory doesn't imply "unreliable". If you need high-availability you'll want to use replication anyway.
by cx01 16y ago
In-memory doesn't imply "unreliable". If you need high-availability you'll want to use replication anyway.
- jbellis 16y agoIn-memory with periodic snapshots sure implies "not durable," though. (That is, you will lose whatever data has not yet been snapshotted on a power failure or crash.) Replication doesn't fix that, unless you're willing to impose the latency of replication to different datacenters for each update. (I don't think Volt even supports this. Most systems don't.)
- cx01 16y agoWhy? If a single node fails, you still have the data on 2 other nodes. Nothing is lost. Of course, assuming you have a reliable UPS.
- shpxnvz 16y agoBecause the data may not have replicated to the other nodes yet. As the parent comment noted, you could synchronously write to all replica nodes, but thats a big performance penalty and not partition tolerant.
- hdiedrich 16y agoThey pay the penalty in latency, not in throughput. That's like no performance penalty at all if you work asynchronously. They make sure that the data cannot become inconsistent between nodes by ordering the transactions. The penalty that comes from this is that latency can become high, i.e. the answer time for individual transactions. While maintaining a maximized throughput of millions of transactions a second. It's like an internal 'pumping rhythm' with tightly synched timestamps.
- aweisberg 16y agoVoltDB replicates synchronously.
- jhugg 16y agoSo if your entire data center loses power... If you have any notice (local UPS, etc), you snapshot to disk. If you have no notice, you lose some number of transactions depending on your data size, snapshot frequency and disk speed. Seconds or minutes, but probably not hours. Future versions of VoltDB will do more address this single-data-center catastrophe scenario.