This definition has already undergone changes and not everyone agrees with them. Some say that the correct name of the technology should be Norel. In some cases Noschema, because that’s what he really is. But in fact what else he has different is that he is Noacid, and that can be a problem.
I don’t like the term much anymore because it ended up encompassing a group of technologies whose only link is that they are databases that have no relationship, but they are very different, this shouldn’t even be considered technology alone, it seems that the term was created only to oppose an established technology and challenge it, be it SQL or relational.
Basically it is to be able to access the data in a non-relational way as are most databases mainstream. And since SQL is the standard language of relational databases, we used this term as marketing.
Usually the data is organized without creating a schema and without defining tables. The main ways to access data are key and value pairs and free documents. There are still models based on objects, documents, graphs, hybrid forms, among others.
Nosql is no magic solution to replace relational databases. It is useful in certain scenarios, especially when searching horizontal scalability - where new servers are added to increase capacity (relational servers can do this too, but it’s not so easy).
Nosql’s need for the core of database work, especially now that most of them have facilities to work with less structured data. But the main reason is that most problems require tabular and related data.
In fact this was an advantage of Nosql, it allows to have data more freely. The "SQL databases" always allowed this but it was not so simple and it was little obvious to some. They’ve been modernizing since 2009 when the so-called Nosql became known.
And remembering that the use of key and value is one of the normal forms of a relational database. Of course it is not optimized for this.
There is a question here to understand a little better that it is useful in large scale cases. I often say that not everyone is Facebook, Netflix or Google, so not everyone needs it. People adopt by fashion or ignorance of the relational model and what these Dbs can do.
- It is not simple to consult in various ways.
- He doesn’t perform well in certain scenarios.
- It has no guaranteed consistency as in relational database.
It’s the fight of ACID X BASE. There are many scenarios that precise consistency in real time is required. See about CHAP.
Some Nosql Dbs are full ACID (see details), but they tend to have disadvantages compared to others. Although there are controversies if this is Nosql itself, because the idea of Nosql is not to abandon SQL but rather the relational model.
In fact, the correct name for this type of technology should be Noconsistency because that’s what it doesn’t really have. Increasingly they are using relations and even SQL.
To tell you the truth, most of them used a different model to get out of the strong competition from the Dbs that were used, today they want to be general-purpose Dbs, and just as relational people can do everything that Nosql could, Nosql wants to be able to do what relational can, giving up something else, that is, you choose which defect to accept having, after all CAP Heheorem continues to exist, despite the fact that some think it is possible to break it (no one could).
It is common to use it as an addition to SQL, as cache or distribution. It is great when data is ephemeral or may be delayed. Get along when queries are simple and unrelated.
The biggest abuse is in the document model, almost always the relational is better. The other models people even use reasonably where need.
Functioning
As each model works differently, and especially as each product has its own way of working, there is no standard - one of the criticisms of this type of technology - it is complicated to say how it works. Each case is different. But you can give some generic examples.
Value key
In the key and value model, you have a dictionary huge. Just like a dictionary structure in any language, access is always done by the key, most likely by calculating a function hash. Then you ask for the value of a key by specifying it. So simple.
Usually this works well in memory, but it doesn’t usually go well if the data is on disk.
It is common for the value returned to be something simple, a data that would amount to a column in a relational DBMS. But nothing prevents a tuple with several columns.
Document
In the document model has several forms of access, you can ask for a value that will be searched in all members of all documents or can specify the type of data, there will be selective in which parts of the document the search will be made. Of course documents that do not have this member will not be evaluated.
In general these documents are stored as JSON or XML, but other formats are also used.
Usually the access is done as data structures in memory. Therefore it is common that they are in memory even. The programmer assumes this. When you use relational, although the DB cache puts a lot of things in memory, there are no guarantees of this, so you always have to think of the queries as if they were on disk. Although today, with SSD and NVRAM, the cost of access to permanent mass storage has gotten lower. So the trend is there’s less need for its use, and more people will use it just because it’s fashionable.
Graphs
It also encompasses object oriented ones that are graphs. General use is useful for very complex cases involving unstructured relationships as a graph even.
Columnar
When individual attributes are more important than the item as a whole, thus dividing into clusters. Example.
Examples.
Learn more.
Related: Nosql is as problematic as it seems?
– rray
Related: "Nosql is synonymous with Object-Oriented Database?"
– mgibsonbr
See here
– Ivan Ferrer