Oracle NoSQL Database Storage Nodes

A storage node (SN) is typically a physical machine with its own local persistent storage, either disk or solid state, a CPU with one or more cores, memory, and an IP address. A system with more storage nodes will provide greater aggregate throughput or storage capacity than one with fewer nodes, and systems with a greater degree of replication in shards can provide decreased request latency over installations with smaller degrees of replication. Storage nodes may be added to the system to improve capacity, decrease latency, and improve throughput.
A Storage Node Agent (SNA) runs on each storage node, monitoring that node’s behavior. The SNA (a) receives configuration from, and (b) reports monitoring information to, the Administration Service which interfaces to the Oracle NoSQL Database monitoring dashboard. The SNA collects operational data from the storage node on an ongoing basis and then delivers it to the Administration Service when asked for it.
A storage node serves one or more replication nodes. Each replication node belongs to a single shard.The nodes in a single shard all serve the same data. Each shard has a designated master node that handles all data modification operations (create, update, and delete). The other nodes are read-only replicas, but may assume the role of master should the master node fail. A typical installation uses a replication factor of three in the shards, to ensure that the system can survive at least two simultaneous faults and still continue to service read operations. Applications requiring greater or lesser reliability can adjust this parameter accordingly.

The figure below 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. 

10 Shards


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