平易な英語での最終的な一貫性
NoSQL、データグリッドなどに関するさまざまなスピーチの結果整合性についてよく耳にします。結果整合性の定義は多くのソースで異なるようです（具体的なデータストレージに依存する場合もあります）。
最終的な整合性が一般的な用語であり、具体的なデータストレージに関連していないことを誰でも簡単に説明できますか？
最終的な一貫性：
- 天気予報を見て、明日は雨が降るだろうと知っています。
- 明日は雨になると言っています。
- あなたの隣人は妻に明日は晴れるだろうと言っています。
- 隣人に明日雨が降るだろうと言います。
最終的に、すべてのサーバー（あなた、私、あなたの隣人）は真実（明日雨が降る）を知っていますが、その間にクライアント（彼の妻）は、彼女が尋ねたとしても晴れると思って去りました1つまたは複数のサーバー（あなたと私）がより最新の価値を持っていた後。
厳密な一貫性/ ACIDコンプライアンスとは対照的に：
- 銀行残高は50ドルです。
- 100ドルをデポジットします。
- どこのATMからも照会される銀行残高は150ドルです。
- 娘がATMカードで40ドルを引き出します。
- どこのATMからも照会される銀行残高は110ドルです。
アカウントで行われたすべてのトランザクションの正確な瞬間以外の実際の合計以外に、残高が反映されることはありません。
reasonなぜ多くのNoSQLシステムが結果整合性を持っているのかは、事実上すべてのシステムが完全に分散するように設計されていることです分散システムには、厳密な一貫性を維持するための超線形オーバーヘッドがあります（つまり、速度が低下し始める前にスケーリングすることしかできず、スケーリングを維持するために指数関数的により多くのハードウェアをスローする必要がある場合）。
最終的な一貫性：
- データは複数のサーバーに複製されます
- クライアントは任意のサーバーにアクセスしてデータを取得できます
- 誰かがサーバーの1つにデータの一部を書き込みますが、それはまだ残りにコピーされていません
- クライアントはデータを使用してサーバーにアクセスし、最新のコピーを取得します
- 別のクライアント（または同じクライアント）が別のサーバー（まだ新しいコピーを取得していないサーバー）にアクセスし、古いコピーを取得します
基本的に、複数のサーバーにデータを複製するのに時間がかかるため、データの読み取り要求は新しいコピーでサーバーに送られ、その後古いコピーでサーバーに送られます。 「最終」という用語は、最終的にデータがすべてのサーバーに複製されることを意味します。したがって、すべてのサーバーが最新のコピーを持ちます。
応答サーバーはデータの独自のコピーを返す必要があり、他のサーバーに問い合わせてデータの内容について相互に合意する時間がないため、低レイテンシの読み取りが必要な場合は、結果整合性が不可欠です。 ブログ投稿 を書いて、これをより詳細に説明しました。
アプリケーションとそのレプリカがあると思います。次に、新しいデータ項目をアプリケーションに追加する必要があります。
次に、アプリケーションはデータを以下に示す他のレプリカに同期します
一方、新しいクライアントは、まだ更新されていない1つのレプリカからデータを取得します。その場合、彼は正しい日付データを取得できません。同期には時間がかかるからです。その場合、最終的に一貫性がない
問題は、どうすれば最終的に一貫性を得ることができるか？
そのために、メディエーターアプリケーションを使用してデータを更新/作成/削除し、直接クエリを使用してデータを読み取ります。 最終的に一貫性を保つのに役立ちます
アプリケーションが1台のマシン上のデータ項目に変更を加えた場合、その変更は他のレプリカに伝播される必要があります。変更の伝播は瞬間的ではないため、一部のコピーには最新の変更があり、他のコピーにはない期間があります。言い換えると、コピーは相互に矛盾します。ただし、変更は最終的にすべてのコピーに反映されるため、「結果整合性」という用語が使用されます。最終的な一貫性という用語は、1台のマシンで行われた変更を他のすべてのコピーに伝播する際に無制限の遅延があることを単に確認するものです。集中化（シングルコピー）システムでは、伝播の必要がないため、結果整合性は意味がありません。
ソース： http://www.Oracle.com/technetwork/products/nosqldb/documentation/consistency-explained-1659908.pdf
簡単な英語で言うと、システムは一貫性のない状態にある可能性がありますが、目的は常に各データのある時点で一貫性を保つことです。
最終的な一貫性は、スペクトルのようなものです。片方には強い一貫性があり、もう片方には最終的な一貫性があります。中間には、スナップショットのようなレベルがあり、私の書き込みを読み、古くなったものがあります。 Doug Terryは 野球を通しての最終的な一貫性に関する彼の論文 で美しい説明をしています。
私によると、結果整合性は基本的に、データストアから読み取るたびにランダムな順序でランダムデータを許容することです。それよりも優れているのは、より強力な一貫性モデルです。たとえば、スナップショットには古いデータがありますが、再度読み取ると同じデータが返されるため、予測可能です。時には、アプリケーションは、一定の期間にわたって失効したデータを許容でき、それを超えると一貫したデータが要求されます。
一貫性の意味を見ると、それはより均一性や逸脱の欠如に関係しています。そのため、コンピューターシステム以外の用語では、予期しない変動に対する許容を意味する場合があります。 ATMを介して非常によく説明できます。 ATMはオフラインになる可能性があるため、コアシステムのアカウント残高とは異なる場合があります。ただし、一定の時間内に異なる残高を表示することは許容されます。 ATMがオンラインになると、ATMはコアシステムと同期し、同じバランスを反映できます。したがって、ATMは最終的に一貫していると言えます。
最終的に一貫性とは、変更が反映されるまでに時間がかかり、同じアクションやデータの変換であっても、すべてのアクションの後にデータが同じ状態にならない可能性があることを意味します。これにより、このようなシステムとやり取りするときに自分が何をしているかわからない場合、非常に悪いことが起こる可能性があります。
この概念をよく理解するまで、ビジネスに不可欠なドキュメントデータストアを実装しないでください。ドキュメントデータストアの実装を台無しにすることは、リレーショナルモデルよりも修正するのがはるかに困難です。なぜなら、それを修正するために必要なものがエコシステムに存在しないため、台無しになる基本的なものは単に修正できないからです。機内ストアのデータのリファクタリングは、RDBMSの場合の単純なETL変換よりもはるかに困難です。
すべてのドキュメントストアが同じように作成されるわけではありません。最近では（MongoDB）ある種のトランザクションをサポートしていますが、データストアの移行は再実装の費用に匹敵する可能性があります。
警告：ドキュメントデータストアの技術を知らない、または理解しておらず、職を失うことを恐れてRDBMSで古典的に訓練されており、ACIDシステムのみを知っていることを認めるのを恐れる開発者およびアーキテクトです。 ？）テクノロジーを知らない、またはそれを学ぶのに時間をかけない人は、ドキュメントデータストアの設計を見逃すでしょう。また、RDBMSとして、またはキャッシングなどの目的で使用することもあります。ドキュメント全体で動作するアトミックトランザクションを「リレーショナル」な部分に分解し、レプリケーションとレイテンシが重要なことを忘れ、さらに悪いことにサードパーティシステムを「トランザクション」にドラッグします。 RDBMSがデータレイクをミラーリングできるように、データレイクが機能するかどうかに関係なく、何をしているのかを知っているため、テストなしでこれを行います。その後、「注文」などの個別のドキュメントに格納された複雑なオブジェクトの「注文アイテム」が予想よりも少ないか、まったくない場合、彼らは驚くように行動します。しかし、それはあまり起こらないか、十分に頻繁に起こるので、彼らはただ前進するだけです。それらは開発の問題にぶつかることさえないかもしれません。次に、物事を再設計するのではなく、「遅延」、「再試行」、「チェック」をスローして、リレーショナルデータモデルを偽造します。これは機能しませんが、利益が得られないほど複雑になります。しかし、今では遅すぎます-事は展開され、今、ビジネスはそれで実行されています。最終的には、システム全体が廃棄され、部門が外部委託され、他の誰かがそれを保守します。それでも正しく動作しませんが、現在の障害よりも安価に障害を起こすことができます。