私は、高可用性とスケーラブルでなければならないアプリケーションの設計の初期段階にあります。いくつかの理由から、このために結果整合性データモデルを使用したいと思います。これが多くのソリューションで人気のないアーキテクチャの選択である理由を私は知っており、理解していますが、私の場合は重要です。
分散/ドキュメントスタイルのデータベースを扱うときに注意すべき実際のアドバイス、ベストプラクティス、および落とし穴を探しています。特に、eコマース（ショッピングカートスタイル）アプリの周辺では、従来はリレーショナルデータベースと組み合わせるのが簡単でした。
これらのタイプのDBを使用するのは難しいことは理解していますが、GoogleとE-bayはそれらを使用しているので、それほど難しくはありません;-)アドバイスをいただければ幸いです。
分散システム (その「結果整合性」) が必要な場合は、それを構築し、維持し、運用する人が必要です。
「結果整合性」の問題がほとんどない 3 つのクラスの人々がいることがわかりました。
全体として、この人々は求人市場で非常に求められています。たとえば、分散システムの研究者の 75% ほどが、証券取引所などの大規模な自己設計の分散システムを運営する機関に移ります。
Hardoop、SimpleDB、CouchDB などの製品によって全体がいくらかシンプルになりましたが、分散システム テクノロジで何かを構築することは依然として大きな課題です。
一方、RDBMS は非常に優れたエンジニアリングです。それらは十分に理解されており、それらに関する専門知識は求人市場で利用できます。多くの適切なツール、教育の機会があり、多くの高度なスキルを持つ専門家が時間単位でレンタルできます。したがって、RDBMS アプローチをうまく利用できないことをよく考えてください。私は通常、学生にLifejournal アーキテクチャを紹介します。
分散データベースの場合、経験ははるかに少なくなります。これがまさに、これまでほとんどアドバイスを見つけられなかった理由です。
「結果整合性」を使用することに決めた場合、未熟なツールに加えて、主な課題は関係者全員の考え方だと思います。API ユーザー (コーダー) とアプリケーション ユーザー (従業員と顧客) は、矛盾を受け入れる意思と能力がありますか? 特定のクラスのユーザーからそれを隠すことはできますか? 私たちは、コンピューターに一貫性がないという考え方に慣れていません。在庫があるものとないものがあります。「たぶん」は、ユーザーが期待する答えではありません。
また、「最終的」は、アルゴリズム設計者にとって非常に長い時間を意味する可能性があることに注意してください。矛盾をどれくらいの期間受け入れることができますか？
ショッピング カート アプリケーションの場合、真に分散したい場合があります。クライアント ブラウザをデータ ストアとして使用します。チェックアウト時に、カートをサーバー側のバッチ処理システムに送信できます。これは、カタログの場合、読み取り専用の高可用性 (より簡単) が必要であり、カートの送信はトランザクションを必要としない非常に狭いインターフェイスであることを意味します。その後の注文の処理には (ソフト) リアルタイム要件がないため、より簡単になります。
ところで: 前回 E-Bay アーキテクチャを確認したとき、それらは RDBMS で大きなものでしたが、その後変更された可能性があります。（編集：変更されました-コメントを参照）
問題の唯一の解決策は、CAP 定理のどのトレードオフが適切かを判断し、それを実装することです。
mdorseif には素晴らしい点があります。一貫性、可用性、およびパーティショニングをどの程度トレードオフするかについては、多くの構成があります。2 つの主なオプションがあります。
これはおそらく過度の単純化です。実稼働可能なパイプラインはエコシステムです。少なくとも正しい軌道に乗ることができます。
Appnexusは、非常に高い可用性と結果整合性のためにhbaseを使用する広告プラットフォームです。彼らはここでこれについてよく話します。
http://highscaleability.comの記事では、ニューヨーク タイムズが、フォールト トレランスと高可用性のために WAN を介してCassandraと一緒にRabbitMQを実装した方法について概説しています。
MongoDBは、書き込みに関する懸念事項の実装により、一貫性と可用性のバランスを取る上で大きな柔軟性を提供します。彼らは、すべての落とし穴 (パーティショニングを含む) でそれを実装する方法を正確に強調する優れたドキュメントを持っています。ネットワーク全体 (構成サーバー上) で状態を維持するために、 2 フェーズ コミットを実装します。
Google はこのテーマに関する優れた論文を発表しています。Google のphotonプロジェクトは、他のいくつかの手法とともに、その中心にある paxos アルゴリズムを備えた高度にスケーラブルで信頼性の高いシステムを実装しています。また、非常に一貫性があり (エンドツーエンドのレイテンシーは約 10 秒)、フォールト トレラントであり、地域的な障害に耐えます。
分散コンピューティング モデルで構築されたすべてのシステムは、CAP と BASE で構築されています。ここでの主な関心事は、システムが可用性と分断耐性を提供する場合、真の整合性は実現できませんが、結果整合性は実現できるということです。
結果整合性の背後にある考え方は、各ノードが常に要求を処理できるようにすることです。トレードオフとして、データの変更はバックグラウンドで他のノードに伝播されます。これは、いつでもシステムに一貫性がない可能性があることを意味しますが、データは依然として大部分が正確です。
ソース: http://www.techspritz.com/eventual-consistency-and-base-model/
リレーショナル データベースを使用して高可用性とスケーラビリティを実現する方法はよく知られており、その方法に関する膨大な知識が世の中にあります。
Google は、ほとんどのサイト、非常に大量のクエリ、非常に大量のデータ、そして最も重要なことに、ほとんどのユーザーとのサービス レベル アグリーメントに適用されない特別なケースです。Web 検索に正解はありません。より良い答えがあるだけです。平均的なユーザーにとっては、Google で十分です。Google が重要なページを検索リストから逃したとしても、ユーザーとして文句を言うことはできません。
E-Bay はかなり異なるケースです。理論的には低価格と引き換えに粗悪なサービスを受け入れるようにユーザーや顧客を説得してきました。