始める前に、今日の議題についてどのような情報があるのか考えてみましょう。 これは単なるデータではありません-非常に予測不可能な構造であり、時間の経過とともにBigDataまたは複雑なセマンティックネットワークに変わる可能性があり、多くの場合、開発者はそれが何であるかを事前に知ることができません。 それでは、本当に高速で効率的なアプリケーションを作成するために、データベース、または少なくともそのアーキテクチャをどのように選択しますか？
この質問に答えるために、私たちが持っているデータベースに関する情報を少し体系化しようとします。 操作の最初で最も有名な候補は、単一のSQL言語を備えたリレーショナルデータベースです。 シンプルで便利、そして標準。 標準化のおかげで、リレーショナルデータベースの人気が高まり、市場を支配しています。 しかし、実際には、リレーショナルデータベースは単なるテーブルであり、各行には、キーとその多数の（または小さな）パラメーターとの間に明確な対応があります。 アプリケーションは個別のテーブルで管理し、アプリケーションと異なる種類のデータとの間の特別な相互作用を考慮しませんでしたが、これで十分です。
| 市区町村
| 設立年
| 人口（人）
| 面積（平方キロメートル）
|
| サンクトペテルブルク
| 1703
| 5 131 942
| 1 439
|
| モスクワ
| 1147
| 12108257
| 2,511
|
| エカテリンブルグ
| 1723
| 1 412 346
| 495
|
| ウラジオストク
| 1860
| 603,244
| 3 3116 |
SQLデータベースの代替として、NoSQLの傾向は2000年代初頭のどこかで開発されてきました。 このカテゴリは、階層およびネットワークデータベース（階層に加えて追加のリンクが提供される）から、各要素に特定のパラメーター値を持たない単純化されたキー値データベースおよびドキュメンタリーデータベースに至るまで、すべてを一列にまとめます。 このカテゴリのデータベースが進化した理由は次のとおりです。プリミティブデータセットと同様のデータセットがあり、クエリが同じテーブルに関連している場合、すべてが問題なく、SQLを使用できます。 しかし、そうでなければ？ リクエストを処理するために10、100、1000のテーブルを参照する必要がある場合は？ その後、リレーショナルデータベースの動作が遅くなり、クエリの作成には多くのコード行が必要になります。
おそらく、NoSQLカテゴリの最も人気のあるデータベースは、ドキュメンタリーデータベース、特にMongoDBです。 これらを使用すると、任意の値のセットを持つオブジェクトを保存できます。これは非常に便利です。たとえば、支払い注文には1つのフィールドがあり、注文には異なるフィールドがあります。 そして、これらはすべて、プリミティブテーブルに分割されることなく、同じデータベースセグメントに格納されます。 ただし、このアプローチには制限もあります。これについては、以下の段落で説明します。
最後に、グラフデータベースは別のクラスですが、従来はNoSQLに分類されていました。 実際の生活で遭遇するのと同じ論理に基づいて、より自然な情報の提示を提供します。 各ソーシャルネットワークがグラフであり、データベースネットワークモデルも実際にグラフであることは秘密ではありませんが、最新のグラフモデルが開く追加機能はありません。 したがって、グラフデータベースは開発者にとって特に興味深いものです。
長所と短所
リレーショナルアーキテクチャについては既に説明しました。これは、すべてがシンプルで曖昧ではない場合の優れたソリューションですが、複雑で柔軟なクエリを作成し、オブジェクト間の多様で複数の関係を処理する完全に不器用なアーキテクチャです。 ただし、複雑な（JOIN）クエリを作成する機能など、SQLデータベースの利点を忘れてはなりません。 このアプローチにより、標準化されたリレーショナルデータベースがより汎用的になります。多くのコードを使用しても、各要求をそれらに実装できるためです。 たとえば、20歳未満の赤い車を持つすべての人をSQLで検索するのは簡単ですが、NoSQLカテゴリのデータベースはこの問題を解決するために多大な労力を必要とします。
SQLの複雑なクエリの図
SQLの直接的な代替手段は、ドキュメンタリーデータベースです。 それらの主な利点は、すべての要素の単一のスキーム（スキーマレス）がないことです。 SQLとは異なり、これらのデータベースは、たとえば、1つの操作で多数のフィールドを持つドキュメントなどの複雑なオブジェクトを保存し、1つの操作で発行することもできます。 これは、たとえば、オンラインストアのカタログに商品の新しいカテゴリを追加する場合に非常に便利です。テレビ、電子レンジ、鉄にはまったく異なるプロパティが使用されるためです。 同じMongoDBでは、短いクエリを使用してそれらを操作できますが、SQLでは、このような複雑なレコードを取得および更新するには、多くのクエリを実行する特別なプロシージャを作成する必要があります。
ドキュメントデータベースにさまざまな種類のデータを保存する図
ドキュメンタリーベースの短所も、そのアーキテクチャ上の特徴に起因しています。 たとえば、ドキュメンタリーモデルは、このような単純な結合機能（JOIN）や、双方向の関係を処理する機能を意味しません。 さらに、ドキュメンタリーベースは、要素間に追加の関係がない個々の要素を保存するために設計されています。 Diasporaソーシャルネットワークの作成者が直面する困難の良い例がここにあります（ http://habrahabr.ru/post/231213/ ）。 彼らは最初、ドキュメンタリーモデルの利点を積極的に活用し始めましたが、ソーシャルデータは互いに多くのつながりを持っているという事実に直面しただけで、個別の「ドキュメント」の形で想像するのは非常に困難です。 そして、彼らはまだSQLに戻らなければなりませんでした。
ドキュメンタリーストレージモデルが適合しなかったソーシャルデータの構造
グラフについて少し説明します。 最初はオブジェクト間の接続に向けられており、これらの接続には異なる特性があります。 たとえば、顧客が各シリーズの各エピソードに異なる俳優が関係するシリーズのデータベースを開発することを要求する場合、ドキュメンタリーデータベースに完全に適合する階層モデルが最も明確に現れます。 ただし、顧客が「聞いて、私たちのシステムに俳優のフィルモグラフィーもワンクリックで表示させる」と言うとすぐに、階層全体がバラバラになり、データベースを変更する（長くて痛い）か、データストレージの形式を変更する必要があります。
この観点からグラフデータベースの主な利点は汎用性です。リレーショナルデータベース、ドキュメンタリーデータ、複雑なセマンティックデータを格納できるためです。 また、データベース構築モデル自体は、アーキテクチャおよび初期クエリを変更することなく、アプリケーションの開発中に変更および変更できます。 そしてそれは、何も書き換える必要がないことを意味します！
一方、少数の接続と大量のデータを使用すると、グラフデータベースのパフォーマンスが大幅に低下するため、これに留意する必要があります。 もう1つの重要な制限は、現時点では、並列アーキテクチャで適切に機能するグラフデータベースが事実上ないことです。
グラフはまだ有望ですか？
しかし、今日のアプリケーション開発について話しているので、設計プロセス中および「研磨」段階でも、データ構造に対する新しい要件がしばしば現れ、優れたモデルが突然悪くなる可能性があります。 たとえば、新しいリンクを追加すると、ドキュメンタリーデータベースが受け入れられなくなり、JOINの数が増えると、リレーショナルデータベースのパフォーマンスが大幅に低下します。 この場合、グラフは最も普遍的なオプションであることがわかり、要件を変更したり将来的に機能を拡張したりする場合に安全にプレイできます。 リレーショナルデータに追加の関係を追加する必要がありますか？ 問題ありません！ 階層的なドキュメンタリーモデルを複雑にする必要がありますか？ 簡単！
グラフデータ：多くのオブジェクト、それらの間の多くのタイプの関係
さらに、今日、グラフデータベースが機能する主な標準であるRDFが積極的に開発されています。 そして、思い出すと、SQLの標準化がリレーショナルデータベースの人気を高めました。 同時に、多くのプロジェクトが、HTTPを介した標準のWebクエリの作成に対するODataサポート、およびさまざまなタイプのクエリとデータを操作するための広範な機能を備えたSPARQLを実証しています（ここでは、リレーショナルデータベースのSQLとの類似性を引き出すことができます）。 しかし最後に、アーキテクチャの開発により、グラフデータベースのパフォーマンスは向上しており、リンクの数が少なくても、すぐにリレーショナルデータベースよりも高くなる可能性があります。 近い将来、グラフデータベースは開発者にとって聖杯のようなものになるでしょうか？