3.1. 弱酸性の特性
長い間、データの一貫性はアーキテクトや開発者にとって神聖な要素でした。すべてのリレーショナル データベースは、更新ロックと読み取りのブロック、または元に戻すログのいずれかによって、ある程度の分離を提供していました。膨大な量の情報と分散システムの出現により、一方ではそれらの一連のトランザクション操作を保証し、他方では高可用性と高速応答時間を確保することは不可能であることが明らかになりました。
さらに、1 つのレコードを更新しても、他のユーザーがシステム内の変更を即座に確認できるとは限りません。変更はたとえばマスター ノードで発生する可能性があり、レプリカは別のユーザーが使用するスレーブ ノードに非同期でコピーされるためです。動作します。この場合、一定期間後に結果が表示されます。これは結果整合性と呼ばれるもので、Facebook や Amazon を含む世界最大のインターネット企業すべてが現在取り組んでいることです。後者は、ユーザーが一貫性のないデータを確認できる最大間隔は 1 秒以内であると誇らしげに宣言しています。このような状況の例を図に示します。
このような状況で生じる論理的な疑問は、古典的に操作のアトミック性の一貫性に対して高い要求を課し、同時に高速分散クラスターを必要とするシステム (金融、オンライン ストアなど) をどうするかということです。実践してみると、これらの要件はもはや意味がありません。金融銀行システムの設計者の言葉は次のとおりです。「ATM のグローバル ネットワークで各トランザクションの完了を実際に待っていたら、トランザクションに非常に長い時間がかかり、顧客は激怒して逃げるだろう。あなたとあなたのパートナーが同時にお金を引き出し、制限を超えた場合はどうなりますか? 「お金は二人とも受け取ってください、後で解決します。」
別の例は、図に示されているホテルの予約です。結果整合性を前提としたデータポリシーを採用しているオンラインストアでは、このような状況が発生した場合の対策（自動競合解決、操作のロールバック、他のデータとの更新）を提供する必要があります。実際には、ホテルは緊急事態に備えて常に空き部屋の「プール」を確保しようとしており、これが物議を醸す状況の解決策となる可能性があります。
実際、ACID 特性が弱いからといって、ACID 特性がまったく存在しないわけではありません。ほとんどの場合、リレーショナル データベースを操作するアプリケーションは、論理的に関連するオブジェクト (注文 - 注文項目) を変更するためにトランザクションを使用します。これらは異なるテーブルであるため、これは必要です。NoSQL データベースのデータ モデルを正しく設計すると (集計とは注文と注文アイテムのリストです)、単一レコードを変更するときにリレーショナル データベースと同じレベルの分離を実現できます。
3.2. 分散システム、共有リソースなし (何も共有しない)
繰り返しますが、これはデータベース グラフには当てはまりません。データベース グラフの構造は、定義上、リモート ノード間でうまく拡散しません。
おそらくこれが、NoSQL データベース開発の主な動機です。世界中で情報が雪崩のように増加し、それを適切な時間内に処理する必要があるため、垂直方向のスケーラビリティの問題が発生しました。プロセッサ速度の成長は 3.5 GHz で止まり、ディスクからの読み取り速度も急速に増加しています。ペースが遅い上に、強力なサーバーの価格は常に複数の単純なサーバーの合計価格よりも高くなります。この状況では、従来のリレーショナル データベースは、ディスクのアレイ上にクラスタ化されていても、速度、スケーラビリティ、およびスループットの問題を解決できません。
この状況を打開する唯一の方法は水平スケーリングです。この場合、複数の独立したサーバーが高速ネットワークで接続され、それぞれがデータの一部のみ、および/または読み取り更新リクエストの一部のみを所有または処理します。このアーキテクチャでは、ストレージ容量 (容量、応答時間、スループット) を増やすには、クラスターに新しいサーバーを追加するだけで済みます。シャーディング、レプリケーション、フォールト トレランス (1 つ以上のサーバーが応答を停止した場合でも結果が取得されます)、ノードを追加した場合のデータの再配布は、NoSQL データベース自体によって処理されます。
分散 NoSQL データベースの主なプロパティを簡単に説明します。
レプリケーション - 更新時にデータを他のノードにコピーします。これにより、優れたスケーラビリティを実現し、データの可用性と安全性を向上させることができます。通常は次の 2 つのタイプに分類されます。
マスター/スレーブ:
およびピアツーピア: 
最初のタイプは、読み取りについては優れたスケーラビリティがある (どのノードからでも実行可能) が、書き込みについてはスケーラブルではない (マスター ノードに対してのみ) ことを前提としています。一定の可用性を確保するには微妙な点もあります (マスターがクラッシュした場合、手動または自動で残りのノードの 1 つがその場所に割り当てられます)。2 番目のタイプのレプリケーションは、すべてのノードが同等であり、読み取りリクエストと書き込みリクエストの両方に対応できることを前提としています。
シャーディングとは、ノードごとにデータを分割することです。
シャーディングは、速度とスループットを向上させるためのリレーショナル データベースの「要点」としてよく使用されていました。ユーザー アプリケーションはデータを複数の独立したデータベースに分割し、ユーザーが対応するデータを要求すると、特定のデータベースにアクセスしました。NoSQL データベースでは、レプリケーションと同様にシャーディングはデータベース自体によって自動的に実行され、ユーザー アプリケーションはこれらの複雑なメカニズムから独立しています。
3.3. NoSQL データベースはほとんどがオープンソースであり、21 世紀に作成されました。
Sadalaj と Fowler がオブジェクト データベースを NoSQL として分類しなかったのは第 2 の理由です (ただし、http://nosql-database.org/ では一般リストに含まれています)。オブジェクト データベースは 90 年代に作成され、あまり人気がなかったためです。 . .
NoSQL の動きは、ものすごい勢いで人気を集めています。ただし、これはリレーショナル データベースが痕跡や時代遅れになりつつあることを意味するものではありません。おそらく、これらは以前と同様に積極的に使用され、使用されるでしょうが、ますます多くの NoSQL データベースがそれらと共生して動作するでしょう。私たちは多言語永続性の時代、つまりさまざまなニーズに応じてさまざまなデータ ストアが使用される時代に突入しています。現在、競合のないデータ ソースとしてリレーショナル データベースを独占する人はいません。アーキテクトは、データ自体の性質とデータの操作方法、予想される情報量に基づいてストレージを選択することが増えています。そして、すべてがさらに面白くなります。
以下では、例として NoSQL Cassandra DBMS を使用して分散データベースの操作を理解しようとします。