問題タブ [scalability]

私たちの postgres サーバーは限界に近づいており、2 番目のデータベース サーバーの追加を検討しています。postgres セットアップに特に適したスケーリング ソリューションはありますか?

多くの同時ユーザーがいる.netポータルに取り組んでいます。そのため、スケーラビリティとパフォーマンスは、設計とアーキテクチャで対処する必要があります。アプリケーションで負荷分散を使用する予定です。

これを念頭に置いて、IIS Web サーバー (aspx、aspx.cs ファイルをホスト) とアプリケーション サーバー (ビジネス ロジックやデータ アクセス レイヤーなどの .net アセンブリをホスト) の間で通信する最良の方法は何でしょうか? .net リモーティングまたは SOAP Web サービスである必要がありますか?または他のアプローチはありますか?

ありがとう。

更新 2009-05-21

単一のネットワーク共有を使用する 2 番目の方法をテストしてきました。これにより、Windows Server 2003 の負荷がかかると、次のような問題が発生します。

http://support.microsoft.com/kb/810886

更新を終了する

次のように動作する ASP.NET Web サイトの提案を受け取りました。

ハードウェア ロード バランサー -> 4 つの IIS6 Web サーバー -> フェールオーバー クラスターを備えた SQL Server DB

これが問題です...

Web ファイル (aspx、html、css、画像) を保存する場所を選択しています。2 つのオプションが提案されています。

1) 4 つの IIS サーバーのそれぞれに Web ファイルの同一のコピーを作成します。

2) Web ファイルの 1 つのコピーを、4 つの Web サーバーからアクセスできるネットワーク共有に配置します。4 つの IIS サーバー上の Web ルートは、単一のネットワーク共有にマップされます。

より良い解決策はどれですか? オプション 2 は、ファイルを 1 つの場所にコピーするだけでよいため、明らかに展開が簡単です。ただし、4 つの Web サーバーがすべて 1 つのファイル セットにアクセスしているため、スケーラビリティの問題があるのではないかと思います。IIS はこれらのファイルをローカルにキャッシュしますか? すべてのクライアント要求でネットワーク共有にヒットしますか? また、ネットワーク共有へのアクセスは、ローカル ハード ドライブ上のファイルを取得するよりも常に遅くなりますか? IIS サーバーを追加すると、ネットワーク共有の負荷が大幅に悪化しますか?

概観を示すために、これは現在 1 か月あたり約 2,000 万ヒットを受け取る Web サイトの場合です。最近のピーク時には、1 秒あたり約 200 ヒットを受信して​​いました。

そのような設定で特別な経験があれば教えてください。入力していただきありがとうございます。

更新 2009-03-05

私の状況を明確にするために、このシステムの「展開」は、典型的な Web アプリケーションよりもはるかに頻繁です。Web サイトは、バック オフィス CMS のフロント エンドです。コンテンツが CMS で公開されるたびに、新しいページ (aspx、html など) がライブ サイトに自動的にプッシュされます。展開は基本的に「オンデマンド」です。理論的には、このプッシュは 1 分以内に数回発生する可能性があります。そのため、一度に 1 つの Web サーバーを展開することが実際的かどうかはわかりません。考え？

誰かがサービスベースのアーキテクチャについて話すときはいつでも、スケーラビリティについて言及することがよくあります。ただし、SOAP や REST などのプロトコルが関係しているため、サービスを使用すると、オーバーヘッドが削減されるどころか、オーバーヘッドが増えるようです。では、Web サービス ベースのアーキテクチャは、たとえば Web アプリケーションのユーザー数がおそらく桁違いに拡大するにつれて、パフォーマンス上の利点を本当に追加するのでしょうか? それとも、スケーラビリティの要件は、コア アプリケーションではなく、単にサービスにオフロードされているのでしょうか?

私は金融業界向けのソリューションに取り組んできました。アプリケーションの主な機能は、大量の入力ファイルを読み込み、それらを消化し、永続ストアの状態を更新し、要求に応じて永続ストアから抽出を生成する機能です。かなり簡単です。

入力ファイルは、多数の繰り返しエントリを含む、業界標準形式の大きな (数百メガバイトを超える) XML メッセージです。永続ストレージはリレーショナル データベースです。エンジンは、J2EE アプリケーション サーバーにデプロイ可能な POJO ベース (バックボーンとしての Spring Framework) Java アプリケーションとして実装されています。

問題は、ソリューションのスケーラビリティとパフォーマンスに関するものです。アプリケーションが XML からのエントリを順番に処理する場合、ソリューションのスケーラビリティはやや劣ります。アプリケーションの複数のインスタンスを 1 つのファイルの処理に関与させる方法はありません。これが、入力 XML ファイルからのエントリの並列処理を導入した理由です。基本的には、ワーカーの個々のエントリの処理をプールからディスパッチするという考え方です。ディスパッチには JMS を使用することにしました。ファイルをロードするコンポーネントはストリームを読み取り、単純に単一のエントリを抽出してディスパッチ キューにフィードします。キューの反対側には多数のコンシューマーが同時にいます。それぞれがキューの 1 つのメッセージを選択してエントリを処理し、すぐに他のエントリを処理できるようになります。これは、Web コンテナー内のサーブレットとよく似ています。このアプローチで特に強力な点は、キューが共有されている限り、リモート サーバーにデプロイされたアプリケーションの個別のインスタンス内にワーカーを配置できることです。残念ながら、すべてのワーカーは永続ストレージを維持する同じデータベースに接続します。データベース サーバーが同時ワーカーからの負荷を処理するのに十分強力でない場合、これがボトルネックになる可能性があります。

