Why are NOSQL databases becoming popular?

Question

SQL

Share your thoughts on the transition from SQL (postgress, sqllite, db2, oracle) to NOSQL.
The motives are incomprehensible to me. I see only harm.

Answer 1

NOSQL databases do not become popular, but occupy their own niche.
NOSQL will never replace relational SQL. There are ways in which NOSQL is effective, and there are other ways in which SQL is effective. Now there is a process of redistribution of spheres of application of these solutions.

Answer 2

And why they become popular: they PR themselves (NoSQL companies like CouchBase, MemDB, etc.), arrange events (every week in Santa Clara some kind of NoSQL conference), but in my opinion, they “hype” a little. And now, as I see it, it has already become a small trend. But it is interesting that until the last moment Oracle did not support NOSQL very conservatively (just like Microsoft with HTML5), and literally six months ago they announced at a conference in San Francisco (open world) what kind of NoSQL is the future.

Answer 3

SQL has serious problems with really large projects: they are very hard to cluster just because of relationality.
Because all database tables are permeated with relationships with each other, then the distribution of one large database across the nodes of the cluster does not give anything, because any request to such a system will lead to the fact that the data located in one node will always be insufficient to form a response, i.e. . to execute each request, you will use the entire cluster.
NoSQL has problems with data consistency (i.e., the lack of the same restrictions imposed by relational databases), so ensuring consistency falls on the application level. But a cluster for NoSQL is an organic form of use for which these databases were created.
Everyone chooses for their project the tool, the advantages of which outweigh the disadvantages in this particular case.

Answer 4

Speed, resistance to SQL-injection.

Answer 5

SQL-relational database. They have a problem with working with very large amounts of data under high load. Here it seems and NOSQL will solve similar problems including.

Answer 6

I can evaluate from the side of MySQL and MongoDB. Apart from the comment above, I would like to add that MySQL is very slow in scale out. In Mong, on the contrary, this is their strong point - convenient, thoughtful sharding with failover replication in the Replica Set format . This is the main emphasis in high-load projects.
Monga also works on the js engine and it is much easier to write all sorts of procedures than in MySQL.
Mongi has the most adequate and convenient PHP driver compared to mysql, mysqli, pdo.
And yes, injection is not really possible in monge because of its BSON format and an adequate driver (unless, of course, your entire request is taken from the url, for example).
Also an important plus in monge is its cursors, which are really cursors, and not an imitation like in MySQL. They (cursors) really walk over the records when the piglets and can live as long as they ask, in the muscle, as a rule, everything is immediately unloaded into memory (correct me if this is a driver problem).
Mongi's ease of use delivers and captivates.
But there is a fly in the ointment. Mongo doesn't have joins (although that might be a plus). And she is sooo voracious (of disk space). Her grouping operations are done through map reduce, which is not very simple.

Answer 7

SQL databases are honed for generalization, they try to provide a reasonable compromise between write and read speeds. This satisfies the needs of most enterprise applications, since the pattern of their use is just "pee / read". Plus, sql databases tend to provide data protection, following the principles of ACID, which, again, is critical for an enterprise.
On the other hand, there are tasks for which something specific from the whole set is important. For example, we want to write fast and write a lot, but we can sacrifice reading speed or data freshness. Or we often write objects of different structures, and we want to get their fast filtering. For all this, the traditional sql approach creates unnecessary bindings that slow down these operations. And these problems are solved by specialized nosql databases.

Answer 8

For example, many developers prefer ORM (Object-relational mapping). NoSQL base (not any, of course) provides a native interface for this model, eliminating the complications from the relational layer. Including for objects with a non-fixed set of properties. Because of this, the application is simplified, performance is increased and sharding is facilitated. Naturally, NoSQL is not an absolute panacea and a replacement for SQL, but in some solutions it has higher efficiency and convenience, and therefore finds its application there.

Answer 9

In some cases, using a SQL database is overkill. For example, if you need to keep a lot of "flat" data, which, if not easier, then faster to work with cursors than queries.
Or the transition from ORM to object-oriented databases. it turns out to be somewhat simpler and more logical than tracking the correspondence of the class diagram with the database schema. Migration is not a panacea.

Answer 10

everything is simple. there is a task: a small database that obviously fits into the RAM, a simple database schema, simple queries, most stupidly on the primary key, data loss is not critical.
the main feature is *many* (very) *simple* queries. they need to be done quickly. it means
1) we keep everything in memory
2) we refuse the query language, we remove the cost of parsing and plan caches, optimization
3) we refuse ACID ,
we get this we get - IN MEMORY query thresher.