NoSQL Databases: What are They, and Why?

  • For years, in order to improve performance on database servers, database administrators have had to buy bigger servers as the database load increases (scaling up) instead of distributing the database across multiple “hosts” as the load increases (scaling out). RDBMS do not typically scale out easily, but the newer NoSQL databases are actually designed to expand easily to take advantage of new nodes and are usually designed with low-cost commodity hardware in mind. Therefore, NoSQL databases function superbly in a distributed setting. This means that users could scale a single database by running it across additional inexpensive machines rather than running it on a single more powerful and costly machine. Furthermore, NoSQL databases enable better performance, especially for write-intensive applications. This has been attested to by Opeyemi Obembe in a recent blog article. This performance increase can be attributed to their simpler data models, amongst other things.
  • High-end RDBMS systems can typically be maintained only with the assistance of highly trained Database Administrators (DBAs). NoSQL databases are generally designed from the ground up to require less management using such desirable features as automatic repair, data distribution, and simpler data models leading to lower administration and tuning requirements, or at least that is the expectation. It is a known fact that someone would always have to be accountable for the performance and availability of any mission-critical data store. However, the human resource requirements for managing a NoSQL database are typically less.
  • It is usually not easy to make big changes to the data model of an RDBMS. Changes have to be carefully managed and may even necessitate downtime or reduced service levels. NoSQL databases have less rigid or even nonexistent data model restrictions. Many NoSQL databases typically allow new columns to be created without too much ado.

Despite the fact that NoSQL databases have a number of significant advantages, they also have a number of setbacks. These challenges may not be as important to developers as they are to enterprises. But either way, they are definitely worth noting.

  • Most NoSQL systems are in pre-production versions with many key features yet to be implemented. Therefore, caution should be exercised when deciding whether or not to use NoSQL databases. This is especially important for enterprises as they have a lot more to lose than the more adventurous developers.
  • Enterprises tend to rely a lot on the assurance that if a key system fails, they will be able to get timely and competent support. RDBMS vendors go to great lengths to provide a high level of enterprise support. Most NoSQL systems are open source projects. The companies that created these systems are often small start-ups without global reach, extensive support resources or the kind of the credibility that large RDBMS vendors like Oracle have.
  • NoSQL databases offer few facilities for queries and analysis since they do not work with SQL. Things that would otherwise require simple queries in RDBMS require significant programming expertise when using NoSQL databases. Furthermore, commonly used Business Intelligence (BI) tools do not provide connectivity to NoSQL. However, some work is being done to provide query capabilities to a variety of NoSQL databases.
  • Although, the design goals for NoSQL may be to provide a solution that requires little or no administration, NoSQL databases currently have not achieved that. These databases today, still require a significant level of skill and effort to install and maintain.
  • Most developers at the moment are currently only familiar with RDBMS concepts and programming. This means that almost every NoSQL developer is in learning mode. This might change over time, but at the moment, it is easier to find experienced RDBMS programmers or administrators than it is to find a NoSQL expert. However, NoSQL databases may be easier to work with for developers who are not familiar with the Structured Query Language (SQL).

Page 2 of 3 | Previous page | Next page