NoSQLをいえば、一貫性（整合性）に言及します、CAP定理によると、我々はいくつかのNoSQLデータベースの整合性をあきらめたが、NoSQLのは、それを放棄するために不可避な選択でしょうか？
1970年代からは、リレーショナルデータベース（RDB、リレーショナルデータベース）本発明は、任意のリレーショナルデータベースを構築することであるため、通常は適用されます。ACID保証、非常に便利な開発者とユーザーに提供するリレーショナルデータベース。1990年代の初めからは、NoSQLのシステムが表示されるようになりました。NoSQLデータベースシステムは、リレーショナル・データベース・システムのスタンドで、彼らはスキーマからの伝統的なリレーショナルモデルリレーショナルデータベースとSQLインタフェースをあきらめました。
二つの単語ですBASEとCAPを伴うとのNoSQLシステムは、多くの場合、これら二つの言葉は、分散システム上で非常に大きな影響を持っています。私は、これら二つの言葉の影響を受けて、初期のアーキテクチャから、多くのNoSQLシステムは、最終的な一貫性（結果整合性）と可用性（アベイラビリティ）を選んだの整合性（一貫性）を放棄すると信じています。私は非常に多くのCAPとBASEこれら二つの言葉に同意するが、私はCAPとBASEの役割を信じていないものの、NoSQLのシステムは一貫性が避けられないものである与えることを選択します。
まずは、CAPやBASEの歴史でこれら二つの概念を見てみましょう。この2つの概念は、エリック・ビール、ビールは現在、（VP、副社長）のGoogleのインフラ部門の副社長（インフラストラクチャ）であるが提示されています。1997年には、SOSP（オペレーティングシステムの原理に関するシンポジウム）に、スピーチという名前は、[1]ビール及びその他の最近の研究を要約し、彼のスピーチは、彼らが一度に取り組んでいると、クラスタサービスは、ACID特性を証明している使用していないことを言いましたリレーショナル・データベース・スキーマとしてではなく、インフラストラクチャ上のリレーショナルデータベースのACID特性をあきらめました。新しい単語BASE、BASEとして彼らの選択のアーキテクチャ及び構造の単語を選択するには、英語でACID酸性意味意図的な構図となっている、とBASEは、基本的な意味を持っている、BASEは？ACIDであることは明らかです反対。
ACIDとBASEは、略語は、以下の単語の最初の文字です：
ACID：原子性、一貫性、独立性、耐久性改訂
BASE：基本的に利用可能な、ソフトステート、結果整合性
BASEの支持者は、主に一貫性を放棄し、システムは（基本的に利用可能な）利用できる基本的な、柔軟な状態（ソフトステート）、最終合意（結果整合性）を満たすことができるように、ACID、ACIDを放棄します。システムビルダーは、ACID、またオプションとして知られているBASEを選択するつまり、ACIDとBASEのいずれかを選択することができないだけ。本質的に、つまり、ACID（一貫性）とBASEの代表に代わって一貫性の2つ（可用性）可用性の間で選択をします。BASE提案されたアーキテクチャの時がすることは、明示的に一貫性と可用性の間で選択をすることが、提案されたCAPのためのステージの後ろに十分であるされていません。
2000年までに、PODCでブリューワー（分散コンピューティングの原則）と題した講演を行いました[2]、基調講演には、堅牢な分散システムを構築する方法を明らかにすることです。この話で、ブリューワー近い分析及び酸と塩基との比較、およびACID一貫性（整合性）であるコア酸と塩基の抽象的特性、BASEのアベイラビリティ（可用性）、及び第3次元を拡張、ネットワークパーティション（ネットワーク・パーティション）、従って提案CAP予想これは、予想は言います：
：分散システムでは、同時に以下の3つのプロパティ2満足することができる
C（一貫性）、A（可用性）、P（ネットワークパーティションに対する耐性）を
この推測によると、システムの3種類が存在します。
そのようなそのようなシステムは、単一のデータベースとしてP放棄された、CAシステムの特性、
例えば分散データベースシステムとして、CPシステムの特性を、放棄は、分散ロックは
C、AP特性を有するシステムを放棄し、そのようなウェブ・キャッシングなどのシステム、DNSの
可用性特にインターネット業界では、非常に重要な機能である、サービス業へのダウンタイムの影響は非常に大きいので、CAP定理によると一貫性が自然な選択であるあきらめます。アマゾンCTOのWerner VOGELS紙を詳細に特に最終的に一致[5]とユーザビリティの多数の出版後にAmazonのダイナモシステム[12]システムが現れるのNoSQLの一貫性の追求を放棄します。
2002年では、ギルバートとリンチは、[3]、そう、これらの3つの属性は、（レンジブリュワー予想の属性よりもはるかに小さい属性を再定義）CAPを再定義し、これらの3つの属性を同時に達成することはできませんCAPを証明しましたCAPは、容疑者CAP定理となりました。
：CAP定理は、[3,6]次のように3つの属性がある定義
一貫性：一貫性は一貫性、少数のシステムの非常に高いレベルである原子（原子一貫性）または線形コヒーレンス（線形化一貫性）を指しこれを達成することができます。
可用性：つまり、各読み出しおよび書き込み要求が妥当な時間には、ダウンタイムがレスポンスを返さないすることができ、各ノードに到着した、完全な可用性を指します。ここで重要な点は、各要求が各非ダウンタイムノードに到達したということです。これは、いくつかのシステムを実現することができ、また、可用性の非常に高いレベルです。
トレラントパーティション：いくつかのシステムの特性、または整合性や可用性を維持するために、つまり、正しく応答し続け、ネットワークパーティションが発生した場合にできるシステムを指します。
GlibertとリンチCAP定理は非常に厳格な再定義が、唯一の3つの属性は、両方を持つことはできません証明しました。その理由は、しかし、ブリュワー予想3定義属性の後、3選挙は、3ポイントの分類（AP、CP、CA3種の分類は）非常に厳密ではない、2を説明したCAPが発生している、多くの人が疑問とCAPに挑戦します。2012年のビールは、記事を再書いた[4]、また、元のCAPは非常に誤解を招く表現することを認めました。実際には、CAP定理の適用範囲は非常に小さいです。誕生からCAPが、多くの問題があるが、それはまだのNoSQL運動を推進し、多くのシステム・アーキテクチャは、CAP定理に基づいており、一貫性をあきらめ、実際には、これらのシステムは、多くの場合、CAP定理の範囲に満足していません。
CAPは2017年に、ビールは、Googleのインフラ（インフラ）部門（VP、副社長）の副社長であったが、この物語の終わりではありません、その後、Googleと、同社の第一世代のシステムは、スパナ[9生まれてきました]。ビールは、Googleのスパナシステム[7]、および前方CAP定理のスパナに従って詳述一歩を踏み出しについての記事を書いたものな特性のシステムです。この論文では、ブリューワーは、「事実上のCA」（有効CA）システムとも言わスパナシステムを指摘しました。アーキテクチャ的に言えば、スパナは、そのネットワークパーティションがある場合に、スパナの選択は、可用性を放棄し、データの一貫性を確保することであると言うことです、CPシステムです。しかし、実際には、スパナは、アーキテクチャからスパナは、CAP定理の完全な可用性の要件に達していなかった、非常に高可用性システムの効果を持つだけでなく、非常に高い可用性、設計の複数のコピー、ネットワークパーティションの出現の個々のコピーの使用に達していますこれにより、ユーザーの知覚可用性に影響を与えません。定義CAP定理、ネットワーク・パーティションの出現のこれらの個々のコピーすることで、これらのノードはつまり、システムが完全な可用性に到達していない、利用できません。しかし、ユーザーの要求は、他のコピー・サービスをサービスすることができ、この時間は、ユーザーがまだスパナが使用可能である感じることを意味し、この時点でご利用いただけます。だから、CAP定理の可用性の使いやすさと使用者の認識は概念ではありません。私たちは、ユーザの知覚可用性を追求する必要があります。
ユーザーは、可用性を、知覚、通常表現SLAは、つまり、我々は通常、いくつかの9の可用性と言います。ネットワークパーティションに利用可能なサービスの割合が比較的小さいため、記事のビールもSLAスパナシステム上のGoogleのデータを与え、我々は、データから見ることができ、そのようなサービスの原因の大部分は使用できません誤用の結果として、ソフトウェアの不具合、設定エラー、運用・保守。これは、CAP定理の必要な可用性を実現するために採用したフレームワークは、ユーザーが実際のサービスの可用性を感じることができにおいても、ある、SLAはあまり改善されません。これは、システム開発者からより多くの不安定なシステムの毎日のターンオーバーは、より大きなシステムの可用性を向上させ、生産運用・保守基準を強化するために標準化されたプロセスの開発を強化し、コードの品質を強化する医師のように多くの年の私の経験です。一貫性の可用性を頻繁にろうそくの価値はありませんので、だから、アーキテクチャレベルで、あきらめました。
クラウドコンピューティングの潮流は、一貫性も非常に賢明であるあきらめないでください。クラウドでホストされたデータ・ストレージ・サービス、およびあなたが一貫選択可用性をあきらめた場合、ユーザーは、あなたのサービスのために、建築設計の手の届かないところのCAP定理の可用性を使用するためのユーザを払っていますので、ユーザーエクスペリエンスは、明らかにされていませんSLAの賃金を満たしています。しかし、データ・ストレージ・サービスは、ユーザーが非常に明白で感じることができている、一貫しています。ダイナモ[12] Amazonの内部アーキテクチャは、CAP定理の可用性要件に達成することができますが、アマゾンAWSクラウド上でこのような理由[10]のために、おそらく、このアーキテクチャを使用してDynamoDBのが販売されていません。
だから我々は、一貫性の恩恵を選ぶ何それですか？それは一貫性に来るとき、多くの場合、お金は、金融と一貫性の必要性に関連した例を取るだろうが、私は金融業界が強い整合性[10]に依存しないと信じています。私は一貫性は、開発の利便性である私をもたらしたと思います。ビールはBASEの概念を提案したが、彼はこの概念について詳しく説明しませんでした。が、2008年にeBayのダンプリチェットは、再び記事を書いた[8]、一例として、同じ需要BASEを達成するためのフレームワークを使用する方法ACIDを、放棄した以降で詳述、BASEは、私たちに、このアーキテクチャのパターンをお勧めします。この記事を通して、私たちは選択ACID BASEをあきらめた場合、その後、非常に簡単な関数、結果整合性、全体的なアプリケーションアーキテクチャの複雑な多くのことを達成するシステムのために、このようなメッセージキューなどのツールが必要であったであろうことがわかります。
プリチェットは、NoSQLのシステムの一貫性を持っていない記事、と同様に説明し、あなたの使用シナリオを使用すると、一貫性を放棄させることができるかどうかを判断するために慎重に選別あなたのシーンを使用する必要があります。あなたはBASEアーキテクチャを使用したい、またそれは単に結果整合性とのNoSQLシステムを使用している場合でも、うまくACIDデータベースを交換するには、最終的な一貫性を持ってきた異常のNoSQLシステムの配置された種々の手段を、設計する必要がありますそして、あなたのアプリケーション全体が柔軟な状態と最終合意を達成することができます。BASEは、最終的な合意に言及し、多くのNoSQLシステムは、最終的にいくつかの微妙な違いを合意しています。違いは、最終的な合意に言及したBASEは、システムの状態が正しいことを確認することで、シンプルであり、多くのNoSQLシステムは、最終的に最終合意することを確実にするためにのみ同意したが、この状態はあなたが[11]何をしたい正しい状態であることを保証するものではありません。
最後に、ビューの個人的な点は、低レイテンシを追求するために、彼らは一貫シーン、ビッグデータとオフラインのコンピューティングを与えることができ、キャッシュとして使用するのNoSQLシステムは、このシナリオに類似している場合、多くのNoSQLシステムは非常に適しているということです。しかし、 NoSQLのデータベースシステムに使用する場合は、NoSQLのシステムがあるため一貫性の可用性をあきらめることが最善ではありません、同時にマルチコピー技術と優れた輸送ベイダーを通じて、実際の在庫状況、つまりは仮想CA（効果的にCA）の時点で、大幅にできます使用するユーザーの負担を軽減。
スペース制限が原因、この記事では、議論個別に書き込まれるように、一貫性、CAP、BASE、細部へのACIDの失敗について、多くの技術的な詳細を説明します。急いで書かれた、私を修正するためにあなたを歓迎するために神に誤りや省略があります。
オリジナルリンク
この記事Yunqiコミュニティのオリジナルコンテンツが許可なく複製することはできません。