問題タブ [cap-theorem]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
distributed-computing - CAP Theorem で RDBMS Partition Tolerant が使用できないのはなぜですか?
RDBMS が CAP Theorem の CA であることについて、私が理解していない 2 つの点:
1) RDBMS はパーティション トレラントではない と書かれていますが、RDBMSはMongoDB や Cassandra などの他のテクノロジよりもパーティション トレラントではないのはなぜですか? AP または CP にするために CA をあきらめる RDBMS セットアップはありますか?
2) CAP はどのように利用できますか? マスタースレーブ設定ですか?マスターが死ぬときのように、スレーブが書き込みを引き継ぎますか?
私はDBアーキテクチャとCAP定理の初心者なので、ご容赦ください。
aerospike - Aerospike は競合の可能性がない CP モードを提供しますか?
現在、私は自分のプロジェクトで Aerospike を評価しています。RAMに収まらないデータサイズに対して、強力な一貫性(どのような状況でも値バージョンの競合が発生してはならない)と最大の耐久性(データ損失は非常に有害)を備えた単純なキー/値ストアが必要です。Aerospike は、最適なオプションの 1 つと思われます。私の唯一の懸念は、強い一貫性が本当にサポートされているかどうかです。
Aerospike ホワイトペーパーhttps://www.aerospike.com/docs/architecture/assets/AerospikeACIDSupport.pdfによると、 CP モードはサポートされていません。
より多くのドメインで Aerospike を使用できるようにするために、現在サポートされている AP モードに加えて、CP モードでクラスターを動作させるための構成を追加する予定です。
同時に、Aeospike はさまざまな一貫性の保証を提供します http://www.aerospike.com/docs/architecture/consistency.htmlしかし、たとえば write.commit_level=all によって矛盾が不可能になるかどうかは明らかではありません。一貫性。
では、単一の DC/リージョン デプロイで、どのような状況 (レプリカの障害、クラスターのパーティショニング、ネットワークの待機時間など) でも、値の競合なしで Aerospike クラスターを使用する方法はありますか? この場合、構成はどのようになりますか?
network-programming - CAP定理はなぜ面白いのか?
CAP定理について数学的に興味深いことはありますか? 証明を見ると、 2 つの形式主義にまたがる 2 つの異なるステートメントに対して 4 つの異なるケースがあるようです。CAP 定理は 3 つの自明なケースで成立し、4 番目のケースでは成立しません。これらはすべて、非常に回り道した証明技法を使用して、非常に単純なことを言っています。
3.1 Thm 1. 2 台のマシンがまったく通信していない場合、一貫したデータを含めることはできません。
3.1 当然の結果 1.1 2 つのマシンが相互にメッセージを受信するのを待つことが許可されておらず、それらの間の通信回線が任意に遅い場合、一方に書き込み、すぐに他方にクエリを実行すると、一貫性のない結果が得られます。
4.2 Thm 2. タイムアウトによる待機が許可されている 2 台のマシンがまったく接続されていない場合でも、一貫したデータを含めることはできません。
...しかし、それらの間の通信回線が最悪の場合の送信時間について保証されている場合、書き込みを実行するたびにタイムアウトを待つことができ、CAP定理は適用されません。
ここで何か不足していますか?この論文で使用されている証明手法は、将軍が攻撃を調整し、攻撃に同意する時間を設定できる丘の上の将軍の問題 (これは自明ではありません) で見られるようなものに似ているようです。それをするために、彼らは同意することに同意することはできません。しかし、それがここでどのように適用されるのかわかりません。
distributed-system - CAP定理に従うのは分散システムだけですか?
インターネットのどこかで、定理は分散システムを説明する一連の基本的な要件であると読んだことがあります。定理が分散システムにのみ適用されることを理解するのを手伝ってください。
distributed - 私の分散データベースは C+A ですか、それとも A+P ですか?
分散データベースにリカバリ メカニズムを持たせます。たとえば、ネットワーク パーティションによって分割されている場合に、両側が作業を継続できるようにし、両側がトランザクションをコミットし続け、パーティションが終了すると、最後に戻ることに同意します。共通の状態。
このシステムは :
- A+P は、パーティションを処理する組み込みの (あまり巧妙ではない) メカニズムを備えており、実行されたコミットを拒否できるという事実によって、一貫性が破られているためです。
- パーティションを実際には処理せず、状態は常に一貫しているため、C + Aですか?
- 別のより複雑なオプション?
mysql - READ_UNCOMMITED/DIRTY 分離を使用すると、ほとんどの RDMS オーバーヘッドが削減されますか?
データの一貫性、アトミック、およびトランザクションを維持するために、BASE データベースとは対照的に、RDMS のオーバーヘッドを把握しようとしています。READ_UNCOMMITED/DIRTY分離を使用すると、RDMS オーバーヘッドのほとんどが削減されますか? そうでない場合、なぜですか?