このアーキテクチャについてどう思いますか? デザインへの同様のアプリケーションはありましたか？その時、どのようなデザインを選択しましたか?

私は現在約500,000人のユーザーがいるWebアプリケーションを持っており、1時間あたりの平均ページビュー数は約500であり、来年中には最大2,000万人のユーザーにスケールアップする必要があると予想しています。

現在のシステムではその規模を処理できないため、処理できるシステムに移行する必要があります。

私は、サービスベースのアーキテクチャがより堅牢になり、コンポーネントサービスを相互におよびメインアプリケーションから独立して拡張できるようになると考えていました。

しかし、拡張性の低いサービスアーキテクチャを簡単に設計できると警告されています。そのようなシステムの設計経験はほとんどないため、推奨されるリソースを確認する方が、単に「それを試してみるよりも良いでしょう。 「」

では、適切なスケーリングシステムを設計するために推奨されるリソースは何でしょうか。プラットフォームは.Netですが、プラットフォームに関係なく、同じ情報がすべてのサービスベースのアーキテクチャに当てはまると思います。

編集：タグ付けシステムを構築している人々へ。これを読まないでください。それはあなたが探しているものではありません。RDBMS にはすべて独自の最適化方法があることを知らなかったので、単純な多対多スキームを使用するだけで、これを尋ねました。

何百万もの投稿がある投稿システムがあります。各投稿には、無数のタグを関​​連付けることができます。

ユーザーは、メモ、作成日、所有者などを含むタグを作成できます。ユーザーはタグに関するメモを投稿できるため、タグはほとんど投稿そのものです。

各タグの関連付けには所有者と日付があるため、誰がいつタグを追加したかがわかります。

私の質問は、これをどのように実装できますか? タグまたは投稿ごとのタグで投稿をすばやく検索する必要があります。また、ユーザーはフィールドに名前を入力して投稿にタグを追加できます。これは、Google 検索バーのようなもので、タグ名の残りの部分を入力する必要があります。

現時点では 3 つの解決策がありますが、どれが最適か、またはより良い方法があるかどうかはわかりません。

タグの適切な解決策が得られれば簡単になるため、メモのレイアウトは表示していないことに注意してください。

方法 1. リンクされたリスト

post の tagId が tag_assoc のリンクされたリストを指している場合、アプリケーションは flink=0 になるまでリストをトラバースする必要があります

方法 2. 非正規化

tags は、tagId:ownerId のタブ区切り配列を含む単なる VARCHAR または TEXT フィールドです。固定サイズにすることはできません。

方法 3. トキシ

(から: http://www.pui.ch/phred/archives/2005/04/tags-database-schemas.html、ここでも同じこと:タグまたはタグ付けのための推奨 SQL データベース設計)

方法 3 では、tag_assoc のすべての行を反復処理するのにどれくらいの時間がかかるかという疑問が生じます。

方法 1 と 2 は、投稿によってタグを返す場合は高速ですが、タグによる投稿の場合は、別のルックアップ テーブルを作成する必要があります。

私が心配しなければならない最後のことは、名前によるタグ検索の最適化です。私はまだそれを解決していません.

ここに ASCII ダイアグラムを作成しました: http://pastebin.com/f1c4e0e53

JMS 準拠の pub/sub インフラストラクチャを介してメッセージをブロードキャストするソース システムを用意します。パブリッシュされたメッセージの大部分では、サブスクライバーは、メッセージ内のデータで画面を更新する GUI アプリケーションになります。

ただし、サブスクライバーの 1 つは翻訳サービスになります。公開された特定のメッセージについては、翻訳サービスがメッセージを別の形式に変換し、企業の別の部門が所有するセカンダリ メッセージング インフラストラクチャに公開します。

翻訳サービスをスケールアウトして、理想的にはアクティブ-アクティブ フォールト トレランスを提供するにはどうすればよいですか? いくつかのメモ:

• メッセージは、セカンダリ メッセージング インフラストラクチャに順番に公開する必要があります。
• メッセージは、セカンダリ メッセージング インフラストラクチャに一度だけ公開する必要があります。

基本的に、1 人の翻訳サービス加入者だけがメッセージに応答するようにするにはどうすればよいですか? キューベースのシステムに切り替える必要がありますか (ただし、GUI には引き続き pub/sub セマンティクスが必要です)?

翻訳サービスは、Windows Server 2003 でホストされる .Net 3.5 アプリケーションに賭けることに注意してください。F5 Network の BigIP LTM/GTM が利用可能です。

詳細が必要な場合は、質問/コメントしてください。

前もって感謝します。