Usage of NoSQL data stores requires an understanding of features compatibility between itself and the standard RDBMS data stores, which also used by us. The main point is to understand what features NoSQL are lacking and what changes must be done to the application architecture for more effective use of a key-value data store and its features. Some common features of NoSQL data stores we will discuss here are consistency, transactions, query features, structure of the data, and scaling. Consistency Consistency applies only for a single-key operation. These are either a get, put, or delete on a single key. Optimistic writes are very cost-expensive because data store itself cannot determine a change in value. In distributed key-value stores (Riak, for example) implemented the eventually consistent model of consistency. Since the value may have already been replicated to other nodes, Riak has two ways of resolving update conflicts: either the newest write wins and older writes lose, or both (all) values are returned allowing the client to resolve the conflict. In Riak, these options can be set up during the bucket creation. Buckets are just a way to namespace keys so that key collisions can be reduced. Let’s assume that all customer keys reside in the customer bucket. When creating a bucket we can provide default consistency values, such as “write is considered good only when the data is consistent across all the nodes where the data is stored.” Bucket bucket = connection.createBucket(bucketName).withRetrier(attempts(3)).allowSiblings(siblingsAllowed).nVal(numberOfReplicasOfTheData).w(numberOfNodesToRespondToWrite).r(numberOfNodesToRespondToRead).execute(); To guarantee that data in every node is consistent, we can increase the numberOfNodesToRespondToWrite set by w to be the same as nVal. Of course, doing that will decrease the cluster’s write performance. We can change the allowSiblings flag during bucket creation for some improvement on write or read conflicts. If the flag is set to false, store will let the last write to win and not create siblings.Transactions Different products have different specifications of transactions, but, in general there are no guarantees on the writes. Many data stores do implement transactions in different ways. Riak uses the concept of quorum implemented by using the replication factor during the write API call. Let’s assume we have a Riak cluster with a replication factor of 5 and we supply the numberOfNodesToRespondToWrite (W) value of 3. It means that Riak will have tolerance of N – W = 2. So, up two nodes can be down, and data store still will succeed on write operation, though we would have lost some data on those two nodes for read.