NoDBのようにRDBMのクラスターを作成できないのはなぜですか？
Nosql DBMSの大きなプラスの1つは、より簡単にクラスター化できることです。おそらくNoSQLを使用すると、さまざまなデータを格納し、一度にクエリを実行する数百の安価なマシンを作成できます。
私の質問はこれです、なぜリレーショナルDBMSはmysqlまたはsqlサーバーのようにこれを行うことができないのですか？ベンダーが既存の製品でこれを行うための技術的な方法を考え出していないのですか、それともこれを実行できないようにするリレーショナルモデルに問題があるのですか？ NoSQLがデータ（キー/値、ドキュメントなど）を格納およびアクセスする方法で、これが真実である場合にクラスタリングを容易にする優れた点は何ですか？
分散データベースシステム101
または分散データベース-FKの意味 ' web scale 'は実際にどういう意味ですか？
分散データベースシステムは複雑なクリッターであり、さまざまなフレーバーがあります。私が大学でこれについてのぼんやりと覚えている研究の深さを掘り下げたら、分散データベースシステムを構築するための主要なエンジニアリング問題のいくつかを説明しようとします。
まず、いくつかの用語
ACID（原子性、整合性、分離、および耐久性）のプロパティ： これらは、望ましくない副作用を引き起こさずにトランザクションを確実に実装するために適用する必要がある主要な不変条件です。
Atomicity は、トランザクションが完了するか、完全にロールバックする必要があります。部分的に完了したトランザクションが表示されないようにする必要があります。システムは、これが発生しないように構築する必要があります。
Consistency は、トランザクションがデータベーススキーマによって保証される不変（宣言的な参照整合性など）に違反してはならないことを要求します。たとえば、外部キーが存在する場合、存在しない親を尊重する子レコードを挿入することはできません。
Isolation は、トランザクションが互いに干渉しないようにする必要があります。トランザクションが並列または順次実行される場合、システムは同じ結果を保証する必要があります。実際には、ほとんどのRDBMS製品は、パフォーマンスと分離をトレードオフするモードを許可します。
Durability コミットすると、トランザクションはハードウェアまたはソフトウェアの障害に対して堅牢な方法で永続ストレージに留まる必要があります。
以下に、分散システムに存在するこれらの要件の技術的なハードルのいくつかを説明します。
共有ディスクアーキテクチャ： クラスタ内のすべての処理ノードがすべてのストレージにアクセスできるアーキテクチャ。これは、データアクセスの中心的なボトルネックになる可能性があります。共有ディスクシステムの例は Oracle RAC または Exadata です。
Shared Nothing Architecture： クラスター内の処理ノードに、他のクラスターノードからは見えないローカルストレージがあるアーキテクチャ。シェアードナッシングシステムの例は Teradata および Netezza です。
共有メモリアーキテクチャ： 複数のCPU（またはノード）がメモリの共有プールにアクセスできるアーキテクチャ。最近のほとんどのサーバーは、共有メモリタイプです。共有メモリは、キャッシュやアトミック同期プリミティブなど、分散システムで実行するのがはるかに難しい特定の操作を容易にします。
Synchronization： 複数のプロセスまたはスレッドによる共有リソースへの一貫したアクセスを保証するためのさまざまな方法を説明する一般的な用語。一部のネットワークアーキテクチャ（TeradataのBYNETなど）には、ネットワークプロトコルに同期プリミティブがありましたが、これは共有メモリシステムよりも分散システムで行うのがはるかに困難です。同期には、かなりの量のオーバーヘッドが伴います。
Semi-Join： 分散システムの2つの異なるノードに保持されているデータを結合するのに使用されるプリミティブ。基本的には、結合を解決するために、結合して1つのノードから別のノードに渡される結合に関する行に関する十分な情報で構成されます。大規模なクエリでは、これは大量のネットワークトラフィックを伴う可能性があります。
Eventual Consistency： 分散システムのすべてのノードでの即時更新（読み取り時の一貫性）とパフォーマンス（したがってトランザクションスループットの向上）のトレードオフとなるトランザクションセマンティクスを表す用語書き込み。結果整合性は、パフォーマンスの最適化として Quorum Replication を使用して、データの複数のコピーが別々のノードに保持されている分散データベースでトランザクションのコミットを高速化することの副作用です。
Lamportのアルゴリズム： 共有メモリのないシステム間で相互排除（同期）を実装するためのアルゴリズム。通常、システム内の相互排除には、共有メモリシステムで通常のみ実用的なタイプのアトミックな読み取り-比較-書き込みまたは同様の命令が必要です。他の分散同期アルゴリズムが存在しますが、Lamportは最初のアルゴリズムの1つであり、最もよく知られています。ほとんどの分散同期メカニズムと同様に、Lamportのアルゴリズムは、クラスターノード間の正確なタイミングとクロック同期に大きく依存しています。
2フェーズコミット（2PC）： 複数の物理システムを含むデータベースの更新が確実にコミットまたはロールバックすることを保証するプロトコルファミリ。 2PCがシステム内で使用されるか、トランザクションマネージャを介して複数のシステム間で使用されるかに関係なく、2PCは大きなオーバーヘッドをもたらします。
2フェーズコミットプロトコルでは、トランザクションマネージャは参加ノードに、トランザクションがコミットされることを保証できるようにトランザクションを永続化し、このステータスを通知するように要求します。すべてのノードが「ハッピー」ステータスを返すと、コミットするようにノードに通知します。すべてのノードがコミットの完了を示す応答を送信するまで、トランザクションはまだ開いていると見なされます。コミットの完了を通知する前にノードがダウンした場合、トランザクションマネージャは、トランザクションがコミットされたことを示す肯定応答を受け取るまで、ノードが復旧したときにノードに再クエリを実行します。
Multi-Version Concurrency Control（MVCC）： 新しいバージョンのデータを別の場所に書き込んで競合を管理し、他のトランザクションが古いバージョンのデータを新しいバージョンがコミットされます。これにより、新しいバージョンを書き込み、古いバージョンを廃止としてマークするための追加の書き込みトラフィックを犠牲にして、データベースの競合が減少します。
選挙アルゴリズム： 複数のノードを含む分散システムは、障害モードが多いため、本質的に単一システムより信頼性が低くなります。多くの場合、クラスター化システムがノードの障害に対処するには、何らかのメカニズムが必要です。選挙アルゴリズムは、「リーダー」ノードが100％決定されていない、または信頼できない状況で分散計算を調整するリーダーを選択するために使用されるアルゴリズムのクラスです。
Horizontal Partitioning： テーブルは、キーによって複数のノードまたはストレージボリュームに分割できます。これにより、大きなデータボリュームを小さなチャンクに分割し、ストレージノード全体に分散できます。
Sharding： データセットは、シェアードナッシングアーキテクチャの複数の物理ノードに水平に分割できます。このパーティショニングが透過的でない場合（つまり、クライアントはパーティションスキームを認識し、どのノードに明示的にクエリを実行する必要があるか）、これはシャーディングと呼ばれます。一部のシステム（Teradataなど）はノード間でデータを分割しますが、場所はクライアントに対して透過的です。このタイプのシステムでは通常、この用語は使用されません。
Consistent Hashing： キーに基づいてパーティションにデータを割り当てるために使用されるアルゴリズム。これは、ハッシュキーの均等な分散と、バケット数を効率的に弾性的に拡大または縮小する機能によって特徴付けられます。これらの属性は、ノードがクラスターに追加または削除されると（おそらく障害が原因で）サイズが動的に変化する可能性があるノードのクラスター全体でデータのパーティション化またはロードに役立ちます。
マルチマスターレプリケーション： クラスタ内の複数のノードにまたがる書き込みを他のノードに複製できるようにする手法。この手法は、一部のテーブルをサーバー間で分割またはシャーディングし、その他のテーブルをクラスター全体で同期できるようにすることで、スケーリングを容易にします。書き込みは、クォーラムではなくすべてのノードにレプリケートする必要があるため、トランザクションのコミットは、クォーラムレプリケートシステムよりもマルチマスターレプリケートアーキテクチャの方がコストがかかります。
非ブロッキングスイッチ： 内部ハードウェア並列処理を使用して、内部ボトルネックのないポート数に比例するスループットを実現するネットワークスイッチ。単純な実装ではクロスバーメカニズムを使用できますが、これはN個のポートでO（N ^ 2）の複雑さを持ち、より小さなスイッチに制限されます。より大きなスイッチは、ノンブロッキング最小スパニングスイッチと呼ばれるより複雑な内部トポロジを使用して、O（N ^ 2）ハードウェアを必要とせずに線形スループットスケーリングを実現できます。
分散DBMSを作る-それはどれほど難しいですか？
いくつかの技術的な課題により、これを実際に行うのは非常に困難です。分散システムを構築する際に追加される複雑さは別として、分散DBMSの設計者は、いくつかのトリッキーなエンジニアリング問題を克服する必要があります。
分散システムでの原子性：トランザクションによって更新されたデータが複数のノードに分散している場合、ノードのコミット/ロールバックを調整する必要があります。これにより、シェアードナッシングシステムに大きなオーバーヘッドが追加されます。共有ディスクシステムでは、すべてのストレージがすべてのノードで認識できるため、単一のノードがコミットを調整できるため、これは問題にはなりません。
分散システムでの一貫性：上記の外部キーの例をとるには、システムが一貫した状態を評価できる必要があります。たとえば、外部キー関係の親と子が異なるノードに存在する可能性がある場合、古い情報がトランザクションの検証に使用されないようにするために、何らかの分散ロックメカニズムが必要です。これが強制されていない場合、（たとえば）子の挿入を許可する前に、その存在が確認された後に親が削除されるという競合状態になる可能性があります。
制約の適用の遅延（DRIを検証するためのコミットまで待機する）には、トランザクションの間ロックを保持する必要があります。この種の分散ロックには、大きなオーバーヘッドが伴います。
データの複数のコピーが保持されている場合（これは、セミジョインからの不要なネットワークトラフィックを回避するために非共有システムで必要になる場合があります）、データのすべてのコピーを更新する必要があります。
分散システムでの分離：トランザクションに影響するデータが複数のシステムノードに存在する場合、ロックとバージョン（MVCCが使用されている場合）はノード間で同期する必要があります。特にデータの冗長コピーが格納される可能性のあるシェアードナッシングアーキテクチャでの操作の直列化可能性を保証するには、Lamportのアルゴリズムなどの分散同期メカニズムが必要です。これには、ネットワークトラフィックに大きなオーバーヘッドが伴います。
分散システムでの耐久性：共有ディスクシステムでの耐久性の問題は、ノード間で分散同期プロトコルが依然として必要なことを除いて、共有メモリシステムと本質的に同じです。 DBMSはログへの書き込みをジャーナルし、データを一貫して書き出す必要があります。シェアードナッシングシステムでは、データの複数のコピーまたはデータの一部が異なるノードに格納されている場合があります。コミットがノード全体で正しく行われるようにするには、2フェーズコミットプロトコルが必要です。これはまた、かなりのオーバーヘッドを招きます。
シェアード・ナッシング・システムでは、ノードの損失は、システムがデータを利用できないことを意味する場合があります。このデータを軽減するために、複数のノード間でデータが複製される場合があります。この状況での一貫性とは、データが通常存在するすべてのノードにデータを複製する必要があることを意味します。これにより、書き込みにかなりのオーバーヘッドが発生する可能性があります。
NoSQLシステムで行われる一般的な最適化の1つは、クォーラムレプリケーションと結果整合性を使用して、トランザクションがコミットされたと報告する前にクォーラムに書き込むことにより、データの特定レベルの復元力を保証しながら、データを遅延してレプリケートできるようにすることです。次に、データのコピーが存在する他のノードにデータが遅延複製されます。
「結果整合性」は整合性の主要なトレードオフであり、トランザクションがコミットされるとすぐにデータを一貫して表示する必要がある場合は許容できない場合があることに注意してください。たとえば、金融アプリケーションでは、更新された残高をすぐに利用できるようにする必要があります。
共有ディスクシステム
共有ディスクシステムは、すべてのノードがすべてのストレージにアクセスできるシステムです。したがって、計算は場所に依存しません。多くのDBMSプラットフォームもこのモードで動作します。OracleRACはそのようなアーキテクチャの一例です。
共有ディスクシステムは、ストレージノードと処理ノード間のM：M関係をサポートできるため、大幅に拡張できます。 A SANは複数のコントローラーを持つことができ、複数のサーバーがデータベースを実行できます。これらのアーキテクチャーは中央のボトルネックとしてスイッチを備えていますが、クロスバースイッチにより、このスイッチは多くの帯域幅を持つことができます。一部の処理はオフロードできます。 （OracleのExadataの場合のように）ストレージノード上で、ストレージ帯域幅のトラフィックを削減できます。
スイッチは理論的にはボトルネックですが、使用可能な帯域幅は、共有ディスクアーキテクチャが大規模なトランザクションボリュームに非常に効果的に拡張できることを意味します。ほとんどの主流のDBMSアーキテクチャは、「十分に優れた」スケーラビリティと高い信頼性を提供するため、このアプローチを採用しています。ファイバーチャネルなどの冗長ストレージアーキテクチャでは、処理ノードとストレージノードの間に少なくとも2つのパスがあるため、単一障害点はありません。
シェアードナッシングシステム
シェアードナッシングシステムとは、データの少なくとも一部がノードに対してローカルに保持され、他のノードから直接見えないシステムです。これにより、中央スイッチのボトルネックが取り除かれ、データベースが（少なくとも理論的には）ノード数に合わせて拡張できるようになります。水平分割により、データをノード間で分割できます。これはクライアントに対して透過的である場合と透過的でない場合があります（上記のシャーディングを参照）。
データは本質的に分散されているため、クエリは複数のノードからのデータを必要とする場合があります。ジョインが異なるノードからのデータを必要とする場合、セミジョイン操作を使用して、あるノードから別のノードへのジョインをサポートするのに十分なデータを転送します。これにより、大量のネットワークトラフィックが発生する可能性があるため、データの分散を最適化すると、クエリのパフォーマンスに大きな違いが生じます。
多くの場合、データは非共有システムのノード間で複製され、準結合の必要性を減らします。ディメンションは通常、ファクトテーブルよりも桁違いに小さく、ノード間で簡単に複製できるため、これはデータウェアハウスアプライアンスで非常にうまく機能します。また、通常はバッチでロードされるため、レプリケーションのオーバーヘッドは、トランザクションアプリケーションの場合よりも問題が少なくなります。
シェアードナッシングアーキテクチャの固有の並列処理は、データウェアハウスに特有のテーブルスキャン/集計クエリの種類に適しています。この種の操作は、処理ノードの数にほぼ比例してスケーリングできます。準結合操作では大量のネットワークトラフィックが生成される可能性があるため、ノード間の大規模な結合ではオーバーヘッドが大きくなる傾向があります。
大量のデータを移動することは、トランザクション処理アプリケーションにはあまり役立ちません。複数の更新のオーバーヘッドにより、このタイプのアーキテクチャは共有ディスクほど魅力的ではありません。したがって、このタイプのアーキテクチャは、データウェアハウスアプリケーション以外では広く使用されない傾向があります。
シャーディング、クォーラムレプリケーション、および結果整合性
Quorum Replicationは、DBMSがデータを複製して高可用性を実現する機能です。これは、SANなどの高可用性機能が組み込まれていない、より安価な汎用ハードウェアで動作することを目的としたシステムに役立ちます。このタイプのシステムでは、読み取りパフォーマンスと冗長ストレージのために、データが複数のストレージノードに複製され、ノードのハードウェア障害からシステムを復元します。
ただし、すべてのノードへの書き込みの複製は、MノードとN書き込みの場合、O（M x N）です。これにより、トランザクションのコミットが許可される前に書き込みをすべてのノードにレプリケートする必要がある場合、書き込みは高価になります。クォーラムレプリケーションは、書き込みをノードのサブセットにすぐにレプリケートし、バックグラウンドタスクによって他のノードにレイジーに書き込むことができる妥協です。書き込みはより迅速にコミットできますが、トランザクションがクライアントにコミットされたと報告される前に、書き込みがノードの最小サブセット（クォーラム）にレプリケートされることにより、ある程度の冗長性が提供されます。
これは、バックグラウンドプロセスが残りのノードへのデータの書き込みを完了するまで、クォーラム外のノードを読み取ると、データの古いバージョンが表示される可能性があることを意味します。セマンティクスは「イベント整合性」として知られ、アプリケーションの要件に応じて受け入れられる場合と受け入れられない場合がありますが、トランザクションコミットはO(1)よりO(n)リソース使用量。
シャーディングでは、クライアントがデータベース内のデータのパーティション分割を認識する必要があります。多くの場合、「一貫性ハッシュ」と呼ばれるタイプのアルゴリズムを使用します。シャーディングされたデータベースでは、クライアントはキーをハッシュして、クラスター内のどのサーバーにクエリを発行するかを決定します。リクエストはクラスター内のノード全体に分散されるため、単一のクエリコーディネーターノードによるボトルネックはありません。
これらの手法では、クラスターにノードを追加することにより、データベースをほぼ線形の速度でスケーリングできます。理論的には、基礎となるストレージメディアが信頼できないと見なされる場合にのみ、クォーラムレプリケーションが必要です。これは、コモディティサーバーを使用する場合に便利ですが、基盤となるストレージメカニズムに独自の高可用性スキームがある場合（たとえば、SANミラーリングされたコントローラーとホスト）。
たとえば、GoogleのBigTableはクォーラムレプリケーション自体を実装していませんが、クォーラムレプリケーションを使用するクラスター化されたファイルシステムであるGFS上にあります。 BigTable（または任意の非共有システム）は、複数のコントローラーを備えた信頼性の高いストレージシステムを使用し、コントローラー間でデータを分割できます。次に、データのパーティション化により、並列アクセスが実現されます。
RDBMSプラットフォームに戻る
これらの手法をRDBMSで使用できないという固有の理由はありません。ただし、ロックとバージョン管理はそのようなシステムではかなり複雑であり、そのようなシステムの市場はかなり専門化されている可能性があります。主流のRDBMSプラットフォームはいずれもクォーラムレプリケーションを使用していません。また、使用するRDBMS製品（特に重要な導入が行われている製品）については特に知りません。
共有ディスクおよび非共有システムは、非常に大きなワークロードにスケールアップできます。たとえば、Oracle RACは63個の処理ノード（それ自体が大きなSMPマシンである可能性があります）およびSAN上の任意の数のストレージコントローラーをサポートできます。 IBM Sysplex（zSeriesメインフレームのクラスター）は、複数のメインフレーム（それぞれ独自の実質的な処理能力とI/O帯域幅）と複数のSANコントローラー）をサポートできます。これらのアーキテクチャは非常に大きなトランザクションをサポートできますTeradata、Netezza、その他のベンダーは、非常に大きなデータボリュームに対応するシェアードナッシングデザインに基づいて、高性能の分析プラットフォームを作成しています。
これまでのところ、安価で超大量の完全ACID RDBMSプラットフォームの市場は、シャーディングとマルチマスターレプリケーションをサポートするMySQLが主流です。 MySQLは書き込みスループットを最適化するためにクォーラムレプリケーションを使用しないため、トランザクションコミットはNoSQLシステムよりもコストがかかります。シャーディングにより、非常に高い読み取りスループットが可能になります（たとえば、FacebookはMySQLを広範囲に使用します）。このタイプのアーキテクチャは、読み取りが多いワークロードに適しています。
興味深い議論
BigTable は、Michael Hausenblas 下 で指摘されている非共有アーキテクチャ（基本的には分散キーと値のペア）です。私の最初の評価には、MapReduceエンジンが含まれていました。これはBigTableの一部ではありませんが、通常、最も一般的な実装（Hadoop/HBaseやGoogleのMapReduceフレームワークなど）で使用されます。
このアーキテクチャをTeradataと比較すると、ストレージと処理の間に物理的な親和性があります（つまり、ノードには共有SANではなくローカルストレージがあります）。BigTable/ MapReduceは、グローバルに見える並列ストレージシステムによる共有ディスクアーキテクチャであると主張できます。
HadoopなどのMapReduceスタイルのシステムの処理スループットは、非ブロッキングネットワークスイッチの帯域幅によって制限されます。1 非ブロッキング ただし、スイッチは、設計に固有の並列処理のために大きな帯域幅の集合体を処理できるため、パフォーマンスに対する実質的な制約となることはめったにありません。これは、ネットワークスイッチが理論的には中心的なボトルネックであっても、共有ディスクアーキテクチャ（おそらく共有ストレージシステムと呼ばれる方がよい）が大規模なワークロードに拡張できることを意味します。
元のポイントは、この中央のボトルネックは共有ディスクシステムに存在しますが、複数のストレージノード（BigTableタブレットサーバーまたはSANコントローラー）など）を持つパーティション化されたストレージサブシステムは依然として大規模に拡張できることに注意してくださいワークロード：ノンブロッキングスイッチアーキテクチャは、理論的には、ポートを持つのと同じ数の現在の接続を処理できます。
1 もちろん、利用可能な処理とI/Oスループットもパフォーマンスの制限を構成しますが、ネットワークスイッチはすべてのトラフィックが通過する中心点です。
リレーショナルデータベースは、NoSQLソリューションのようにクラスター化できます。 ACIDプロパティを維持すると、これがより複雑になる可能性があり、これらのプロパティを維持するために行われるトレードオフに注意する必要があります。残念ながら、トレードオフが正確に何であるかは、ワークロードと、もちろんデータベースソフトウェアの設計中に行われた決定に依存します。
たとえば、主にOLTPワークロードには、クラスターのスループットが適切にスケーリングされている場合でも、追加の単一クエリレイテンシがある可能性があります。この余分なレイテンシは、すべてアプリケーションに依存して、気づかれないか、実際の取引ブレーカーになる可能性があります。一般に、クラスタリングはスループットを向上させ、レイテンシを損ないますが、アプリケーションのクエリが特に並列処理に適している場合、その「ルール」でさえ疑わしいです。
私が働いている会社 Clustrix が提供するのは、比較的高速なネットワークで接続された一連の均一な計算ノードとストレージノードです。リレーショナルデータは、「スライス」と呼ばれるチャンクでインデックスごとにノード全体にハッシュ分散されます。各スライスには、ノードまたはディスクに障害が発生した場合の耐久性のために、クラスター全体に2つ以上のレプリカが分散されます。クライアントはクラスタ内の任意のノードに接続して、MySQLワイヤプロトコルを使用してクエリを発行できます。
ACIDデータベースのコンポーネントを個別に考えるのは少し不自然です。なぜなら、その多くが一緒に機能するからです。
Atomicity-Clustrixは2つのフェーズコミットを使用して原子性を保証します。 UPDATEおよびDELETE操作では、内部的にSELECTに変換してから正確なUPDATE/DELETE操作を行うため、分散ロックマネージャーを介して行をロックします。
原子性により、トランザクションに参加しているノード間のメッセージングの量が明らかに増加し、コミットプロトコルを処理するためのノードの負荷が増加します。これは、分散システムを使用する場合のオーバーヘッドの一部であり、すべてのノードがすべてのトランザクションに参加するとスケーラビリティが制限されますが、ノードは、レプリカの1つが書き込まれている場合にのみトランザクションに参加します。
Consistency-外部キーはトリガーとして実装され、コミット時に評価されます。広範囲のUPDATEおよびDELETE操作は、ロックが原因でパフォーマンスに悪影響を与える可能性がありますが、幸いなことに、これらの操作はそれほど頻繁には見られません。トランザクションがいくつかの行を更新/削除してからコミットするのがはるかに一般的です。
一貫性の他の部分は、 PAXOSコンセンサスプロトコル を介してクォーラムを維持することです。これにより、既知のノードの大部分を持つクラスターのみが書き込みを行うことができます。クラスターがクォーラムを持つことはもちろん可能ですが、データが欠落している（スライスのすべてのレプリカがオフライン）ため、これらのスライスの1つにアクセスするトランザクションが失敗します。
分離-ClustrixはコンテナレベルでMVCC分離を提供します。コミットされたトランザクションを報告する前に、適用可能なすべてのレプリカが特定の書き込みを受信するというアトミックな保証により、分離の問題がクラスター化されていない場合の問題にまでほとんど減少します。
耐久性-リレーショナルデータの各スライスは2つ以上のノードに保存され、ノードまたはディスクに障害が発生した場合の回復力を提供します。パフォーマンス上の理由で、WALが格納されているNVRAMカードが製品のアプライアンスバージョンにあることも、ここで注目に値するでしょう。多くのシングルインスタンスデータベースは、コミットごとではなく間隔でチェックポイントを設定することにより、WALのパフォーマンスを向上させます。このアプローチは、「どこまで再生するか」を行うため、分散システムでは問題があります。複雑な質問。ハードな耐久性保証を提供することで、アプライアンスでこれを回避します。
基本的な答えは、整合性モデルが異なるということです。私は、これを参照ポイントとするべきであるConcernedOfTunbridgeの回答を拡張するためにこれを書いています。
ACID整合性モデルの基本的なポイントは、システム内のグローバルなデータの状態に関して一連の基本的な保証を行うことです。これらの保証はCAPの定理の制限の影響を受けます。つまり、それらを機能させるには、トランザクションをコミットしたことをアプリケーションに通知する前に、すべての信頼できるソースを同じページに置く必要があります。したがって、マルチマスターレプリケーションは、これらの制約に遭遇しないと実行が非常に困難です。確かに、マルチマスター環境で非同期レプリケーションを開始すると、これらの保証はなくなります。 ACID整合性モデルは、重要または重要な情報を対象とした強力な整合性モデルです。
BASE整合性モデルは、重要ではない情報を対象とした弱い整合性モデルです。保証が非常に弱いため、マルチマスターシステムでこのような弱い保証を提供する機能は、保証が弱いため、より簡単に達成できます。
RDBMSは、NoSQLソリューションだけでなく、スケールも実行できます！
ただし、RDBMSがNoSQLでさえも一致できない可能性がある範囲までスケールアップできる場合とそうでない場合があります。それはそう違うだけです。強力な一貫性の保証を犠牲にすることなくスケールアウトが可能である例として、Postgres-XCを見ていきます。
これらの特定のRDBMSが行う方法は、プロキシを使用したシャーディングソリューションのようなものと、共有ディスクアーキテクチャのようなものを実装することですが、どちらよりもかなり複雑です。これらはNoSQLソリューションと同じように拡張されないため、トレードオフが異なります。
Postgres-XCモデルはTeradataに触発されたと私は理解しています。ストレージノードまたはコーディネーターとして、2つの異なる役割のノードで構成されます。コーディネーターはマルチマスター（実際のレプリケーションは含まれません）であり、ストレージノードに接続して実際のデータ処理を処理します。ストレージノードは、マスター/スレーブ構成で複製されます。各ストレージノードには、本質的にデータベースのシャードが含まれますが、コーディネーターはデータの一貫した全体像を維持します。
ここでは、責任の大幅な分離が行われます。ストレージノードはデータを管理し、制約を確認し、ローカルで強制可能な外部キー制約を設定し、少なくともデータの集約を処理します。コーディネーターは、ローカルに適用できない外部キー、および複数のデータノードから取得する可能性のあるウィンドウ処理やその他のデータの考慮事項を処理します。本質的に、コーディネーターは、ユーザーがトランザクションが分散されていることさえ知らないマルチマスター構成の分散トランザクションでACIDを可能にします。
この点で、Postgres-XCはNoSQLスケーリングオプションのようなものを提供しますが、追加の一貫性保証により、複雑さが追加されます。ただし、この種のスケーラビリティを提供する商用RDBMSがあることは理解しています。 Teradataはこれを行います。さらに、共有ディスクシステムも同様の方法でスケールアウトでき、DB2とOracleの両方がこのようなソリューションを提供します。したがって、RDBMSがこれを行うことができないと言うのはまったく不公平です。彼らはできます。ただし、これまで必要性は非常に小さかったため、ほとんどのプレーヤーが独自のソリューションを非常に手頃な価格で提供するには規模の経済が不十分でした。
最後に、VoltDBについてのメモ。 NoSQLソリューションと同様に、VoltDBは非常に特殊なツールだと思います。非常に高速ですが、マルチラウンドトリップトランザクションとディスクの耐久性が犠牲になります。これは、非常に異なる一連の懸念があることを意味します。 VoltDBは、RDBMSの先駆者がNoSQLソリューションを構築したときに得られるものです;-)。 VoltDBは、同時実行性と耐久性を方程式の外に定義しているため、高速です。耐久性は、ホスト内のプロパティではなくネットワークプロパティになり、同時実行性は、内部的に並列化されたクエリを一度に1つずつ実行することで管理されます。これは従来のRDBMSではありません（これは、従来のRDBMSができない場所に移動できるので良いことですが、その逆も非常に当てはまります）。
編集：結合の影響を考慮することも重要です。クラスター化システムでは、結合は非常に異なるパフォーマンスの問題になります。すべてが同じノード上にある場合は、パフォーマンスが向上しますが、別のノードへの往復を行う必要がある場合は、非常に高いコストがかかります。したがって、データモデルは違いを生み、クラスタリングのアプローチはパフォーマンスに影響を与えます。 Postgres-XCやPostgres-XLのようなアプローチでは、かなりの時間をかけて物事を考えることができるため、データを適切に分割し、データを結合し続けることができると想定しています。しかし、それは設計のオーバーヘッドを課します。一方、これは多くのNoSQLソリューションよりもはるかに優れており、適切に調整できます。たとえば、（Adjustで）PostgreSQLの3.5PBのデータには、基本的にログ分析であるNoSQLのようなクラスタリング戦略を使用しています。そして、私たちの設計の多くはNoSQLクラスタリング戦略に深く影響を受けています。そのため、データモデルがクラスタリングモデルも制約する場合があります。
私の答えは前の答えほどよく書かれていませんが、ここに行きます。
Ingres名声のMichael Stonebrakerは、MPP共有無列ストア（Vertica）とMPP共有無新規SQLデータベース（VoltDB）を作成しました。これは、クラスター内の異なるノード間でデータを分散し、ACIDを維持します。 VerticaはHPに買収されました。
他の新しいSQLデータベースもACIDを維持していると思いますが、それらのどれだけがクラスターなどに行を分散しているのかはわかりません。
StonebrakerがNoSQLおよび "Old SQL"に関連するNew SQLについて語ったトークは次のとおりです。 http://www.youtube.com/watch?v=uhDM4fcI2aI
MySQLクラスタリングは、マルチマスターレプリケーションとハッシュシャードをクラスター全体で使用してシャーディングできます。