ディレクトリ
1.はじめに
リレーショナル・データベースは、基本的なリレーショナルデータモデルからの基本的なモデルは、SQL言語のサポート、取引メカニズム、完全性保護およびその他の機能のほとんどの実装では、異なるデータベース製品の設計はまた、相互にリンクまたは類似しています。
NoSQLのデータベースは、NoSQLのは、集合的に、種々の分散非リレーショナルデータベースとして見ることができる用語非常に異なっており、単一のモデルは存在しません。しかし、NoSQLのデータモデル上の一つの共通点は、伝統的な意味での構造のランクを採用するつもりはありません。例：ネストされた行の構造（原子性要件が満たされていない）、無固定範囲と列名（ドメインは、完全性の要件を満たしていない）、テーブルの構造を事前に定義されていません。
キーモード、列ストレージモード、ドキュメントストレージモードとストレージモード：共通のNoSQLデータ・モデルは次の形式を持っています。前記アプリケーションキーモード、保存モード、及び文書格納カラム広いパターン、一般に指向従来のリレーショナルのデータ・モデルとは異なる重合のためのデータモデルと呼ばれます。
注：発生する分散問合せのシナリオと管理の最大数を満たすためにNoSQLのデータ、およびリレーショナルデータベースの比較、のNoSQLデータベースの一般的な、トランザクション機能に大きなギャップがあるが、大規模な分散展開でデータ検索および他の利点の観点。NoSQLのはそのため「より良い」モデルとみなすことができないものを、リレーショナルデータベース、NoSQLのデータモデルと関係なくの代用として見ることができない、その長所と短所がビジネスニーズと需要シナリオの弱点に基づいて、客観的、柔軟な使用。
2、メモリモードキー
2.1はじめに
- キーと値のペアモードは、キーと値のモードです。
- 各データテーブルは、行の実際のCCB（キー）と値（値）は、2つの基本的な要素を有しています。
- 値は、任意の型、あるいは配列であってもよく、別の記憶領域として見ることができます。実際のソフトウェア実装では、完全に異なる（各列の値は、異なる名前を有していてもよく、キーに対応する異なる値は、完全に異なるコンテンツであってもよい、すなわち、タイムスタンプ列の名前と他の情報を格納することができます列）。したがって、テーブルの構造は、（テーブルには、その範囲など列を含む）は、このテーブルモデルの鍵は、非構造化であることを、事前に設計することができません。
- 使用時には、同じ行にCCB同じ行は、論理（タプルの概念に類似）として扱われます。
2.2特長
- 迅速な位置決めモードキーに適したキーデータに基づいて、また、より高速なデータの場所を達成するために、キーやパーティションによってソートすることができます。
- コンテンツの値で検索を行うには、テーブル全体のトラバース、ビッグデータのシーンでの非効率性を必要とします。
- キーモードが異なるノード上の手順の鍵データブロックの数に応じて、分散クラスタにデプロイされている場合、これは、検索効率が大幅に改善され、トラバースパラレルデータを達成することができます。
- リレーショナルデータベースは、リレーショナルクエリでは非常に一般的であるならば、我々は非効率的なビッグデータのシーンのデータ量に複雑な鍵データベースでのプログラミング、対象を必要としています。
- 対応する列の値が不確実なためのNoSQLデータベースのキーモードは、通常、インデックス値をサポートしていませんし、CRUD、メンテナンスおよび分散型の場合には、インデックスを再構築する必要性から搬出する際、キーが考慮に自然順序付けを取ることですインデックス、インデックス値は、セカンダリインデックス、解決するのがより困難な問題として見ることができます。
2.3例
この構造でのRedis、levelDBは、等、ならびにJavaのハッシュテーブル、構造はキーと値のストアです。
3、ドキュメントストレージモード
3.1はじめに
ドキュメントストレージモードとストレージモードキーは、いくつかの類似点を有するが、その値は、一般的に半構造化コンテンツである、半構造化マークアップ言語の何らかの方法によって記述する必要がある、例えば、方法のようにその値JSON又はXMLを整理するために、キー値記憶構造は、一般的に自分の価値観を気にしないでください。タプルは完全に異なっていてもよく、異なる文書構造に対応することができます。文書はまた、ネストされた文書であってもよく、可変長リピート属性の出現は、文書構造は、構造を事前に定義されていません。
3.2特長
- そして、ドキュメントストレージモードに比べてキーモードは、キー内部文書でキーワードクエリ構造により取得するだけではなく、強調することができます。
- 文書はあなたが従来のリレーショナルデータベースが一つのドキュメントにクエリ参加が必要なフィールドことができますので、入れ子にできるようにするため、このアプローチは、理論的には、オーバーヘッドストレージを増やすことができますが、クエリのパフォーマンスが向上します。分散システムでは、オーバーヘッドクエリに参加し、より大きな、文書保管の入れ子構造の利点はより明白です。
- 文書蓄積パターンは、典型的には、JSON、記述されたデータのようなJSON（JavaScriptオブジェクト表記）または使用します。いくつかはまた、JSONのNoSQL列グループモードに基づいて、アプリケーション層データの使用を記載しています。
3.3例
などのMongoDBやCouchDBの、
4、柱状ストレージモード
4.1はじめに
カラムストレージモードはまた、主にOLAPストレージモード、データ・ウェアハウスおよび他の場所で使用されるラインパターンを格納するためのリレーショナルデータベースと区別するために、列指向ストレージモードと呼ばれることもあります。
4.2特長
- 列指向ストレージモード、異なるファイルに格納されたデータの異なるグループに属している列または列は、これらのファイルがあっても、異なるノードにおいて、異なる位置に分散されてもよいです。
- あなたは、クエリを実行すると、列のストレージ・モデルは、例えば、カラム内のデータのクエリ最初の1000行より効果的で、その後、対応する列に格納されたデータベースの必要性、読み取り専用のファイルは、関連する列を取得することはできません必要はありません。このアプローチは、スパースワイド・テーブルを取得する行の数が多いために非常に有効です。データの量が少ない場合には、それは明らかな利点を持っていません。
- 行指向のモードでは、データテーブルの各行は、列または関与するフィールドが同じと不可分です。しかし、列指向店舗で、当該列の各行は異なっていてもよいです。
- 列ストレージモードはまだありません一般的に事前に定義された構造であり、これがキー・ストレージに似ています。これは、列ストレージモード「は、列ファミリ、」列の家族が列数の集合であるという概念によって、データを整理することがあり、数や名前は任意であることは注目に値します。
4.3例
大きなテーブルとDremal、C-店のほか、カサンドラとHBaseのは、列ストレージモードを使用します。
5、図ストレージモード
5.1はじめに
グラフ理論に由来図ストレージモードトポロジ。図ストレージモードは、ストレージノードとノードとエッジの間の特別な関係の接続トポロジを記憶する方法です。ノードとエッジは、本明細書のパラメータで、エッジが方向であるベクターである、単方向または双方向であり得ます。例えば、ノードとして理解することができる情報、「李」と「張」、ノード間の双方向関係の存在「教師は、Li張であり、」「yは教師はX。」このトポロジは、図ERと同様であるが、図ストレージモードでは、「関係」とノードは、データそのものではなく、リレーショナルデータベースに、「関係」とERデータ構造は、図で説明されています。
5.2特長
- 図ストレージモードでは、各ノードは、高速ルーティングを達成するために、接続されたオブジェクトを指すようにそのポインタの全てを有する必要があります。従来の2次元テーブルのモデルよりので、図ストレージモード簡単検索及び処理パス。
- パターンデータベースノードが相互に接続されているので、このようにデータの断片化が困難と分散展開です。
5.3例
Neo4j、GraphXモジュールのApacheのスパーク。
参考：「のNoSQLデータベースの基本原理。」
