First look: Oracle NoSQL Database
Oracle's take on the distributed key-value data store is fast, flexible, and enterprise-grade seriousFollow @peterwayner
There will be plenty of debate about whether Oracle NoSQL offers real ACID compliance. The promises aren't as all-encompassing as they are with SQL databases. You only get an ACID promise when you write data attached to the same major part of the key. For example, you could change the address and ZIP code of the same person and get an ACID guarantee because both parts are stored under the same major key. But you get no guarantee that changes to two separate people will remain consistent. In other words, a bank could use Oracle NoSQL to store personnel records, but not to safely transfer cash between accounts because there's no ACID guarantee that the money won't get lost along the way.
Oracle NoSQL is able to make this promise because it guarantees that one master machine will hold all of the minor keys associated with a major key. Attach any collection of fields to a major key defining a person, and all of this data will end up in the same node in the cluster. But the data from different major keys could end up on different machines, and Oracle NoSQL doesn't have a mechanism to ensure that the data will be written to both simultaneously.
You can also add replication and sharding, which Oracle calls "partitioning." In essence, you arrange the nodes in a rectangle where the sharding occurs along one axis and the replication occurs across the other. If you want more reliability and faster reads, you add more machines along the replication axis. If you want less contention, you add more machines along the partitioning axis. Oracle NoSQL handles most of this configuration for you.
Again, this structure stores data with Oracle-grade seriousness. If you don't want the slacker-grade promise of eventual consistency offered by so many other NoSQL stores, Oracle NoSQL will deliver absolute consistency across all of the machines replicating a node. You'll pay for this in write performance, of course, but it's your choice.
This is more than a binary decision, by the way. You can tell Oracle NoSQL to sign off on the write after one, all, or a simple majority of the nodes are finished sending the data to disk. The documentation calls this feature a durability policy.
Some of this flexibility is available to you, the programmer, if you have the time to worry about it. All of the key-value pairs come with a version number, which you can watch yourself if you want to play your own games with replication. This can be helpful if you're trying to goose performance when modifying records.
Eventual consistency: The great debate
It's worth noting that an intriguing debate about eventual consistency broke out on the blog of Daniel Abadi, a professor of computer science at Yale. He pointed out that in some situations a new pair written to the master could get lost if the master gets cut off from the replicas that will go off and elect a new master that knows nothing of the pair. A different spin came from Margo Seltzer, a professor of computer science at football rival Harvard, as well as an Oracle employee. She joined with the acquisition of Sleepycat, which she helped found.
Seltzer argues that it all depends upon what you mean by "eventual consistency." The database owners choose to take their chances with the durability policy. If the owners want to make sure that a pair never gets lost, they need to ask all writes to wait until all replicas get updated. The debate hinges largely on what "eventual consistency" requires, and it won't be as easily decided as the annual football game.