The term “database” was long synonymous with SQL, and for a while there seemed to be no viable alternative. Recently, however, the realm of data storage has welcomed a new option: NoSQL. This article offers you a brief overview of what NoSQL is and when it may be applied.
What is NoSQL?
NoSQL sometimes read as “Not Only SQL“. This emphasizes that NoSQL technology is not against the Structured Query Language. It rather extends it with objects, key/value pairs, graphs and other structures in addition to traditional tables.
The NoSQL database got its start out as an in-house solution to real-world problems of the kind experienced at companies such as Google, Amazon and Facebook. Initially, those companies tried SQL, but soon they found that it couldn’t satisfy their requirements. Three key factors were involved:
- Unprecedented transaction volumes
- The need for low-latency access to massive data sets
- Nearly perfect service availability despite the wildly unpredictable environment.
Why use NoSQL?
The NoSQL database represents a departure from conventional thinking. While a traditional RDBMS relies on the ACID (Atomicity, Consistency, Isolation, Durability) principle, a NoSQL database rather conforms to the different one. This principle is called BASE (Basically Available, Soft state, Eventually consistent).
ACID is relatively pessimistic, forcing consistency at the end of every operation. BASE, however, is optimistic and accepts that the consistency in a data set will fluctuate. Although it might seem impossible to cope with such a system, it’s really very easy. BASE achieves a level of scalability that ACID cannot provide.
BASE facilitates availability by supporting partial failures without experiencing complete system failure. For example, if users are partitioned across five database servers, the BASE design encourages the design of operations in such a way that a failure in the user database will impact only 20% of the users on a given host. This isn’t magic, like some unquantifiable idea. Instead, it’s eminently logical, leading to greater perceived availability for the overall system.
Pros and Cons of NoSQL
NoSQL, though, shouldn’t be considered the solution to every database-related problem. For example, in the context of a stock exchange or banking organization, cached or static data will not be sufficient for the management of critical transactions.
However, the NoSQL database still has a lot to offer. Here are some examples of the benefits of NoSQL database architecture:
Data representation without schema
Nearly every NoSQL implementation is free of the need for schema. So, one needn’t think too far ahead to define a structure. Instead, you can continue to evolve over time. You can add new fields or even nest the data, such as in the case of JSON representation.
Development time
NoSQL may significantly reduce development time because it eliminates the need to deal with complex SQL queries. (Certainly you’ll remember the JOIN query that you wrote to collate the data across multiple tables, simply for the purpose of creating a final view. With NoSQL, you can say goodbye to that.)
Speed
Even with a small amount of data, if you can deliver it in milliseconds as opposed to hundreds of milliseconds (particularly now, with the prevalence of mobile devices and other intermittent connections) you can more easily build a loyal following.
In the end I’d like to offer you a 1-hour introductory video about NoSQL by Martin Fowler:
One reply on “What is NoSQL?”
I think this video at the post bottom might be as a separate post referred to from here.