NoSQL database systems continue to gain traction, but they are still not widely understood. There is more than one type of NoSQL database and a large number of individual NoSQL DBMSs. There are more than 225 NoSQL DBMSs listed on the NoSQL Database website and it just is not possible to review and understand every option.
Before going down the NoSQL path, it's a good idea to first determine whether your existing DBMS software can be used. NoSQL may be new and interesting, which gets techies excited about learning something new, but a tried-and-true technology such as a relational DBMS can be a better choice at times (because you already use it and employ skilled developers).
That said, NoSQL may be a valid choice for your new project. How can you determine if NoSQL is a reasonable fit? Well, you need to define the problem you're trying to solve, understand the types of problems for which NoSQL works best, and then identify a match.
Two of the basic defining characteristics of most NoSQL offerings are support for flexible schemata and eventual consistency. A schema that is flexible means that one record (or row) of data may have different fields (or columns) than the next, which is not permitted in relational databases. And eventual consistency for transactions, as opposed to ACID (atomicity, consistency, isolation, and durability), delivers higher availability?albeit with more relaxed data consistency than with ACID. You will need to delve deeper into these areas to understand more fully before attempting to use NoSQL.
With that said, let’s quickly outline the types of NoSQL databases and their use cases.
NoSQL DBs and Their Use Cases
Document databases work well for event logging, online shopping, content management and in-depth analytical processing. The schema flexibility of document databases can also be useful for projects requiring rapid prototyping. Document databases are not well-suited for complex transaction processing. MongoDB is an example of a popular document DBMS.
The next type of NoSQL offering is the key-value database. Key-value technology can be useful when most of the data access is done using a unique key. The key is used to access a block of data that really can be anything at all and can vary from record to record.
You might consider a key-value database for tracking session management, serving ad content, or for managing user and product profiles. When data is encoded in many different ways without a rigorous schema, using a key-value database can make sense. Redis is an example of a popular key-value DBMS.
The third NoSQL option is the wide column store, which stores data with keys mapped to values and the values grouped into families that are often accessed together. Again, the schema is flexible and need not be the same from one record to the next.
A column database is well-suited for large datasets with a high number of columns that can vary from record to record. Column stores work well for event logging, content management, and counting or categorizing for analytics. Apache Cassandra, originally developed at Facebook and later released as an open source project, is an example of a wide column store NoSQL database system.
Finally, we have the graph database which focuses on relationships between values and stores data using graph structures with nodes, edges and properties. In a graph database, every element contains a direct pointer to its adjacent element and no index lookups are necessary.
Before looking into a graph database provider, make sure your intended use works well with the graph model. This means any application that can benefit from using graphs to manage data relationships. Example use cases include networks, social media (relationship management), search, fraud detection, real-time recommendations, and digital asset management. An example of a popular graph database system is Neo4j.
Another Choice: The Multi-Model DBMS
Yet another choice in the NoSQL market is the multi-model DBMS. A growing number of vendors have delivered DBMS products that support more than one of the NoSQL models (and in some cases, relational, too).
It can get complicated trying to decipher what is actually offered by DBMSs that market themselves as multi-model. Which models? Delivered how? But using a DBMS that supports more than one model can provide a simpler, easier-to-support environment.
Keep in mind, too, that your existing relational DBMS may also be an option. The relational vendors have expanded their DBMSs to embrace NoSQL and most provide support for one or more of the types of NoSQL.
I guess the bottom line is that the NoSQL market is crowded and confusing. Although there is a quite a lot of good and useful technology, there is also an avalanche of vendors and products to review. Proceed with caution and use due diligence when choosing your database platforms.