BASE is an acronym that stands for: Basically Available, Soft State, Eventually consistent. So with an ACID-compliant transaction model, we have Immediate Data Consistency, and with BASE, we have Eventual Consistency.

In the SQL world, we have grown accustomed to ACID-compliant transactions. While on the other hand, when it comes to NoSQL, there are several databases that support ACID-compliant transactions within the world of vertically scaling applications (meaning we can achieve more data throughput by enhancing the computer where the database engine resides by providing faster disks, solid state disks, more memory, faster CPUs, etc.). Then, when you get into the area of NoSQL, where applications are scaled by growing horizontally (generally by utilizing a cluster of computers with multiple copies of the same data), we tend to find most databases offering a BASE transaction model. 

So think about an application that might have two copies of the same file stored on different nodes within a cluster. If user A queries copy 1 of the file, and user B queries copy 2 of the file, will the results always be the same? If the answer is yes, then you most likely have an ACID compliant database, at least as far as the “C”, or Consistency component of the ACID acronym is concerned. This ACID model indicates that there won’t be a delay before the data is consistent, so the data is considered “Immediately Consistent.”

Going back to our two user examples above, with two users querying the same record across two different copies of the data in a BASE implementation, it’s possible for the two users to get different results, while waiting for the two copies of the data to become consistent. In this model, we say the data is “Eventually Consistent.” The period of time before the data is consistent in the BASE model can be a component in determining if this temporary level of inconsistency will pose a problem to your application. In some cases, such as many financial applications, you won’t want to have any level of inconsistency, so ACID might be the best choice for this type of application. In other cases, there are several applications where a BASE level of consistency is just fine. Consider perhaps a social media application that is tracking the number of likes and dislikes for a given post. If the number of likes and dislikes is off slightly for a brief period of time, no one is going to lose any sleep.

Note though, this topic is something to consider, as getting this issue wrong can have serious implications for your application. That being said, if you are building an application that might someday be scaled horizontally, where you will have multiple copies of the same data being updated and read by multiple concurrent users, be aware, as this topic has had devastating business impact and in at least one documented case has actually put a company out of business.

Given the general nature of this article, I have only touched on this topic of data consistency, so if you feel the level of data consistency might impact your application, I recommend additional research in this area. There are many good articles on the Web discussing this topic, one of which can be found here.

Step 4 => Do Your Research to Find a Suitable List of Vendors

Now that we’ve touched on a few of the key technical items to consider as you contemplate joining the users of NoSQL technology, consider building a short list of vendors to evaluate.

As you build this list, in addition to the points above, ask yourself the following three questions:

1.  Does your NoSQL database vendor have experience in your market segment? It should prove reassuring if the vendor you choose has experience with companies just like yours. This offers peace of mind that there will be no learning process for your vendor.
2.  Does your NoSQL database vendor have a proven track record? With the large number of NoSQL databases available to choose from today, be sure your database is around for the long haul. Look for a company that has been in the business for many years. This can say a lot about the likelihood that your chosen NoSQL database will be around for years to come so you won’t end up with support problems down the road.
3. Do the references of your NoSQL vendor match the SLA of your own applications? A large number of startups are competing in this NoSQL market, and some of them have compiled a sizeable number of references very quickly, simply because of the richness of this new subject. Don’t assume that number means quality: make sure that your vendor has references that match the same level of criticality of the applications that you are planning to develop. If it is a mission-critical system or you foresee large volumes of data, then seek references for this kind of system to ensure your vendor has this support covered.

Step 5 => Build a Proof of Concept

Now that you have your short list of vendors to consider, a great way to compare the merits of the ones you’ve chosen to evaluate is to build a simple application. If performance is one of your main motivators for considering NoSQL, I’d recommend looking at one of your performance bottlenecks and attempt to simulate a small example that exercises that pain point. Create a realistic sample database with a volume of data that matches your biggest problem area and then ask your vendors to recommend their best practices for a highly tuned system (or whatever aspect you are keen to exercise) serving this type of system. Then spend the time coding this example with each of your short-list vendors. Doing research on paper and reading websites is a great way to get started, but at the end of the day, the proof is in the code.

As you code this example, ask yourself:

1. Is the database easy to work with?
2. Is there a variety of APIs and programming languages supported?
3. Are the APIs flexible and able to meet your application requirements?
4. How good is the tech support team?

One of the many strengths of NoSQL is the ability to have precise control over your data. Therefore, looking for flexibility within the APIs, frameworks and programming languages supported, and then seeing how flexible the APIs are make up an important step. One of the ways performance is obtained within the NoSQL world is empowering developers with the ability to solve their data storage and retrieval needs as they see fit, for their specific application and environment.

I also highly recommend sending some questions to the various tech support teams. The strength of a company’s tech support department is critical if you’ll need to rely on them down the road when you go into production. Check this aspect out thoroughly during this proof of concept.

SQL, NoSQL - the Goal is the Same

While the world of NoSQL might seem different than the SQL world we’ve been living in for some time, the end goal is the same: safely store data to a storage medium (hard disk, memory, etc.) and provide an efficient way to later retrieve said data. By using some of the items in this short NoSQL checklist, you should be headed down the right path of exploring the world of alternate databases available to today’s application developers.