0

A と B の 2 つのデータベースがあり、Web ページを提供し、データを共有する必要がある場合に内部ネットワークを介して相互に通信します。サーバー A は、サーバー B で大量のデータを含む集中的な計算を必要とするグラフを含む Web ページを生成する必要がある場合があります。両方のサーバーが同等に強力で、ネットワークが高速であると仮定しましょう。これを行う良い方法を見つけようとしています。これまでのアイデア:

  • サーバー B は多くの計算を行い、サーバー A に結果の小さなセットを返すことができます。柔軟性は劣りますが、かなり効率的です。残念ながら、これはやや複雑な取引です。多くのパラメーター、副作用、および結果を持つメソッドと比較します。
  • サーバー B は、単純に独自の生データ サーバーを A に提供し、すべての計算を処理させることができます。より「オープン」で柔軟性がありますが、計算には大量のデータが含まれ、サーバー A はそのすべてをネットワーク経由で取得する必要があるため、効率が低下します。
  • サーバー B は、チャートまたはチャートへのリンクを作成して返すことができます。おそらく最も効率的ですが、柔軟性が低く、サーバー B がサーバー A の Web ページの作成を部分的に担当するという厄介な関係を作成します。ただし、少なくともサーバー A は、複雑なオブジェクトを取得することを心配する必要はなく、それをどう処理するかを知っています。

パフォーマンスと保守可能なカプセル化のバランスをもたらすベスト プラクティスはありますか? それとも単にケースバイケースですか？私は最初のオプションに傾いています。この質問が十分に「回答可能」であり、議論の問題ではないことを願っています. 一般的な問題を特定のシナリオに集中させようとしました。

4

1 に答える 1

0

あなたの質問のベスト プラクティスの部分にはお答えできませんが、パフォーマンスの側面についてはお答えします。あなたが説明したのは、それらの間に実際の技術的な違いのない2つのサーバーであり、おそらく両方を更新するための同等のアクセス権があり、リソースが不足することもありません.

パフォーマンスを正確に計算するには、いくつかの数値が必要です。

A) 1 秒あたりのリクエスト数は? B) 手法 a と b の場合、マシン間でどれだけのトラフィックが流れるか? C) どのくらいのレイテンシーに耐えられますか?

データフローが十分に小さい場合、最初のオプションはパフォーマンスに妥当です。オプション b は、インフラストラクチャにほとんどの負荷を生成します。これがハードウェアの限界に近づいている場合は、今すぐこのオプションを破棄してください。すべての数値が小さい場合、これは実際にはパフォーマンス ベースの決定ではありません。

これをすべてWebページから実行している場合、最初のページの読み込みでサーバーBを参照するImgタグなどを返すことはできませんか? つまり、pageA をリクエストしましたが、HTML ストリームには serverB からのリソースが含まれていますか? これは基本的にオプション C ですが、さまざまなサーバーからリソースを並行してダウンロードできるため、ユーザーのパフォーマンスが向上する可能性があります (複数のサーバーにアクセスすると仮定します)。

設計の観点から、計算が実行される場所がこの質問に関連していることを確認するのに苦労しています。両方のサーバーを制御するため、問題はサーバーbがサーバーaに情報を提供するために必要な「契約」になります。b がフィルタリングされた結果のみを提供できず、基になる生データを提供できない理由はありますか? 別の言い方をすれば、なぜ a が b のデータを処理しなければならないのでしょうか? 両端を制御する場合、ロジックが a または b のどちらにあるかは関係ありません。

両方のサーバーを管理していない場合は、生データを処理して結果を出すためのコスト (構築とサポート) を誰が負担するかが決定の中心になります。

要約/意見。オプション c 可能かつ適切な場合、そうでない場合は b に優先する理由がない場合は a

于 2013-03-16T23:03:50.670 に答える