平易な英語での結果の一貫性

NoSQLやデータグリッドなどに関するさまざまなスピーチで結果の一貫性についてよく耳にします。結果の一貫性の定義は多くのソースで異なるようです（具体的なデータストレージに依存している可能性もあります）。

具体的なデータストレージとは関係なく、結果整合性の一般的な用語について簡単に説明できますか？

結果整合性：

1. 天気予報を見て、明日は雨が降るだろうと知った。
2. 明日は雨が降るだろうと言っています。
3. あなたの隣人は妻に明日は晴れるだろうと言っています。
4. あなたは隣人に明日雨が降るだろうと言います。

結局、すべてのサーバー（あなた、私、あなたの隣人）は真実（明日は雨が降るだろう）を知っていますが、その間にクライアント（彼の妻）は晴れだと思って離れましたが、彼女は尋ねました1つ以上のサーバー（あなたと私）がより最新の値を持っていた後。

厳密な一貫性/ ACIDコンプライアンスとは対照的に：

1. 銀行の残高は50ドルです。
2. $ 100を入金します。
3. どこのATMからでも照会された銀行残高は150ドルです。
4. あなたの娘はあなたのATMカードで$ 40を引き出します。
5. どこのATMからでも照会された銀行残高は$ 110です。

残高は、その瞬間にアカウントで行われたすべてのトランザクションの実際の合計以外のものを反映することはできません。

理由非常に多くのNoSQLシステムは、最終的な一貫性を持っている理由は、事実上すべてのそれらのが配布されるように設計されており、完全な分散システムで（物事を遅らせるために開始する前にのみ、これまでに拡張できることを意味し、厳密な一貫性を維持するために、超線形のオーバーヘッドがあることですダウンした場合、スケーリングを維持するには、問題が発生したときにハードウェアを指数関数的に増やす必要があります）

結果整合性：

1. データは複数のサーバーに複製されます
2. クライアントは任意のサーバーにアクセスしてデータを取得できます
3. 誰かがサーバーの1つにデータの一部を書き込みましたが、それはまだ残りのサーバーにコピーされていません
4. クライアントはデータを使用してサーバーにアクセスし、最新のコピーを取得します
5. 別のクライアント（または同じクライアント）が別のサーバー（まだ新しいコピーを取得していないサーバー）にアクセスし、古いコピーを取得する

基本的に、複数のサーバー間でデータを複製するには時間がかかるため、データの読み取り要求は、新しいコピーを持つサーバーに送信されてから、古いコピーを持つサーバーに送信される可能性があります。「最終的な」という用語は、最終的にデータがすべてのサーバーに複製され、すべてのサーバーが最新のコピーを持つことを意味します。

応答サーバーはデータの独自のコピーを返す必要があり、他のサーバーを調べてデータの内容について相互の合意に達する時間がないため、結果の整合性は低遅延の読み取りが必要な場合に必須です。私はこれをより詳細に説明するブログ投稿を書きました。

アプリケーションとそのレプリカがあるとします。次に、新しいデータ項目をアプリケーションに追加する必要があります。

次に、アプリケーションはデータを他のレプリカに同期させます

一方、新しいクライアントは、まだ更新されていない1つのレプリカからデータを取得します。その場合、彼は正しい最新データを取得できません。同期には時間がかかるためです。その場合、最終的に一貫性がなくなります

問題は、どうしたら最終的に整合性を保つことができるかですです。

そのために、メディエーターアプリケーションを使用してデータを更新/作成/削除し、直接クエリを使用してデータを読み取ります。最終的に一貫性を保つのに役立ちます

アプリケーションが1台のマシンのデータアイテムに変更を加える場合、その変更を他のレプリカに伝達する必要があります。変更の伝播は瞬間的ではないため、一部のコピーには最新の変更があり、他のコピーにはない時間間隔があります。つまり、コピーは相互に矛盾します。ただし、変更は最終的にすべてのコピーに反映されるため、「結果整合性」という用語が使用されます。結果整合性という用語は、1台のマシンで行われた変更を他のすべてのコピーに伝播するのに際限のない遅延があることの確認にすぎません。伝播の必要がないため、集中型（単一コピー）システムでは結果整合性は意味がありません。

