NoSQL databases, upstart technologies that offer more design flexibility than SQL-based relational software does, have started being accepted into the mainstream IT fraternity. For example, Gartner Inc. included five NoSQL DB vendors when it plotted the top providers of operational database management systems in a Magic Quadrant report that the consulting and market research company issued in late 2013. One of those vendors also made it into the ranks of leading data warehouse database developers in a similar report published in March 2014.

But NoSQL technology still hasn't found a place in many user organizations. In a survey of IT and business professionals conducted by The Data Warehousing Institute in November 2013, only 11% of the 538 respondents said their organizations were using NoSQL databases in their primary data warehouse architectures. Another 24% said they planned to do so within three years -- but that left 65% saying their organizations had no adoption plans for NoSQL. Even in a survey of people with experience managing big data environments, done by TDWI earlier in 2013, just 32% of the 189 respondents said they had deployed NoSQL systems -- the lowest adoption rate among six types of technology platforms.

But it isn't always an either-or choice. In a video Q&A, William McKnight, president of McKnight Consulting Group, explains why there's room for combining NoSQL and relational databases in many IT architectures; in another, consultant John Myers of Enterprise Management Associates Inc. discusses the melting pot of data management platforms typically needed to support big data applications. We also look at NoSQL databases from the user point of view -- for example, in a story about MongoDB deployments and a video in which database engineer John Kanagaraj talks about the pros and cons of using NoSQL DB systems in big data environments.

You can find much of the content highlighted here, and more, in our guide to NoSQL database trends and best practices. And if you do decide to take the NoSQL plunge, let me know how the water feels for your organization.

2 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Here's a top piece of advice with two parts.
First, match the type of NoSQL database to your requirements. The most commonly used are key value (e.g. Redis and Riak) and document databases (e.g. MongoDB and CouchDB) but column family data stores (e.g. Cassandra) and graph databases (e.g. Neo4J) fit well in particular use cases. If you need faster retrieval times from databases, storing data in a Redis cache might be a good option. If you need flexibility with attributes and could benefit from embedding structures within your records then document databases are worth a look.
The second piece of advice is don’t worry too much about data modeling at first. The queries you will pose to your NoSQL database should drive how you structure your document, key values, graphs, etc. The reason NoSQL data stores were developed is because relational databases were not meeting a critical need. It’s not surprising that we’d approach NoSQL database design differently. Once you have basic structures down you can test and tune. For example you might start by embedding documents within documents but find references to documents give better performance.