Figure shows an installation with 10 shards (0-9). Each shard has a replication factor of 3 (one master and two replicas) spread across two data centers. Note that we place two of the replication nodes in the larger of the two data centers and the last replication node in the smaller one. This sort of arrangement might be appropriate for an application that uses the larger data center for its primary data access, maintaining the smaller data center in case of catastrophic failure of the primary data center. The 10 shards are stored on 30 storage nodes, spread across the two data centers.
Replication nodes support the Oracle NoSQL Database API via RMI calls from the client and obtain data directly from or write data directly to the log-structured storage system, which provides outstanding write performance, while maintaining index structures that provide low-latency read performance as well. The Oracle Berkeley DB Java Edition storage engine pioneered the use of logstructured storage in key/value databases since its initial deployment in 2003 and has been proven in several open-source NoSQL solutions, such as Dynamo, Voldemort, and GenieDB, as well as in Enterprise deployments. Oracle NoSQL Database uses replication to ensure data availability in the case of failure. Its singlemaster architecture requires that writes are applied at the master node and then propagated to the replicas. In the case of failure of the master node, the nodes in a shard automatically hold a reliable election (using the Paxos protocol), electing one of the remaining nodes to be the master. The new master then assumes write responsibility. When multiple replication nodes reside on a storage node, the system will attempt to insure that no shard has more than one of its replication nodes on a single storage node