Geekly Articles each Day
📜 ⬆️ ⬇️

Isn't it time for relational databases to fall into the dustbin of history?

Hello, my name is Dmitry Karlovsky and I ... anti-conformist, that is, a person who does not hold on to his habits and is always ready to change them, if there is a need. For example, like many developers, I started exploring relational databases. Although relational algebra is quite beautiful in its simplicity, I constantly caught myself thinking that I was trying to shove a round figure into a square hole and it turned out somehow not tight .



No, I will not tell you about MongoDB or any other defective “SQL killer”. There are articles on the topic “SQL vs NoSQL” that actually compare relational data with document ones and so full:
')

But most of them have a fatal flaw - the authors simply do not know that there are much more data models in the DBMS than the two mentioned : from the highly specialized “dictionaries” , then the universal “graphs” . And the popular "relational" and "documentary" are only somewhere in the middle between universality and specialization.

Let's compare the typical representatives of the mentioned types of DBMS (from larger to smaller).


SQL


The forces of thousands of developers are aimed at placing rather simple domain models in tablets so that it is fast, flexible and not too difficult. It turns out badly. Huge ORM frameworks, furious SQL queries are written, huge indexes are created, and data is duplicated.

As an example, I will give one of the typical tasks - working with trees. This can be a comment tree, a section tree of a site, a tag tree. There are a lot of trees in the subject areas, but when working with relational databases, they are avoided because working with them causes a lot of pain.

Here, how many articles on Habré alone are written about the problem, which is exclusively in the RDBMS due to attempts to shove all the variety of domain models into rectangular tables:


All solutions are reduced to three main ones:

Adjacency table The child stores the link to the parent. The order of descendants is not preserved here (in order to save it, you need to enter additional numbering by which to sort, which slows down both inserts and selections). Recursive queries or denormalization of adjacency tables are required.

Recursive subtree query:

WITH RECURSIVE Rec(id, parent, name, ord)
AS (
    SELECT id, parent, name, ord FROM tree
    UNION ALL
    SELECT Rec.id, Rec.parent, Rec.name, Rec.ord
    FROM Rec, tree
    WHERE Rec.id = tree.parent
)
SELECT * FROM Rec
WHERE parent = 123
ORDER BY ord

:

SELECT navi.id , navi.name , navi.parent
FROM tree , navi
WHERE tree.ancestor = 123 AND navi.id = tree.node
ORDER BY ord

. ( ). . , , . .

ordpath:

SELECT RowId, name FROM dbo.Tree WHERE @ParentId.IsDescendant(RowId) = 123

. , . . . .

:

SELECT node.id, node.name
FROM tree AS node, tree AS parent
WHERE node.left BETWEEN parent.left AND parent.right
AND parent.id = 123
ORDER BY node.left;

, .

, . , , ? , , — . « » .

:

SELECT name , parent FROM ( TRAVERSE child FROM #1:123 )

, , «NoSQL», Structured Query Language, :-)

SQL- , . , — , . 1--1 1-- , ( ). . --. , , .

, «» , . « » , , . « » ( ) .

— . . , , id (--). , (--). . . — , . , ( ). , , , .

NoSQL


SQL- - MongoDB, , , , . MongoDB, , json.

, MongoDB — , . — OrientDB, . , OrientDB , , .

NoSQL, — MongoDB Redis:

1. . ( , ), ( , ). OrientDB : , , . , — .

2. ACID (, , , ). OrientDB . , - , . :
writeQuorum , , , .
readQuorum , , .
( ), ( ).
map-reduce: , . . , .

3. SQL API. OrientDB Java Java . API:
. . , API.
. .
. , .
Java-API , (SQL, Gremlin, SPARQL).
Java. Lucene .

NoSQL :-)

NewSQL


, — :

SQL
create table Persons (
    name text,
    age smallint
)

OSQL
create class Person
create property Person.name string
create property Person.age short

. «»:

SQL
create table Persons_friends (
    subject integer,
    object integer
)
create unique index Persons_friends on Persons_friends ( subject , object )

OSQL
create property Person.friend linkset Person

— . , , .

:

SQL
select
    Persons.rowid ,
    Persons.name ,
    Persons.age
from
    Persons_friends as friends,
    Persons
where
    friends.subject = 123 ,
    friends.object = Persons.rowid

OSQL
select expand( friend )
from #19:0
fetchplan *:-2 name:0 age:0

— . , . .

:

SQL
select
    Persons_1.rowid ,
    Persons_1.name ,
    Persons_1.age ,
    Persons_2.rowid ,
    Persons_2.name ,
    Persons_2.age
from
    Persons_friends as friends_1 ,
    Persons_friends as friends_2 ,
    Persons as Persons_1 ,
    Persons as Persons_2
where
    friends_1.subject = 123 ,
    friends_1.object = Persons_1.rowid ,
    friends_1.object = friends_2.subject ,
    friends_2.object = Persons_2.rowid

OSQL
select expand( friend )
from #19:0
fetchplan *:-2
    name:0
    age:0
    friend.name:0
    friend.age:0

. , .

, , , . "How Graph Databases started the Multi Model revolution".

, , , — . , . , , , — .

. -?


SKEDDY ( ). , 20 (20 , ): person, mail, phone, social, token, application, profession, service, meeting, assessment, album, image, notification, place, track, payment, article, aspect, facet, salon.

50 , 20 -- ( 20 20-40 ). OrientDB ( — , — «»), . , , , .

, — , . AngularJS , …

:

, . , .

- :-)

. , - — .

Source: https://habr.com/ru/post/267079/

More articles:


All Articles