6

ピザ配達店向けのシンプルなフォールトトレラントなソフトリアルタイムWebアプリケーションについてはすでに質問しました。

ここに画像の説明を入力してください

私はそこで本当に素晴らしいコメントと回答を得ましたが、それが真のWebサービスであるという点で私は同意しません。Webサービスではなく、顧客からの注文を受け付け、これらの注文の発送を制御し、それらの注文をリアルタイムで配信する車両を制御するのは、よりリアルタイムのシステムです。

さらに、「真の」Webサービスとは異なり、このシステムは多くのユーザーを対象とはしていません。これを使用するのは、ほんの数人のディスパッチャー（電話交換手）と数人の配達ドライバーです（今のところ、直接アクセスを提供する必要はありません）。実際の顧客へのサービスへ。ディスパッチャと配達ドライバーのみが直接アクセスできます）。

したがって、この質問はもう少し一般的です。

このアプリケーションのNoSQLデータストレージオプションを正しく選択するために最初に行う必要があるのは、 CAP定理に従ってとを選択CAすることです。PACP

さて、Building Web Applications with Erlangの本には、「[Mnesia]はSQLデータベースではありませんが、SQLデータベースのようなCAデータベースです。ネットワークパーティションは処理されません」と書かれています。同じ本には、CouchDBデータベースはデータベースであると書かれていPAます。

そのことを念頭に置いて、アプリケーションで最初に行う必要があるのは、CAPに関して「フォールトトレランス」という用語が何を意味するかを決定することだと思います。

私が持っている単純な要件は、アプリケーションを24時間年中無休（R1）で利用できるようにすることです。もう1つは、拡張する必要がないことです。アプリケーションのユーザー数は非常に少なくなります（数千のディスパッチャーを持つことはおそらく不可能です）（R2）。

さて、R1はアプリケーションに一貫性、可用性、パーティション許容度を提供することを要求し、どのような優先順位を付けますか？

次の問題をより適切に処理できるのは、どのタイプのデータストレージオプションですか。

  1. ディスパッチャ（顧客からの電話を受け入れ、CRMを使用する人）が顧客の記録を検索してシステムに注文するための24時間年中無休の可用性を提供します。
  2. 現在進行中の注文とそのステータス（発注、ベーキング、ディスパッチ、配信、配信）をリアルタイムで検索します。
  3. すべての作業車両の位置とそのペイロードをリアルタイムで追跡します。
  4. システムクラッシュまたはネットワーククラッシュ後にシステムの任意の部分を回復して、1、2、および3を提供し続けます。

要約すると、上記のシステムにはどのような種類のデータストレージ（CA、PA、またはCP）が適していますか？どのような種類のデータストレージがR1要件をよりよく満たすでしょうか？

4

2 に答える 2

4
  • 24 /要件の場合、リクエストを毎回成功させたいので（エラー結果のみであっても）、（高）可用性を備えたデータベースを検索しています。
  • パーティションの許容範囲がない場合、netsplitはシステム全体をダウンさせます
  • 一貫性があると便利ですが、3つのうち2つしか持てません。

あなたの最善の策はPAソリューションになります。AmazonDynamoに触発されたソリューションを強くお勧めします。最もよく知られているdynamoの実装は、riakとcouchdbです。Riakでは、読み取りレプリカと書き込みレプリカを調整することにより、PAを他の形式に変更することもできます。

于 2012-08-21T20:59:06.447 に答える
0

まず、CAPの「可用性」と「高可用性」を混同しないでください。彼らはお互いに何の関係もありません。CAPのAは、単に「すべてのDBノードがクエリに応答できる」ことを意味します。高可用性を実現するには、複数のデータセンターにいる必要があり、メンテナンスや拡張などの手順が文書化されている必要があります。CAPの選択に依存するものはありません。

次に、要件について現実的に考えてください。株取引アプリケーションでは、ダウンタイムが1秒ごとに数百万ドルも失われる可能性があるため、100％のアップタイムが必要になる場合があります。一方、あなたのピザのジョイントは、1分ごとに数十ドルも失う可能性があると思います。したがって、それを維持するために何百万ドルも費やすことは意味がありません。実際の費用を計算してみてください。

第三に、常にあなたの選択と主流を評価してください。CA（MySQL）にアクセスして、問題が発生したときにスレーブにすばやくフェイルオーバーすることができます。新しいテクノロジーを構築するためのコスト（およびリスク）について現実的に考えてください。システムがダウンタイムなしで5年間実行されることを本当に期待している場合は、他の誰かがそのデータベースをダウンタイムなしで5年間実行したことの証明を求めてください。

「AP」にアクセスしてリモートユーザー（ドライバーなど）がいる場合は、データを電話に保存してバックグラウンドで（再試行して）送信するアプリを作成する必要があります。もちろん、データベースがCAまたはAPの天気に関係なく、これを行うことができます。

高い稼働時間が必要な場合は、次のいずれかを実行できます。

  • MTBF（平均故障間隔）の増加-冗長電源装置の購入、デュアルイーサネットカードの購入など。

  • MTTR（平均修復時間）を減らす-障害が発生したときに迅速に回復できることを確認してください。（スレーブにフェイルオーバー）

私は人々がMTBFに数万ドルを費やしているのを見てきましたが、バックアップを復元している間は8時間しかダウンしていません。MTBFを攻撃する前に、MTTRが低いことを確認する方が理にかなっています。

于 2013-01-26T15:46:16.357 に答える