noSQLデータベースがSQLよりもスケーラブルなのはなぜですか？
最近、私はnoSQL DBMSについてたくさん読んだ。私は理解しています CAP定理 、 [〜＃〜] acid [〜＃〜] ルール、 [〜＃〜] base [〜＃〜] ルールと基本理論。しかし、noSQLがRDBMSよりも簡単にスケーラブルである理由（たとえば、多数のDBサーバーを必要とするシステムの場合）に関するリソースは見つかりませんでしたか？
制約と外部キーを維持することはリソースを消費し、DBMSが分散される場合、それははるかに複雑になると思います。しかし、私はこれ以外にもたくさんあると思います。
NoSQL/SQLがスケーラビリティにどのように影響するかを誰かが説明できますか？
noSQLデータベースは、SQLデータベースが本来提供する膨大な量の機能を放棄します。
参照整合性、トランザクションなどの自動適用など。これらはすべて、いくつかの問題に対して非常に便利であり、単一のサーバーの外部で拡張するための興味深いテクニックが必要です（2つをロックする必要がある場合にどうなるかを考えてください）アトミックトランザクションのテーブルであり、それらは異なるサーバー上にあります！）。
noSQLデータベースにはそれだけではありません。それが必要な場合は自分で行う必要がありますが、必要がない場合（および必要のないアプリケーションがたくさんある場合）は、なんと幸運なことでしょう。 DBは、これらの複雑な操作やデータセットの大部分にわたってロックを行う必要がないため、多くのサーバー/ディスク/その他にデータを分割して、非常に高速に動作させることが非常に簡単です。
それはNoSQL対SQLではなく、BASE対ACIDに関するものです。
Scalableを構成要素に分解する必要があります。
- 読み取りスケーリング=大量の読み取り操作を処理する
- 書き込みスケーリング=大量の書き込み操作を処理する
ACID準拠のデータベース（従来のRDBMSなど）は、読み取りをスケーリングできます。 （可能性のある）パフォーマンスのボトルネックは、NoSQLに（場合によっては）使用できないオプション（結合やwhereの制限など）がないために発生するため、それらはNoSQLデータベースよりも本質的に効率が悪いわけではありません。クラスター化されたSQL RDBMSは、クラスターに追加のノードを導入することで読み取りを拡張できます。読み取り操作をスケーリングできる範囲には制約がありますが、クラスターにより多くのノードを導入すると書き込みをスケールアップすることが困難になるため、制約が課せられます。
書き込みスケーリングは、物事が厄介になる場所です。 ACIDの原則によって課せられるさまざまな制約がありますが、これらは最終的に一貫した（BASE）アーキテクチャでは見られません。
- 原子性とは、トランザクションが全体として完了または失敗する必要があることを意味します。そのため、これを保証するために多くの簿記を裏で行う必要があります。
- 整合性制約は、クラスター内のすべてのノードが同一でなければならないことを意味します。 1つのノードに書き込む場合、クライアントに応答を返す前に、この書き込みを他のすべてのノードにコピーする必要があります。これにより、従来のRDBMSクラスターの拡張が困難になります。
- 耐久性の制約は、書き込みが失われないようにするために、応答がクライアントに返される前に、書き込みがディスクにフラッシュされていることを確認する必要があることを意味します。
書き込み操作またはクラスター内のノードの数を特定のポイントを超えてスケールアップするには、ACIDの要件のいくつかを緩和できる必要があります。
- 原子性を削除すると、テーブル（データのセット）がロックされる期間を短縮できます。例：MongoDB、CouchDB。
- 整合性を削除すると、クラスターノード全体で書き込みをスケールアップできます。例：riak、cassandra。
- Droping Durabilityを使用すると、ディスクにフラッシュせずに書き込みコマンドに応答できます。例：memcache、redis。
NoSQLデータベースは、通常、ACIDモデルではなくBASEモデルに従います。 A、C、Dの要件を放棄し、その結果、スケーラビリティを向上させます。 Cassandraのような一部では、必要なときにACIDの保証を選択できます。ただし、すべてのNoSQLデータベースが常によりスケーラブルであるとは限りません。
SQL APIには、ACIDの要件が緩和されているクエリを記述するメカニズムがありません。これが、BASEデータベースがすべてNoSQLである理由です。
個人的な注意：私が付けておきたい最後のポイントは、パフォーマンスを改善するためにNoSQLが現在使用されているほとんどの場合、適切なインデックスを持つ適切に正規化されたスキーマを使用することにより、適切なRDBMSでソリューションが可能になるということです。このサイト（MS SQL Serverを利用）で実証されているように、RDBMSは、適切に使用すれば、高いワークロードに拡張できます。 RDBMSを最適化する方法を理解していない人は、データに対してどのようなリスクを負っているのかを理解していないため、NoSQLを避けてください。
更新（2019-09-17）：
この回答を投稿して以来、データベースの状況は進化しています。 RDBMS ACIDの世界とNoSQL BASEの世界との間にはまだ二分法がありますが、その線はあいまいになっています。 NoSQLデータベースには、SQL APIやトランザクションサポートなど、RDBMSの世界の機能が追加されています。 Google Cloud Spanner、YugabyteDB、CockroachDBのように、SQL、ACID、の書き込みスケーリングを保証するデータベースさえあります。通常、悪魔は詳細にありますが、ほとんどの目的にとって、これらは「十分にACID」です。データベーステクノロジーの詳細と、それがどのように進化したかについては、 このスライドデッキ を参照してください（スライドのメモには付随する説明があります）。
NoSQLデータベース（MongoDB、Redis、Riak、Memcachedなど）が外部キー制約を維持しないことは事実であり、アトミック操作はより明示的に指定する必要があります。 SQLデータベース（SQL Server、Oracle、PostgreSQLなど）を拡張して、経験豊富なDBAが非常に大きなパフォーマンス要件を処理できることも事実です。
NoSQLデータベースを使用すると、競合状態とアトミック操作に精通している熟練したプログラマーが、今日のWebアプリケーションコードのごく一部でのみ必要とされる大量の処理を放棄することができます。 NoSQLデータベースには確かにアトミック操作があり、SQLデータベースに存在するほとんどすべてのトランザクション要件もNoSQLデータベースを取得できます。違いは抽象化のレベルです。 NoSQLデータベースは、より高いレベルの抽象化を削除し、その機能をアプリケーションプログラマーに渡します。その結果、コード全体が高速になり、季節性のないプログラマーによるデータ破損の可能性が高くなります。
その結果、開発時間とパフォーマンスが非常に重要であるWebアプリケーションスペースでNoSQLデータベースがますます使用されるようになる可能性が高くなります。ハードウェアのパフォーマンスは比較的安価であり、手持ちのDBAを熟練させているため、金融および企業向けソフトウェアはSQLの遺産を保持する可能性があります。
IBM developerWorksから： NoSQLデータベースでクラウドレベルのデータスケーラビリティを提供
スケーラビリティーは、非常に低いレイテンシで非常に高いリクエストレートで非常に大規模なデータベースをサポートできるシステムです。
NoSQLシステムには、多くの共通の設計機能があります：
- 多くのサーバーでスループットを水平方向にスケールアウトする機能。
- 単純な呼び出しレベルのインターフェースまたはプロトコル（SQLバインディングとは対照的）。
- ほとんどの従来のRDBMSのACIDトランザクションよりも弱い整合性モデルのサポート。
- 分散インデックスの効率的な使用とRAMデータストレージ用。
- 新しい属性またはデータスキーマを動的に定義する機能。
リレーショナルデータベースがスケーリングに最適でない理由
一般に、リレーショナルデータベース管理システムは、何十年もの間、「データの永続化と取得のための万能ソリューション」と見なされてきました。広範な研究開発努力の結果、成熟し、さまざまなビジネスドメインで大規模な市場とソリューションを非常に成功させました。
スケーラビリティと新しいアプリケーション要件へのニーズの高まりにより、従来のRDBMSには新しい課題が生じました。これには、一部のWebスケールアプリケーションでのこの万能のアプローチに対する不満も含まれます。これに対する答えは、リレーショナルデータベース管理システムの優位性に挑戦するように設計された新世代の低コスト、高性能データベースソフトウェアです。 NoSQLの動きの大きな理由は、Web、エンタープライズ、およびクラウドコンピューティングアプリケーションの実装が異なれば、データベースの要件も異なるためです。たとえば、すべてのアプリケーションに厳密なデータ整合性が必要なわけではありません。
別の例：eBay、Amazon、Twitter、Facebookなどの大量のWebサイトの場合、スケーラビリティと高可用性は妥協できない必須の要件です。これらのアプリケーションの場合、わずかな停止でも、重大な財務上の結果をもたらし、顧客の信頼に影響を与える可能性があります。
DBA.SEについて： 水平スケーリングとはどういう意味ですか？
水平方向のスケーリングは、基本的にアップではなく構築されています。大きなビーファーサーバーを購入してすべての負荷をそのサーバーに移動するのではなく、1台以上の追加サーバーを購入して負荷をそれらに分散します。
水平スケーリングは、サーバーで複数のインスタンスを同時に実行できる場合に使用されます。通常、1台のサーバーから2台のサーバーに移動するのは非常に難しく、2台から5台、10台、50台などに移動するのが難しくなります。
並列インスタンスの実行の問題に対処したら、Amazon EC2、Rackspaceのクラウドサービス、GoGridなどの環境を利用して、インスタンスを需要に応じて上下させ、サーバーの電力を支払う必要性を減らすことができます。これらのピーク負荷をカバーするためだけに使用しているわけではありません。
リレーショナルデータベースは、完全な読み取り/書き込みを並行して実行するのが最も難しい項目の1つです。