noSQLデータベースがSQLよりもスケーラブルなのはなぜですか？

最近、noSQL DBMSについてたくさん読みました。CAP定理、ACIDルール、BASEルール、および基本理論を理解しています。しかし、noSQLがRDBMSよりも簡単にスケーラブルである理由に関するリソースが見つかりませんでした（たとえば、多数のDBサーバーを必要とするシステムの場合）。

制約と外部キーを保持するとリソースにコストがかかり、DBMSが配布されると、はるかに複雑になると思います。しかし、これ以上のものがあると思います。

誰かがnoSQL / SQLがスケーラビリティにどのように影響するか説明してもらえますか？

noSQLデータベースは、SQLデータベースが提供する非常に多くの機能をその性質上放棄します。

参照整合性、トランザクションなどの自動施行など。これらはすべて、いくつかの問題に対して非常に便利なものであり、単一のサーバーの外部でスケーリングするための興味深いテクニックが必要です（2つのロックが必要な場合にどうなるか考えてくださいアトミックトランザクションのテーブルであり、異なるサーバー上にあります！）。

noSQLデータベースにはすべてがありません。そのようなものが必要な場合は、自分でそれを行う必要がありますが、必要ない場合（および必要のないアプリケーションがたくさんある場合）、幸運を祈っています。DBはこれらの複雑な操作やデータセット全体のロックをすべて実行する必要はありません。そのため、多くのサーバー/ディスク/その他にデータをパーティション分割し、非常に高速に動作させることができます。

NoSQLとSQLの関係ではなく、BASEとACIDの関係です。

スケーラブルは、その構成要素に分解する必要があります。

• 読み取りスケーリング=大量の読み取り操作を処理する
• 書き込みスケーリング=大量の書き込み操作を処理する

ACID準拠のデータベース（従来のRDBMSのような）は読み取りをスケーリングできます。（可能性のある）パフォーマンスのボトルネックは、使用しないことを選択できるNoSQLに（場合によっては）不足しているもの（結合や制限など）によって導入されるため、それらは本質的にNoSQLデータベースほど効率的ではありません。クラスター化されたSQL RDBMSは、クラスターに追加のノードを導入することで読み取りをスケーリングできます。読み取り操作をどこまで拡大できるかには制約がありますが、これらはクラスターにノードを追加するにつれて書き込みを拡大することが難しいために課せられます。

書き込みスケーリングは、物事が困難になる場所です。ACID原則によって課せられるさまざまな制約がありますが、最終的に整合性のある（BASE）アーキテクチャにはありません。

• アトミック性とは、トランザクションが全体として完了または失敗する必要があることを意味するため、これを保証するためにバックグラウンドで多くの簿記を行う必要があります。
• 一貫性の制約は、クラスター内のすべてのノードが同一でなければならないことを意味します。1つのノードに書き込む場合、クライアントに応答を返す前に、この書き込みを他のすべてのノードにコピーする必要があります。これにより、従来のRDBMSクラスターのスケーリングが困難になります。
• 耐久性の制約により、書き込みが失われないようにするには、クライアントに応答が返される前に書き込みがディスクにフラッシュされていることを確認する必要があります。

特定のポイントを超えてクラスター内の書き込み操作またはノードの数をスケールアップするには、ACID要件の一部を緩和できる必要があります。

• アトミック性をドロップすると、テーブル（データのセット）がロックされる期間を短縮できます。例：MongoDB、CouchDB。
• 整合性をドロップすると、クラスターノード全体で書き込みを拡大できます。例：riak、cassandra。
• 耐久性をドロップすると、ディスクにフラッシュせずに書き込みコマンドに応答できます。例：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の効率的な使用。
• 新しい属性またはデータスキーマを動的に定義する機能。

リレーショナルデータベースがスケーリングに最適ではない理由

一般に、リレーショナルデータベース管理システムは、何十年もの間「データの永続化と取得のための万能ソリューション」と見なされてきました。彼らは広範な研究開発の努力の結果成熟し、さまざまな事業領域で大規模な市場とソリューションを非常にうまく作成しました。

スケーラビリティと新しいアプリケーション要件に対する絶えず増大するニーズは、一部のWebスケールアプリケーションにおけるこの万能のアプローチに対する不満など、従来のRDBMSに新たな課題をもたらしました。これに対する答えは、リレーショナルデータベース管理システムの優位性に挑戦するように設計された低コストで高性能なデータベースソフトウェアの新世代です。NoSQLの動きの大きな理由は、Web、エンタープライズ、およびクラウドコンピューティングアプリケーションの実装が異なるとデータベースの要件が異なるためです。たとえば、すべてのアプリケーションが厳格なデータ整合性を必要とするわけではありません。

別の例：eBay、Amazon、Twitter、Facebookなどの大規模なWebサイトの場合、スケーラビリティと高可用性は妥協することができない重要な要件です。これらのアプリケーションの場合、わずかな停止でも重大な経済的影響をもたらし、顧客の信頼に影響を与える可能性があります。

DBA.SEについて：水平スケーリングとはどういう意味ですか？

水平スケーリングは、本質的にはアップではなくビルドアウトです。大型のサーバーを購入してすべての負荷をそのサーバーに移すのではなく、1台以上のサーバーを追加して負荷を分散します。

水平スケーリングは、サーバーで複数のインスタンスを同時に実行できる場合に使用されます。通常、1台のサーバーから2台のサーバーに移動するのは、2から5、10、50などに移動するのがはるかに困難です。

並列インスタンスの実行の問題に対処すると、Amazon EC2、RackspaceのCloud Service、GoGridなどの環境を最大限に活用できます。需要に応じてインスタンスを上下させることができるため、サーバーの電力を購入する必要がなくなりますそれらのピーク負荷をカバーするためだけに使用しているわけではありません。

リレーショナルデータベースは、完全な読み取り/書き込みを並行して実行するのが難しい項目の1つです。