長年存在してきたリレーショナル データベース ソリューションと比較して、多くの新しいデータベース ソリューション（「NoSQL データベース」）の位置付けと目的について、多くの混乱を目にします。
まず、これらのデータベース ソリューションを 2 つのグループに分類します。
1) リレーショナル データベース。 最も一般的なものは、Microsoft SQL Server、Oracle Database、MySQL、および IBM DB2 です。 これらのRDBMSは主に大企業のシナリオで使用されるが、MySQLは例外で、主にWebアプリケーションのデータを保存するために使用され、一般的に人気のあるLAMPスタック（Linux、Apache、MySQL、PHP/ Python/ Perl）の一部となっている。
2) NoSQLデータベースとも呼ばれる非リレーショナルデータベースは最も人気があり、 MongoDB, DocumentDB、Cassandra、 Coachbase、 HBase、 RedisおよびNeo4jが挙げられる。 これらのデータベースは、通常4つのカテゴリーに分類される。 3312>
すべてのリレーショナル データベースは、トランザクション指向アプリケーション (OLTP) の管理に使用でき、ドキュメント ストアとカラム ストアのカテゴリに属するほとんどの非リレーショナル データベースも OLTP に使用できるため、混乱が増しています。 OLTPデータベースは、更新を含む頻繁で短いトランザクションを特徴とし、少量のデータに触れ、数千のトランザクションの同時性が非常に重要な「運用型」データベースと考えることができます（銀行アプリケーションやオンライン予約などの例）。 データの完全性が非常に重要であるため、ACIDトランザクション（Atomicity, Consistency, Isolation, Durability）をサポートする。 これは、データウェアハウスとは対照的です。データウェアハウスは、大量のデータに触れ、多くのリソースを必要とする長くて複雑なクエリーを特徴とする「分析型」データベースと考えられています。 更新は頻繁には行われない。
リレーショナル データベースは通常、構造化データを処理しますが、非リレーショナル データベースは通常、半構造化データ (XML や JSON など) を処理します。 このモデルは、データを行と列からなる1つまたは複数のテーブル（または「関係」）に整理し、各行には一意のキーが設定されています。 一般に、データベースで記述される各実体タイプは、行がそのタイプの実体のインスタンスを表し、列がそのインスタンスに帰属する値を表す独自のテーブルを持つ。 テーブルの各行は一意なキーを持つので、あるテーブルの行は、リンク先の行の一意なキーを格納することで他のテーブルの行とリンクできる（このような一意なキーを「外部キー」として知られている）。 コッドは、任意の複雑なデータ関係をこの単純な概念のセットを使用して表現できることを示した。
事実上すべてのリレーショナル データベース システムは、データベースを照会および保守するための言語として SQL (Structured Query Language) を使用している。 たとえば、比較的単純な SELECT ステートメントには、何十もの潜在的なクエリ実行パスがあり、クエリ最適化装置は実行時にそれらを評価します。 これらすべてはユーザーには見えませんが、RDBMS はコストベースのアルゴリズムなどを使用して、リクエストに答えるための最適な「実行プラン」を決定しています。 大規模なワークロードを持つ環境 (Amazon など) でますます多くのアプリケーションが作成されているため、スケーラビリティ要件は非常に迅速に変化し、非常に大きくなる可能性があります。 リレーショナル・データベースはよく拡張されますが、通常はその拡張が1台のサーバーで行われる場合のみです（「スケールアップ」）。 その単一サーバーの容量に達すると、「スケールアウト」してその負荷を複数のサーバーに分散させる必要があり、いわゆる分散コンピューティングに移行することになります。 このとき、リレーショナルデータベースの複雑さが、その拡張性に問題を引き起こし始めます。 何百台、何千台というサーバーに拡張しようとすると、その複雑さに圧倒されてしまいます。 リレーショナル データベースを魅力的なものにしている特性は、大規模な分散システムのプラットフォームとしての実行可能性を大幅に低下させるものでもあります。
非リレーショナル データベース
NoSQL データベースは、リレーショナル データベースで使用される表形式の関係以外の方法でモデル化したデータの保存および検索のためのメカニズムを提供するものです。 アプリケーションを書くためのオブジェクト指向アプローチと、リレーショナル データベースのスキーマベースのテーブルと行の間の「インピーダンス不整合」に対処する必要がないこと。 たとえば、顧客の注文情報をすべて 1 つのドキュメントに格納すると、多くのテーブルを結合する必要があるのとは対照的に、記述、デバッグ、および保守のためのコードが少なくなる
特定の NoSQL データベースが適しているかどうかは、それが解決しなければならない問題によって異なります。 データベースが、企業内アプリケーションでは最大でも数百人のユーザーだったのが、Web アプリケーションでは数千人または数百万人のユーザーになったとき、Web の導入とともに普及しました。 NoSQL システムは、SQL ライクなクエリ言語もサポートすることを強調するために「Not only SQL」とも呼ばれています。
多くの NoSQL ストアは、可用性とパーティション耐性を優先し、（CAP 定理の意味での）一貫性を犠牲にしています。 NoSQL ストアの採用を阻む理由には、低レベルのクエリ言語の使用、標準化されたインターフェースの欠如、既存の SQL への莫大な投資などがあります。 また、ほとんどのNoSQLストアは真のACIDトランザクションを備えていないか、特定の状況や特定のレベル（ドキュメントレベルなど）でのみトランザクションをサポートしています。 最後に、多くの NoSQL ソリューションがコマンドライン インターフェイスを使用するのに対し、RDBMS は GUI を備えているため、通常はるかにシンプルに使用できます。 銀行の例で説明すると、顧客と銀行の関係の各側面は、別々のテーブルの別々の行項目として保存されます。 つまり、お客様のマスター情報はあるテーブルに、口座情報は別のテーブルに、融資情報はさらに別のテーブルに、投資情報はまた別のテーブルに、というように。 これらのテーブルはすべて、主キーや外部キーなどの関係を使用して互いにリンクされています。
非リレーショナル データベース、特にデータベースのキー-値ストアまたはキー-値ペアは、このモデルとは根本的に異なっています。 キーと値のペアを使用すると、同じテーブルのデータの 1 つの「行」に複数の関連する項目を格納することができます。 ここで「行」という言葉を引用符で囲んでいるのは、ここでの行はリレーショナル・テーブルの行と実際には同じものではないからです。 例えば、同じ銀行の非リレーショナルテーブルでは、各行には顧客の詳細と、口座、ローン、投資の詳細が含まれます。 3312>
これは明らかに優れたデータ格納方法のように見えますが、大きな欠点があります。キーバリュー ストアはリレーショナル データベースと異なり、データ項目間の関係を強制することができないのです。 たとえば、キーバリュー データベースでは、顧客の詳細 (名前、社会保障番号、住所、口座番号、ローン処理番号など) はすべて 1 つのデータ レコードとして保存されます (リレーショナル モデルのように複数のテーブルに保存されるわけではありません)。 顧客のトランザクション（口座からの引き出し、口座への入金、ローンの返済、銀行手数料など）も、別の 1 つのデータ レコードとして保存されます。
関係モデルでは、データベース層で、たとえば引き出しが正しい銀行口座に請求されるというビジネス ロジックやルールを、主キーと外部キーによって保証および実施する、組み込みで完全なメソッドが存在します。 キーバリューストアでは、この責任はアプリケーションロジックにあり、多くの人がこの重要な責任をアプリケーションに委ねることを非常に嫌がります。 これは、リレーショナル データベースが使用され続ける理由の 1 つです。
しかし、データベースを使用する Web ベースのアプリケーションに関しては、ビジネス ロジックを厳密に適用することは最優先事項ではないことがよくあります。 最も優先されるのは、大量のユーザー リクエストを処理する能力であり、それは通常、読み取り専用のクエリです。 例えば、eBayのようなサイトでは、ユーザーの大半は単に出品された商品を閲覧するだけです（読み取り専用の操作）。 このうち、実際に入札したり、商品を予約したりする（読み書き操作）のは、ごく一部のユーザーだけです。 しかも、1日あたりのページビューは数百万、時には数十億にものぼることを忘れてはならない。 eBayのサイト管理者は、ビジネスルールの適用や読み取りと書き込みのバランスの確保といった従来の優先事項よりも、サイトのユーザーにより速くページをロードできるような素早いレスポンスタイムに関心を持っているのです。
リレーショナル モデル データベースは、データ ウェアハウスを通じて大規模な読み取り専用操作を実行するように調整および設定することができ、したがって、特にスケーリングをサポートする Analytics Platform System、Teradata、Oracle Exadata、または IBM Netezza などのリレーショナル MPP アーキテクチャを使用すると、大量のデータを照会している多数のユーザーに潜在的に対応することができます。 前述したように、データウェアハウスは一般的なデータベースとは異なり、より複雑なデータ分析に使用されるのが特徴です。 これは、主な用途が運用システムをサポートし、日々の小規模なレポートを提供するトランザクション (OLTP) データベースとは異なります。
しかしながら、OLTP アプリケーションや、リレーショナル SMP アーキテクチャの領域である多くの個別の書き込みを伴うソリューションを扱う場合、リレーショナル モデルには拡張性がないことが本当の課題です。 そこで、非リレーショナルモデルが真価を発揮するのです。 非リレーショナルモデルは、データロードを数十台、数百台、極端な場合には数千台のサーバーに簡単に分散させることができます（Google検索を考えてみてください）。 各サーバーが扱うのはユーザーからのリクエスト全体のごく一部であるため、個々のユーザーに対するレスポンスタイムは非常に良好なものとなります。 この分散コンピューティングモデルはリレーショナルデータベースでも構築できますが、特に書き込みが多い場合（つまりOLTP）、シャーディングのような技術が必要になり、アプリケーションのビジネスロジック以外の部分でかなりのコーディングが必要になるため、実装にはかなりの手間がかかります。 これは、リレーショナルモデルが、データが複数の異なるサーバーからアクセスされ、変更されたとしても、すべてのレベルでデータの整合性を維持しなければならないことを主張しているためです。 これは、クラウドコンピューティングやソーシャルネットワーキングなどの Web アプリケーションのアーキテクチャとして、非リレーショナル モデルが選択される理由でもあります。
また、非リレーショナル データベースのパフォーマンスは必要なく、HDFS にファイルを保存して Apache Hive を使用するだけで十分であることも覚えておいてください (Apache Hive は、Hadoop 上に構築されたデータウェアハウス インフラストラクチャで、HiveQL という SQL に似た言語を通じてデータの要約、クエリー、分析が可能です)。 NewSQLは最新のRDBMSの一種で、従来のリレーショナルデータベースシステムのACID保証を維持しながら、OLTPの読み書きワークロードに対してNoSQLシステムと同じスケーラブルな性能を提供しようとするものである。 ただし、OLAPスタイルのクエリには向かず、数テラバイトを超えるデータベースには適さないという欠点がある。 例としては、VoltDB、NuoDB、MemSQL、SAP HANA、Splice Machine、Clustrix、Altibaseなどがある。
多くの製品が当てはまるカテゴリを示す図：
Azure クラウドにおけるすべてのテクノロジの適合性を示す優れたグラフィックは、Understanding NoSQL on Microsoft Azure に掲載されています。
NoSQL ソリューションを使用する最重要ポイントは、何千人ものユーザーがいる OLTP アプリケーションで、スケール アウト ソリューションを必要とする非常に大きなデータベースを持っているか、JSON データ、特にこの JSON データにさまざまな構造がある場合は、これを使用することです。 また、NoSQLソリューションではデータのコピーを複数保存するため、高可用性というメリットも得られます。 ただ、パフォーマンスのために、データの一貫性や、データの結合、SQL の使用、迅速な一括更新の機能を犠牲にする可能性があることを心に留めておいてください。 MongoDB: Looking At Relational and Non-Relational Databases
10 things you should know about NoSQL databases
Introduction to Databases
Difference between SQL and NoSQL : Comparision
SQL vs NoSQL Database Differences Explained with few Example DB NoSQL, NewSQL, or RDBMS.NoSQL Databaseの違いについて。 選び方
NewSQL – RDBMS on Steroids
NoSQL vs NewSQL データベース 適材適所のツールを選択する
SQL vs NoSQL:
Oracle、NoSQLの競合に対してリレーショナルDBを擁護
Understanding NoSQL on Microsoft Azure
Meet the Avant-Garde of New Relational Databases
To SQL or NoSQL?:SQLとNoSQLのどちらが良いのか? それがデータベースの問題だ
CAP Theorem:
NewSQLで何が新しくなったのか
MongoDB vs. MySQL: データベースの比較研究
SQL と NoSQL データベースの特徴と違い