NoSQL databases, such as MongoDB, Cassandra, Couchbase, and the rest of this rapidly growing field are some of the latest buzz-worthy technologies. Far past the experimental stage, it is almost safe to say that if you used the internet today, your actions touched a NoSQL database at some point.
However, we should try to separate some of the marketing-speak from the real nature of NoSQL; it is easy to make the mistake that it refers to one technology, but what it really signifies is a philosophical shift.
There is no central board that decides what qualifies as “NoSQL,” nor is it defined by any type of standard (which is sort of the point); it is really a movement focused on giving higher-performing, diversified storage tools to developers. The only real concensus regarding NoSQL is design around the BASE model:
- Basically Available
- Soft State
- Eventually Consistent
To put it into an everyday perspective, if someone tries one of those ubiquitous social media actions such as “liking” or “sharing” and it fails the first time, they are likely to keep trying until it works, not lodge a complaint to a help desk (or in the enterprise environment register a vague and possibly bitter-sounding bug report). Also, many online services generate their value by delivering content tailored to our preferences, a feature that requires more data-crunching than it may seem. Such data crunching can not be held back by I/O throughput or complex queries that are easy to write but cause the database to chug along.
On top of this added utility, NoSQL represents a widened pool of data models. Yes, at the machine level all data is represented as ones and zeros. This fact, however, is not useful when designing the majority of applications: some require quick lookups of user data; some require a great number of reads among thousands of distributed nodes; some require a graph model in order to efficiently represent connections between the data points.
With increased development of document, key-value, graph, and other innovative database models, developers can more easily find a solution that fits their needs. This is more convenient than having to find time in a conference room with a nice big white board that they and DB admins can litter with relational diagrams until everyone is happy.
