NoSql


  • What's driving the switch to NoSQL?
  • Why relational databases like MySQL don't perform at scale?
  • Why large enterprises are choosing NoSQL databases for their web apps?

Relational and NoSQL data models are very different. The relational model takes data and separates it into many interrelated tables. Each table contains rows and columns where a row might contain lots of information about a person and each column might contain a value for a specific attribute associated with that person, like his age.
Tables reference each other through foreign keys that are stored in columns as well. The relational model minimizes the amount of storage space required, because each piece of data is only stored in one place – a key requirement during when relational databases were created and disk storage was very.
However, space efficiency comes at expense of increased complexity when looking up data. The desired information needs to be collected from many tables (often hundreds in today’s enterprise applications) and combined before it can be provided to the application. Similarly, when writing data, the write needs to be coordinated and performed
on many tables.

NoSQL databases have a very different model. For example, a document-oriented NoSQL database takes the data you want to store and aggregates it into documents using the JSON format. Each JSON document can be thought of as an object to be used by your application. A JSON document might, for example, take all the data stored in a row that spans 20 tables of a relational database and aggregate it into a single document/object. Aggregating this information may lead to duplication of information, but since storage is no longer cost prohibitive, the resulting
data model flexibility, ease of efficiently distributing the resulting documents and read and write performance improvements make it an easy trade-off for web-based applications.



Developers generally use object-oriented programming languages to build applications. It’s usually most efficient to work with data that’s in the form of an object with a complex structure consisting of nested data, lists, arrays, etc. The relational data model provides a very limited data structure that doesn’t map well to the object model.
Instead data must be stored and retrieved from tens or even hundreds of interrelated tables. Object-relational frameworks provide some relief but the fundamental impedance mismatch still exists between the way an application would like to see its data and the way it’s actually stored in a relational database. Document databases, on the other hand, can store an entire object in a single JSON document and support complex data structures. This makes it easier to conceptualize data as well as write, debug, and evolve applications, often with fewer lines of code.

Another major difference is that relational technologies have rigid schemas while NoSQL models are schemaless. Relational technology requires strict definition of a schema prior to storing any data into a database. Changing the schema once data is inserted is a big deal. Want to start capturing new information not previously considered? Want to make rapid changes to application behavior requiring changes to data formats and content? With relational technology, changes like these are extremely disruptive and frequently avoided, which is the exact opposite of the behavior desired in the Big Data era, where application developers need to constantly – and rapidly – incorporate new types of data to enrich their applications.
In comparison, document databases are schemaless, allowing you to freely add fields to JSON documents without having to first define changes. The format of the data being inserted can be changed at any time, without application disruption. This allows application developers to move quickly to incorporate new data into their applications. The stark differences between relational and NoSQL data models have caught the attention of application development teams. Whether or not they ever scale beyond a single machine, growing numbers of development
teams feel they can be far more productive using the data models embodied in NoSQL databases

Subpages (1): Readings
Comments