Image courtesy of Shutterstock.
You probably already have a team within your organization that has SQL experience. After all, SQL has been the de facto database standard for arguably more than 2 decades now. So at the most fundamental level, consider that at the end of the day NoSQL and SQL are essentially performing the same core task — storing data to a storage medium (hard disk, memory, etc.) and providing a safe and efficient way to later retrieve said data. Sounds pretty simple — right? Well, it really is with a little planning and research. Here is a simple checklist of items to consider as you embark into the world of NoSQL databases.
Do I Need NoSQL?
One of my father’s favorite sayings was, “Use the right tool for the job.” If you are building a house today, you can build it with a hand saw and a hammer, although it would take you quite a while. Instead, if you use a power saw and a pneumatic nail gun, you’ll have a house built in a fraction of the time. You might be asking yourself, “What does building a house have to do with databases?” This analogy is simply implying that you choose the best “tool” for your job at hand; don’t be afraid to venture out — which translates to using the right database for the job. Spending some time learning how to use a new tool, or in our case a new database, can potentially save you money on reduced hardware needs, provide data at a faster rate and provide for more in-depth control over the data.
The main reason for NoSQL’s sudden popularity is that many system architects are realizing that SQL isn’t always the best solution for every situation; so it’s worth asking whether your problem might be better addressed by a NoSQL database. This is especially true with new applications, where you have the chance to pick the right technology upfront. With the variety of database choices available today, don’t waste the chance to create a unique solution that will drive competitive advantages from the fact that you picked the right data management piece of software. While supporting multiple databases isn’t very popular with many IT departments, the overhead of supporting multiple databases, when done for the right reasons, is usually worth the effort. The end goal of IT after all is to provide the business with the best possible information, in a safe and timely manner, to make intelligent decisions to compete in today’s high-paced global economy. If bringing in a new database gives the business a competitive edge, then IT is doing its job.
Step 1 => Choose Your NoSQL Database Category
Choose the correct NoSQL database type for your need. With more than 150 different NoSQL databases, and counting, one of the challenges for the NoSQL industry has been to classify the different databases. The term "NoSQL" is defined as something that is NOT, and therefore it is very comprehensive. The variety of NoSQL databases is vast, and new ones are appearing every year. However, it seems that currently most options are falling into one of these four classifications: Key-Value, Column, Graph, and Document. Each of these four categories has its own set of strengths and weaknesses, so choosing the right database category is your first step. There are many good books, articles and websites detailing the attributes of each, so I won’t go into detail here.
However, I will recommend a book that I’ve found informative: “NoSQL Distilled,” by Sadalage and Fowler, and suggest a comprehensive list of NoSQL databases available at http://nosql-database.org.
Step 2 => Do I Need NoSQL + SQL?
Ask yourself this question: “Do I need to interface my NoSQL data with other applications?” If so, then you might want to consider a NoSQL + SQL database. There are several NoSQL databases that not only provide efficient NoSQL support, but also leverage the relational world which simplifies sharing your NoSQL data with websites and other applications in your enterprise. With a NoSQL + SQL database you will have the best of both worlds — the performance and control which the NoSQL world is bringing to the market, and the ability to easily share data with other parts of the enterprise.
Step 3 => What Level of Data Consistency (ACID vs BASE) Do I Need?
If you are coming to the NoSQL world from the SQL world, then you are probably already familiar with ACID transaction properties. For those not familiar with this topic, when we talk about “Data Consistency,” we are generally referring to what happens as your NoSQL data gets distributed.
First, let’s define the terms: ACID is an acronym that stands for: Atomicity, Consistency, Isolation and Durability. The opposite of an ACID-compliant transaction is either no transaction support, or somewhere in the middle with transactions operating in a BASE model.
Randal Hoff is VP of Engineering Services, FairCom.