2年後、セスギルバートとナンシーリンチはCAPの概念を定義し、「 遅延整合性 」を形式化する研究を発表しました。これは後に「 最終整合性 」と呼ばれ、CAPの「定理」を指定された定義。 あなたが研究を読んでいない場合、それは間違いなく行う価値があります-lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf
NoSQLマーケティング担当者がこの「定理」を採用していれば、誰も必要としなかったでしょう。
事実1
CAPの一貫性は、ACIDの一貫性を意味するものではありません 。 ギルバートとリンチは、一貫性をシステム全体の読み取り/書き込み操作の単一の順序の存在として定義しています。 つまり、値Xが時刻T1に記録された場合、T2> T1の任意の時点で、ユーザーは別の書き込み操作が発生するまでXを読み取ることができます。 CAPの一貫性のより人間的な定式化-データを上書きする時間が他にない場合、ユーザーは常に自分が書いたものを読みます。 ACIDでは、この概念は原子性と一致します。
ACIDの一貫性により、キーの完全性（一意性）および外部キーの完全性（外部キーは常に既存のレコードを参照します）、およびデータスキームに記述されているすべての制限の履行がはるかに強力になります。 さらに、ACIDは、1つの操作だけでなく、多くの操作で構成されるトランザクションに対しても保証を提供します。 チケット販売などの一部のシナリオは、通常、ACIDの保証なしでは不可能です。
事実2
CAPのアクセシビリティは、あなたが考えるものがまったくないことを意味します 。 ギルバートとリンチは、アクセシビリティを、要求に応答するためにパフォーマンスが損なわれないリンクの機能として定義します。 故障とは何かは明記されていません。
クライアントの観点からは、「サーバーが利用できません」という回答と、サーバーとの直接的な通信不足は同等である可能性があります。 この論理的な欠陥により、サーバーが応答できないことは、リンク障害および別のノードへの要求を繰り返す必要性として認識される可能性があります。
つまり、インスタンスとデータベース間の通信が失われ、エラーが発生し始めた場合に、すべてのインスタンスが同じデータベースにアクセスするWebサービスには、CAPの観点からアクセスできます。
アクセシビリティを判断する上で別の論理的な欠陥があります-回答に必要な時間は制限されません。主なことは、それが有限であることです。 つまり、接続が復元されるまでにかかる限り、サービスは共通データベースにアクセスしようとする場合があります。 「そして、接続がまったく回復しない場合はどうなりますか？」-あなたは、これについてもう少し詳しく尋ねます。
したがって、CAPのアクセシビリティは、この言葉の意味のフィリピンの理解における同じアクセシビリティとはほど遠いものです。
事実3
CAPは、ネットワークパーティションが発生し、無期限に継続できると想定しています 。 ネットワーク共有とは、サーバー間で任意の数のメッセージが失われることを意味します。
一度に2つの誤解があります。
- ネットワークを無制限に長く分離すると、長期的に一貫性の特性、さらには一貫性の特性さえ満たすことは不可能です。 実際、無制限に長い分離により、Webサービスはユーザーの観点からは統一されなくなります。 ギルバートとリンチは、彼らの研究で、無限に長い分離のケースを考慮せず、失われたメッセージの以前は未知の数だけを考慮しました。
- 現在、ネットワーク共有は非常にまれです。 ギルバートとリンチは、ローカルネットワークで動作するシステムは分離されにくいと見なすことができると明示的に宣言しています。
したがって、ほとんどの情報システムとWebサイトはCAPの「定理」に該当しません。
事実4
CAPはクライアントの動作を説明しません 。 クライアントとWebアプリケーション間の通信の損失は、ネットワーク共有やサーバー障害よりもはるかに頻繁に発生します。 リクエストの繰り返しと送信の再開のメカニズムは、多くのクライアントに組み込まれています。 CAPとほぼ同時期に登場したRoy Fieldingの論文では、HTTPプロトコル（RESTサービス）に基づいてWebサービスとクライアントを構築し、耐障害性と一貫性（ACIDの意味）を最大限に高める方法について説明しています。
ほとんどの場合、RESTの原則に基づいて、CAPの観点からのアクセシビリティの欠如、場合によっては一貫性の欠如を克服できるシステム（クライアント+サービス）を構築できます。
事実5
純粋なAPシステムは役に立ちません 。 GilbertとLynchは、APの特性を実現するには、サービスが常に同じ値を返すだけで十分だと書いています。 原則として、APシステム（追加の制限を受けない）は、純粋な形でランダムな値を返すことができます。
事実6
整合性を達成するための間隔で記録が行われない場合にのみ、 最終的に 遅延整合性または整合性を実現できます。 言い換えると、サービスが一貫した状態に達するために時間Tを必要とする場合、記録が間隔Tで1回のみ発生することが必要です。
もちろん、相互接続されていないデータの記録がある場合、たとえば、DNSでさまざまなゾーンが更新される場合、問題は発生しません。 しかし、多数の接続があるデータの場合、大量の書き込み負荷で永続的に一貫性のない状態になる非常に大きな機会があります。
事実7
遅延コヒーレンスまたはコヒーレンスは最終的に保証を与えません 。 システムが長期的に一貫性のみを維持する場合、その正確性を保証することは不可能です。 すべてのリンクは、古くなったデータに依存しており、それについて知ることができません。 さらに、制限を確認するためには合意された状態に依存する必要があるため、追加の制限を導入し、保証を得るためにプログラムコードのレベルでそれらを制御することは不可能です。
おわりに
CAP-「定理」にはかなり難しい運命があります。 当初は、実用的な考慮事項に基づいた声明でした。 しかし、証明のために、正式なモデルが考案されましたが、これは現実の世界からはほど遠いものです。 CAPの「定理」がNoSQLデータベースを宣伝する方法にならなかった場合、すべてがうまくいき、論争、resみ、誤解の波を引き起こしました。 CAPを理解したことで、マーケティングの声明ではなく、実際的な考慮事項に基づいて決定を下せるようになることを願っています。