ソース：http : //www.oracle.com/technetwork/products/nosqldb/documentation/consistency-explained-1659908.pdf

簡単な英語では、次のように言うことができます。システムが一貫性のない状態にある可能性がありますが、その目的は、常に、データの各部分についてある時点で一貫性に到達することです。

結果的に整合性とは、変更が反映されるまでに時間がかかり、同じアクションやデータの変換であっても、すべてのアクションの後でデータが同じ状態にならない場合があることを意味します。これは、そのようなシステムと対話するときに何をしているのかを人々が知らないときに、非常に悪いことを引き起こす可能性があります。

この概念を十分に理解するまで、ビジネスに不可欠なドキュメントデータストアを実装しないでください。ドキュメントデータストアの実装を台無しにすることは、リレーショナルモデルよりも修正がはるかに困難です。なぜなら、台無しにされようとしている基本的なものは、修正するために必要なものがエコシステムに存在しないだけなので、単に修正できないからです。機内ストアのデータのリファクタリングは、RDBMSの単純なETL変換よりもはるかに困難です。

すべてのドキュメントストアが同じように作成されるわけではありません。最近のいくつか（MongoDB）は一種のトランザクションをサポートしていますが、データストアの移行は再実装の費用に匹敵する可能性があります。

警告：ドキュメントデータストアのテクノロジーを知らないか理解しておらず、職を失うことを恐れて、古典的にRDBMSでトレーニングを受けており、ACIDシステムのみを知っている開発者やアーキテクト（ACIDシステムのみを知っている場合） ？）そして、テクノロジーを知らないか、それを学ぶために時間をかけない人は、ドキュメントデータストアの設計を見逃します。また、RDBMSとして、またはキャッシングなどに使用することもできます。ドキュメント全体を操作する必要のあるアトミックトランザクションを「リレーショナル」に分解し、レプリケーションとレイテンシが重要であることを忘れます。さらに悪いことに、サードパーティのシステムを「トランザクション」にドラッグします。RDBMSがデータレイクをミラーリングできるようにするために、RDBMSが機能するかどうかに関係なく、テストも行わずに、何をしているのかを知っているためです。次に、「注文」などの個別のドキュメントに保存された複雑なオブジェクトの「注文アイテム」が予想より少ないか、まったくない場合、彼らは驚いて行動します。しかし、それは頻繁に起こることはなく、十分な頻度で行われるため、前進するだけです。彼らは開発の問題にぶつからないかもしれません。次に、物事を再設計するのではなく、「遅延」と「再試行」と「チェック」を入れてリレーショナルデータモデルを偽造しますが、これは機能しませんが、複雑さを増すだけでメリットはありません。しかし、もう手遅れです-事は展開されており、ビジネスはその上で実行されています。最終的には、システム全体が破棄され、部門が外部委託され、他の誰かがそれを維持します。それでも正しく機能しませんが、現在の障害よりも安価に障害が発生する可能性があります。

結果整合性は、スペクトルのようなものです。一方の端では強い整合性があり、もう一方の端では結果整合性があります。中間には、スナップショット、私の書き込みの読み取り、限定された古さのようなレベルがあります。ダグ・テリーは野球を通しての結果の一貫性に関する彼の論文で美しい説明をしています ます。

私によると、結果整合性は基本的に、データストアから読み取るたびにランダムなデータをランダムな順序で許容することです。それより良いものは、より強い一貫性モデルです。たとえば、スナップショットには古いデータがありますが、再度読み取ると同じデータが返されるため、予測可能です。時々、アプリケーションは、一定の期間、古いデータを許容でき、それを超えると一貫したデータを要求します。

一貫性の意味を見ると、それはより均一性または偏差の欠如に関連しています。したがって、コンピュータシステム以外の用語では、予期しない変動に対する許容を意味する可能性があります。ATMを介して非常によく説明できます。ATMがオフラインになっている可能性があるため、コアシステムの口座残高とは異なります。ただし、時間枠ごとに異なる残高を表示することは許容されます。ATMがオンラインになると、コアシステムと同期し、同じバランスを反映できます。したがって、ATMは最終的には整合性があると言えます。