NoSQL ?

Relational Vs NoSQL ( right tool for the right job )

I have no doubt by now you all have either heard about or used NoSQL databases, or the least used an application with a NoSQL integrated DB (eg.viber, LinkedIn, PayPal, Agoda, Adobe, eBay, Buzz feed etc.)

The definition of NoSQL implies that there is Not Only SQL(Structured query language) when designing a software solution or product, there are more than one storage mechanism that could be used based on the needs, such as in the form of Document stores, Wide column stores, Key value tuple stores, Multi-model db’s and Graph db’s etc.

NoSQL at first was a hashtag (#nosql) chosen for a meetup to discuss these new databases. The most important result of the rise of NoSQL is Polyglot Persistence, best explained here by Martin Fowler.

“when storing data, it is best to use multiple data storage technologies, chosen based upon the way data is being used by individual applications or components of a single application.”

This rapidly growing technology provides a mechanism for storage and retrieval of data which is modeled in means other than the tabular relations used in relational databases. While It’s true that No SQL databases provide more scalable and superior performance It cannot be considered as a replacement of SQL but rather an alternative.

Therefore in case you’re struggling to decide out of traditional relational model over NoSQL, here are some tips you might find useful,

Tables vs Documents

• While SQL has relational tables with columns, indexes, keys and relationships representing data, NoSQL databases store JSON-like field-value pair documents, e.g.

{
  id: 000000001,
  title: "JavaScript: Beginners Guide",
  author: "Martin Fowler",
  format: "ebook",
  price: 12.00
}

• Similar documents can be stored in a collection, which is analogous to an SQL table. However, you can store any data you like in any document; the NoSQL database won’t complain. For example:

{
  id: 1200000001
  title: "JavaScript: Beginners Guide",
  author: "Darren Jones",
  year: 2016,
  format: "ebook",
  price: 29.00,
  description: "Learn JavaScript from scratch!",
  rating: "4.5/5",
  review: [
    { name: "James", text: "Javascript Cookbook" },
    { name: "Elene", text: "Excellent book for beginners" }
  ]
}

Schema vs Schemaless

• In an SQL database, it’s impossible to add data until you define tables and field types in what’s referred to as a schema. The schema will contains other information, such as primary keys, indexes, relationships while it’s required to be designed and implemented before any business logic can be developed to manipulate data. It’s possible to make updates later, but large changes can be complicated.

• In a NoSQL database, data can be added anywhere, at any time. There’s no need to specify a document design or even a collection up-front. For example, in CouchDB the following statement will create a new document in a new Movie collection if it’s not been previously created:

db.book.insert(
  ISBN: 9780994182654,
  title: "The Alchemist",
  author: "Paulo Cahelo",
  format: "ebook",
  price: 12.00
);

Performance

• Perhaps the most controversial comparison, NoSQL is regularly quoted as being faster than SQL. which isn’t surprising; NoSQL having a simpler denormalized store allows you to retrieve all information about a specific item in a single request. There’s no need for related JOINs or complex SQL queries.
• That said, your project design and data requirements will have most impact. A well-designed SQL database will almost certainly perform better than a badly designed NoSQL equivalent and vice versa.

Scaling

• With the growth of your data in the large project you may find it mandatory to distribute the load among multiple servers, but In general, relational database management systems have been considered as a “one-size-fits-all solution for data persistence and retrieval” for decades.

• Since the SQL based systems being relational models it can be tricky to allocate the related data. Clustering can come to your rescue having multiple servers across the same central store, but still will bring challenges.
• NoSQL having a simpler data model can make the process easier, and many have been built with scaling functionality from the start.

In conclusion “Different kinds of data are best dealt with different data stores”

visual Guide to NoSQL

Considering all the pros and cons of NoSQL with respect to traditional databases i believe NoSQL is more applicable to projects having,

• large data manipulations.
• Managing large streams of non-transactional data (Apache logs, application logs, MySQL logs, clickstreams, etc.)
• unrelated, indeterminate or evolving data requirements.
• Syncing online and offline data.
• Speed and scalability is imperative.
• Soft real-time systems where low latency is critical.
• Load balance to accommodate data and usage concentrations.
• Sequential data reading.
• Caching : Requirement for a high performance caching tier for web sites and other applications. Example is a cache for the Data Aggregation System used by the Large Hadron Collider