skip to Main Content

One of the primary challenges facing developers today is finding the right tool to complete a given job. Let’s face it, it’s downright time consuming to even look through the vast quantities of frameworks, libraries and software, let alone determine which one is the best. Thankfully there are nice blog posts like this one to give you the introduction you need to specific topics. Today, we’ll answer one simple question: when is a NoSQL database solution right for my company? First things first though, a little background on this technology is required. More specifically, we need to establish where standard relational database systems and where NoSQL databases shine.

RDBMS Shortcomings

Standard relational databases are rock-solid. They have transactional consistency, durability if they lose power, and are highly-supported at the enterprise level. However, there are several places where the relational database falls short. First, column types are strictly defined and have a very specific set of data types. This leaves little room for the times when functional requirements change and the data model must be updated. Often times changing this model is painful for both developers and users alike. Second, the speed and scalability of the databases are sacrificed for safety and durability. Maintaining the ACID properties come at the price of speed and scalability with the database. It ends up as additional overhead for the database and when the data sets grow quickly or become enormous, it slows down the entire system significantly.

How NoSQL Can Help

NoSQL is still a very young technology, but it addresses many of the shortcomings present in relational database systems. Scalability is one of the biggest strengths of NoSQL. Most of the NoSQL database providers have some form of automatic horizontal scaling that allows numerous nodes of the database to be created with little effort. Another strength of these databases is cost – there is less overhead for these databases because they are lightweight. Beyond speed and scalability, these databases can be in-memory (like Oracle DB 12c), and have a flexible data structure. This means that if functional requirements change or the application moves on to a new version, it’s possible to leave all of the old information in place and significantly change how the data is laid out. NoSQL is truly revolutionizing the technology stack of companies all around the world.

When to Use NoSQL

  • Providing personalized alerts to millions of users – with all of this data, it needs to be distributed quickly. Speed is critical for things like severe weather and amber alerts.
  • Managing a “view” of a multitude of systems – NoSQL makes it far easier to develop and manage real-time tracking systems.
  • Managing incoming sensor data from manufacturing processes or geolocation data from users – these databases can handle the significant read-write activity because they can scale horizontally and perform operations quickly.
  • Real-time data analysis – analyzing data as it comes into the database is a strong suit of NoSQL.
  • Mobile application development – much of mobile development relies on REST API’s and NoSQL makes versioning these API’s simple.
  • In conjunction with relational databases – NoSQL doesn’t need to be the only type of database present at a company. In fact, it probably shouldn’t. Sometimes, NoSQL databases act as a cache for the relational databases behind them. Other times they are simply used for different applications.

Conclusion

Overall, NoSQL is not a panacea for data storage problems. But, it is another tool developers can add to their technological repertoire. This data storage technology is something that will likely be used in conjunction with relational databases – they’re very complementary. Try it out – make a new NoSQL database and mess around with it. See the Wikipedia page listed below for a list of common NoSQL databases.

This Post Has One Comment

  1. Hi,Book is a great info about NoSQL and Graph databases, but it’s rellay hard to get started with real samples. The Cypher is 2.0 assumed, but Chapter 3 Shakespeare example is not working in 1.8 (missing index) and also not workin in 2.0.0-M02 some syntax exception. I’m new for the Graph, Neo4j and Cypher, so as 2.0.0 does not have a doc I can not follow the early release book, and must revert to old books and old Neo4j versions.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top