NimbusDB Web サイトから:
当社の分散ノンブロッキング アトミック コミット プロトコルにより、利用可能な任意のノードでデータベース トランザクションを処理できます。
彼らは、分散環境で ACID トランザクションを保証できると主張し、一貫性、高可用性、分断耐性のすべてを提供します。テキストからわかる限り、CAP定理の制限を克服するための彼らの「秘密」は、ネットワークパーティションを管理するためのある種の「予測可能で一貫した」方法です。
背後にあるものについて、誰かが洞察や詳細情報を持っているかどうか疑問に思っていますか?
「一貫性」という言葉には、複数の意味が考えられます。たとえば、CAP定理のCはACIDのCと同じではないのはなぜですか? .
さらに、「ACID」の C の意味についても、ある程度の議論が可能です。通常は、データベースの整合性に関連する意味で定義されます (「トランザクションは、宣言された制約に違反するデータベースの状態を確認することはありません」 -もちろん、そのトランザクション自体が作成した不整合をモジュロします」)、あるコメンターは、「トランザクションによって見られるデータベースの状態 (または、おそらくより効果的に使用されている) は、そのトランザクションが実行されている間は変化しない」ことを指していると解釈したと述べました。言い換えると、少なくとも反復可能な読み取りモードで実行されている場合、トランザクションは ACID に準拠しています。
CAP-C を「すべてのノードが同時に同じデータを見る」という意味に解釈すると、システムがデータをさまざまなノードに配布するのに忙しい間、(そのデータの古いバージョン)。(もちろん、トランザクションが MVCC で実行されている場合など、古いバージョンへのアクセスが正確に必要なものである場合を除きます。)
CAP-C を「一貫性のないデータベースの状態を確認できるトランザクションはありません」という意味で使用する場合、すべてのアクセスをロックアウトする必要があるのはユーザーの更新プロセスであることを除いて、基本的に同じことが当てはまります。その他の取引。
「トランザクションがリソース R から読み取るために特定のノード N にアクセスしたときはいつでも (R は理論的には複数のノードでアクセスできると仮定して)、そのトランザクションが R に再びアクセスするときはいつでも、次のルールを適用する必要があります。したがって、同じノード N で」、これにより「一貫性」の保証が向上すると想像できますが、ノード N が機能しなくなった場合、まさにルールが課されているため、トランザクションは R にアクセスできなくなります。他のノードで実行できたとしても。
いずれにせよ、バークレーのような機関が何らかの定理の証明にたどり着いた場合、あなたが言及したような大げさな主張を考慮すれば、マーケティングの嘘として安全だと思います.
この投稿が書かれてからしばらく経ちましたが、それ以来、NuoDB は Web サイトの製品マーケティングと技術リソースに多くの情報を追加してきました。
同社は、分散データ キャッシュ システムを使用することで、データの耐久性と ACID コンプライアンスを実現しています。彼らは今、それを「創発的アーキテクチャ」と呼んでいます: (p.6-7)
このアーキテクチャは、「タイムトラベル」、以前の状態を再作成するデータベースのコピーを作成する機能など、さまざまな将来の可能性を開きます。「クラウド バースティング」、別々のグループによって管理されるクラウド システム間でデータベースを移動する機能。「coteries」は、CAP 定理に対処するメカニズムであり、DBA がネットワーク パーティションを生き残るシステムを指定して、継続的な可用性を備えた一貫性とパーティション耐性を提供します。
仕組みページから：
今日のデータベース ベンダーは、従来のシステムに 3 つの一般的な設計パターンを適用して、分散スケールアウト データベース システムに拡張しています。これらのアプローチ (Shared-Disk、Shared-Nothing、および Synchronous Commit) は、単一サーバー展開の制限の一部を克服しますが、複雑でエラーが発生しやすいままです。
NuoDB のテクニカル ファウンダーである Jim Starkey は、一歩下がってデータベース設計を根本から再考することにより、Durable Distributed Cache (DDC) と呼ばれるまったく新しい設計アプローチを思いつきました。最終的な効果は、コモディティ マシンおよび仮想マシン上で動的にスケールアウト/スケールインし、単一障害点がなく、完全な ACID トランザクション セマンティクスを提供するシステムです。
NuodDB の NewSQL モデルと従来の RDMS システムのアーキテクチャの主な違いは、NuoDB がメモリとストレージの間の従来の関係を逆転させ、分散 DRAM キャッシュと同様の基本設計を持つ ACID 準拠の RDBMS を作成することです。NuoDB耐久分散キャッシュページから:
現在までのすべての汎用リレーショナル データベースは、ストレージ中心の前提に基づいて設計されています。残念ながら、これはスケールアウトに関して根本的な問題を引き起こします。事実上、これらのデータベース システムは、ユーザーが互いに干渉しないように、ディスク ベースのファイルへの同時読み取り/書き込みアクセスを調整する凝ったファイル システムです。
NuoDB DDC アーキテクチャはこの考えを覆し、必要に応じてディスクにオーバーフローし、耐久性のためにバッキング ストアに保持できるインメモリ コンテナー オブジェクトのセットとしてデータベースを想像します。
NuoDB DDC アーキテクチャ内のすべてのサーバーは、オブジェクト (Atom と呼ばれる) を要求および提供できるため、相互にピアとして機能します。一部のサーバーは常にオブジェクトのサブセットを保持しているため、データベースのサブセットのみを他のサーバーに提供できます。他のサーバーはすべてのオブジェクトを持っており、それらのいずれかを提供できますが、メモリに常駐していないオブジェクトを提供するのは遅くなります。
NuoDB は 2 種類のサーバーで構成されています。トランザクション エンジン (TE) はオブジェクトのサブセットを保持します。Storage Manager (SM) は、すべてのオブジェクトの完全なコピーを持つサーバーです。TE は、ディスクを使用する必要がないピュア イン メモリ サーバーです。それらは自律的であり、必要に応じてメモリからオブジェクトを一方的にロードおよびイジェクトできます。TE とは異なり、SM は使い終わったオブジェクトを床に落とすことはできません。代わりに、耐久性のある保管場所に安全に保管する必要があります。
キャッシング アーキテクチャに精通している方は、これらの TE が実質的に分散 DRAM キャッシュであり、SM が耐久性を保証する特殊な TE であることを既に認識しているかもしれません。そのため、永続分散キャッシュという名前が付けられました。
また、サブシステム コンポーネントと、NoSQL システムのほとんどのパフォーマンスを備えた ACID 準拠の RDMBS を提供するために連携する方法について詳しく説明したテクニカル ホワイト ペーパーも公開しています (注: ホワイトをダウンロードするには、サイトに登録する必要があります)。紙）。一般的な要点は、自動化されたネットワーク クラスタ パーティショニング システムを提供し、永続的なストレージ システムと組み合わせると、CAP Theoremの問題に対処することです。
オンラインドキュメントライブラリには、技術に関する多くの有益なテクニカルホワイトペーパーと独立した分析レポートもあります