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 debateIt'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.
To test the speed of Oracle NoSQL, I concocted a low-end test that put more stress on the database engine than on the networking. I started up the single-node NoSQL server, then stuffed in 358,400 keys attached to values that were strings with about 30 characters in them. This ran in about 119 seconds on an old, underpowered Mac. Using an older machine with a small amount of RAM is one way to test performance under limited resources.
As a comparison, I stuffed the same pairs into a new version of Voldemort, an open source Java-based NoSQL server from LinkedIn that doesn't offer ACID promises. It took 180 seconds on the same machine.