Why exactly do we use NoSQL? [closed]

Answer 1

The main reason not to use an SQL database is scalability. The transactional guarantees and the relational model make it almost impossible to scale a database usefully across more than a few machines, especially given the write-heavy workloads generated by modern web applications.

An app like Facebook can't be made to work on a straightforward SQL database, except by massive partitioning and sharding, which requires significant adjustments to the app logic as well. That's why Facebook developed Cassandra.

NoSQL basically means you make do without some SQL-typical features like immediate consistency or easy joins, in exchange for being able to use a database that scales much better.

Conversely, there is no point in using NoSQL if your website never has more than a dozen concurrent users (which is true for the vast majority of all sites).

Answer 2

Better performance

NoSQL databases sometimes have better performance, although this depends on the situation and is disputed.

Adaptability

You can add and remove "columns" without downtime. In most SQL servers, this takes a long time and takes up a load of load.

Application design

It is desirable to separate the data storage from the logic. If you join and select things in SQL queries, you are mixing business logic with storage.

Answer 3

We need understand what is your problem in the current application?

• Transactions
• Amount of data
• Data structure

NoSQL solves the problems of scalability and availability against that of atomicity or consistency.

Basic drive us to CAP theorem. Eric Brewer also noted that Of the three properties of shared-data systems – Consistency, Availability and tolerance to network Partitions – only two can be achieved any given moment in time. (CAP theorem)

NOSQL Approach

• Schemaless data representation:
  • Most of them offer schemaless data representation & allow storing semi-structured data.
  • Can continue to evolve over time— including adding new fields or even nesting the data, for example, in case of JSON representation.
• Development time:
  • No complex SQL queries.
  • No JOIN statements.
• Speed:
  • Very High speed delivery & Mostly in-built entity-level caching
• Plan ahead for scalability:
  • Avoiding rework

Answer 4

There are many types of NoSQL databases. The web applications uses document based databases. The document db allows us to store JSON,XML,YAML and even Word documents and manipulate them. So, NoSQL is the obvious choice, especially MongoDB which is a Document Database which supports JSON format by default is the most preferred choice of developers and designers.

Answer 5

NoSQL databases are there to solve several things, mainly:

• (buzz) BigData => think TB, PB, etc..

• Working with Distributed Systems / datasets => say you have 42 products, so 13 of them will live in Chicago datacenter, 21 in NY's and another and 8 somewhere in Japan, but once you query against all 42 products, you would not need to know where they are located: NoSQL DB will. This also allows to engage a lot more brain power ( servers ) to solve hard computational problems [ does not seem it would fit your use case, but it is an interesting thing to note ]

• Partitioning => having your DB be easily distributed, besides those cool 8 products in Japan, also allows for an easy data replication, so those 42 products will be replicated with a factor of 3, for example, which would mean you DB would have 3 copies for every product. Hence if something goes down, no problem => here is a replica available. This is where NoSQL databases actually shine vs. RDBMS. Granted you can shard, partition and cluster Oracle / MySQL / PostgreSQL / etc.. BUT it is a several magnitudes more complicated process and usually a maintenance headache for most people you'd employ.

BUT to your question:

• why a website would want to use a non-relational database

When most of the people, I worked with / met / chatted with, choose NoSQL for their "website", it is unfortunately NOT for the reasons above, but simply because it is COOLER to do so. And in fact many projects FAIL / have extreme difficulties due to this reason.

If most of NoSQL gurus take their masks off, they will all agree that MOST of the problems ( or as people call them websites ) that developers solve day to day, can and rather be solved with a SQL solution, such as PostgreSQL, MySQL, etc.. with some cool Redis cache layer on top of it. And only a small subset of problems would REALLY benefit from NoSQL.

I personally love Riak, as I am a firm believer that a NoSQL, fault tolerant DB should have an extremely strong, flexible and naturally distributed foundation => such as Erlang OTP. Plus I am a fan of simplicity. But again, given the problem, I would choose whatever works best, and most of the time I will NEED that consistency ( especially if we are talking about money / financial world / mission critical / etc.. ).