VoltDB has offered one consistency level from v1.0 until today: fully ACID, serializable transactions.
Why is this important? Giving up or weakening ACID means the application developer needs to:
Identify and understand what kinds of additional failures a system might encounter during an operation.
Figure out what the right resolutions for those failures are.
Write additional code to correctly implement detection and resolution of the failures.
Google has pushed for stronger consistency and ACID across its stack, arguing that the costs of giving up ACID aren’t worth the benefits. They explain why in the Google MillWheel Paper:
By allowing users to focus solely on their application logic, this kind of programming model allows users to reason about the semantics of their system without being distributed systems experts. In particular, users are able to depend on framework-level correctness and fault-tolerance guarantees as axiomatic, vastly restricting the surface area over which bugs and errors can manifest.
That’s a fancy way of saying developers will be more productive and systems will have fewer bugs.
The argument against ACID is that it costs too much in performance and availability. VoltDB performance is clear proof by counter-example that ACID can scale. See our architecture section for more background on how this works. Our high availability features and usage by major banks and telcos show that it doesn’t have to mean less uptime either.
ACID transactions aren’t a panacea, but where they don’t totally negate one of the above concerns, they make the response much simpler. ACID allows developers to think about a set of changes as a compete unit that will run as if it is the only thing running, and will either succeeded or fail in totality, not piecemeal. The time and energy used to address the lack of ACID transactions is better spent adding needed business features to the end application, or getting it into production faster.
Many systems offer ACID with weaker isolation, but suddenly developers have to reason a lot more. Isolation levels like “Read Committed” can’t even increment a value to maintain a counter properly. If you have to think about concurrency for correctness, you’re making problems substantially more complicated.
At VoltDB, we work every day on distributed systems problems like consensus, coordination and fault resolution. We push forward on state management and managing concurrent access. We do this so you don’t have to – so you can focus on your problem, without worrying about ours.