こんにちは、私の名前はドミトリー・カルロフスキーです。私は反コンフォーマストです。つまり、彼の習慣に固執せず、必要に応じて常に変更する準備ができている人です。 たとえば、多くの開発者と同様に、リレーショナルデータベースを使用してデータベースの研究を始めました。 関係代数はその単純さでは非常に美しいですが、私は丸い図形を四角い穴に押し込もうとしていると常に考えていました。
いいえ、MongoDBやその他の劣った「SQLキラー」については説明しません。 トピック「SQL vs NoSQL」に関する記事では、実際にリレーショナルサブドキュメントとドキュメントサブドキュメントを比較しています。
しかし、それらのほとんどに致命的な欠陥があります。著者
は、DBMSに記載されている2つよりもはるかに多くのデータモデルがあることを単に知りません。 そして、人気のある
「リレーショナル」と
「ドキュメンタリー」は、普遍性と専門性の中間に位置しています。
前述のタイプのDBMSの典型的な代表を比較します （大規模から小規模）。
- 人気：Oracle、MongoDB、Redis、HBase、OrientDB。
- 機能：OrientDB、Oracle、MongoDB、HBase、Redis。
- 速度：アプリケーションのタスク、データ、実装に大きく依存します。 たくさんのベンチマークをレビューしましたが、すべてがどこでも異なっています。
SQL
数千人の開発者の力は、タブレットにかなり単純なドメインモデルを配置することを目的としているため、高速で柔軟性があり、それほど難しくありません。 ひどく判明しました。 巨大なORMフレームワーク、猛烈なSQLクエリが記述され、巨大なインデックスが作成され、データが複製されます。
例として、典型的なタスクの1つである、ツリーの操作について説明します。 コメントのツリー、サイトのセクションのツリー、タグのツリーにすることができます。 サブジェクトエリアには多くのツリーがありますが、リレーショナルDBMSを使用すると作業に多大な苦労が生じるため、リレーショナルDBMSを使用しないようにしています。
以下は、さまざまなドメインモデルをすべて長方形テーブルに押し込もうとしたために、RDBMSにのみ存在する問題について、Habréについての記事がいくつ書かれているかを示しています。
すべての決定は、主に次の3つになります。
隣接テーブル。 子孫は親への参照を保存します。 これは子孫の順序を保持しません（保持するには、ソートするために追加の番号を入力する必要があり、挿入と選択の両方が遅くなります）。 隣接テーブルの再帰クエリまたは非正規化が必要です。
再帰的なサブツリークエリ：
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 , …
:
, . , .
- :-)
. , - — .