At AgileIT Labs we solve a variety of problems for our customers and often that includes guiding clients to the right tools for their needs. In our previous post on NoSQL, we discussed how NoSQL solutions offer a better alternative to RDBMS. In this post we’ll walk you through different types of NoSQL database models and solutions and show you how different architectures and design philosophies support various features. We’ll explain how NoSQL can be a tool that better serves your needs than a one-size-fits-all tool like an RDBMS.

1. Key-Value Stores – These types of database stores data as a hash table with a unique key and a pointer to a particular item of data. Similar to traditional hash tables, it allows data storage and retrieval through keys. It’s the simplest data model and it scales incrementally. However, it’s not suitable where queries are based on the value rather than on the key. It’s also not suitable for transactions or for storing relationship details between data.
2. In-Memory Key-Value Stores – In-memory key-value stores, like Redis, deserves their own category because they’re designed to minimize latency while compromising capacity by holding data within memory. In-memory key-value stores are frequently used to cache results from larger-but-slower databases. In fact, these often aren’t RDBMS replacements, but rather work in conjunction with an existing RDBMS solution. An in-memory key-value store can still scale to high capacities using multiple nodes. For example, it’s been implemented with as many as 250 million key-value pairs.
3. Document Stores – This type of database stores, retrieves and manages data as documents. A document is basically the same thing as a row in a traditional RDBMS. Documents are schema free, i.e., different documents can have structures and schema that differ from one another. That’s completely different from an RDBMS which requires that each row contain the same columns. Instead, document stores can embed and refer to other documents, with each document having a unique id. A collection is a set of documents that’s similar to a set of RDBMS tables.
A document store can support fairly advanced structures. For example, CouchDB accepts documents in JSON format, which allows support for fields and arrays like in C/C++.

Example:

{

 _id:”5466b7c22”,

company:{

   _id:”5466b7c22”,

company: “google”,

symbol : “GOOG”,

stock_price: “858”,

   stock_volume:10M

 }

}

4. Graph Databases – In these, data is stored as graph structures using nodes, edges and properties to represent and store data. Entities are represented as nodes and the relationship between entities as edges. These databases are extremely useful for doing analytics on graph data. With the rise of social media marketing, graph data analyses are becoming more and more common.

5. Column Stores – These are similar to key-value pairs in that keys are used, but they differ by pointing to multiple columns. Each column is a construct that’s uniquely identified by a name, a value and a timestamp. The difference between column stores and key-value stores is that column stores are optimized to handle data along columns. While adding a certain amount of rigidity to a database schema, column stores allow better analytics along columns than do key-value stores in which each row is completely independent. In some ways column stores are an intermediate solution between traditional RDBMSs and key-value stores.
Example:
First_Name    Last_Name    Email
John    Smith    johnsmith@xyz.com
The values shown above are references using the row id 123abc. A row refers to a group of columns identified by a unique row key.
The following table lists databases that fall under each of the categories listed above.


Database Solution/Model      Examples
Key-Value Pairs                         Tokyo Cabinet/Tyrant, Voldemort, Oracle BDB, Amazon SimpleDB, Riak
In-MemoryKey-Value Store        Redis, Memcached
Document Store                        CouchDB, MongoDB
Graph Database                         Neo4j, GraphDB
Column Stores                           Cassandra, HBase

Needless to say, we’ve only scratched the surface here. Varying design decisions and levels of corporate and community interest require a range of considerations within each higher-level type.