問題タブ [scalability]

擬似コードを使用してハンドロールされたPOCOキュークラスを使用しています

WCFの場合、リクエストキューイングはスケーラブルなアプローチですか？

私は PHP で Web アプリケーションの開発を始めています。このアプリケーションが信じられないほどの人気を得て、有名になり、金持ちになることを願っています。:-)

その時が来たら、API のデータを SimpleXML で XML として解析するか、json_decode を使用するかの私の決定は、アプリのスケーラビリティーに違いをもたらす可能性があります。

これらのアプローチのどれがサーバーにとってより効率的か知っている人はいますか?

更新:基本的なテストを実行して、どちらの方法がよりパフォーマンスが高いかを確認しました。json_decodeの実行は よりわずかに速いようですsimplexml_load_string。これは、並行プロセスのスケーラビリティなどをテストしていないため、決定的なものではありません。私の結論は、XPath 式がサポートされているため、当面は SimpleXML を使用するということです。

結果：

同僚との最近の会話では、この問題についてさまざまな見解が生まれました。SOのメンバーはどうですか？

スケーラビリティの概念でさえ、非常に多くの異なる方法や文脈で捉えることができますが、これが話題になったときの議論の一部でした. スケーラビリティが実際に意味するものについて、誰もが異なる見方をしているように見えました。ここでもさまざまなテイクが見られることに興味があります。実際、私はその概念のためだけに質問を投稿しました。

linq のスケーラビリティについて同様の質問を投稿しました。最近の会話では、スケーラビリティが実際に何を意味するのかについて非常に多くの異なる見解があったため、私もこの質問をするきっかけになりました. あなたにとってスケーラビリティとは何ですか?

完全にステートレスにできない大規模な Web サイトは、どのようにして Web 層で極端なスケーラビリティを実現するのでしょうか?

eBay や Amazon のようなサイトは、ショッピング カートなどを持っているため、完全にステートレスにすることはできません。ショッピング カート内のすべてのアイテムを URL にエンコードすることも、すべてのアイテムを Cookie にエンコードして接続ごとに送信することもできません。そのため、Amazon は、送信される Cookie にセッション ID を格納するだけです。したがって、eBay と Amazon の Web 層のスケーラビリティは、すべてを安らかに URL にエンコードできる Google 検索エンジンのスケーラビリティよりもはるかに困難であることを理解しています。

一方、eBay と Amazon の両方が、非常に大規模にスケーリングしました。噂によると、eBay には約 15000 の J2EE アプリケーション サーバーが存在します。

これらのサイトは、極端なスケーラビリティとステートフルネスの両方をどのように処理しているのでしょうか? サイトはステートフルであるため、単純な DNS バランシングを行うことは現実的ではありません。したがって、これらの企業は、そのサイトの単一の IP アドレスの背後にある唯一のデバイスである、BigIP、Netscaler などのようなハードウェア ベースのロード バランサーを持っていると想定できます。このロード バランサーは、SSL を復号化し (エンコードされている場合)、Cookie を検査し、その Cookie のセッション ID に応じて、どのアプリケーション サーバーがその顧客のセッションを保持しているかを判断します。

しかし、単一のロードバランサーでは何千ものアプリケーション サーバーの負荷を処理できないため、これではうまくいかないのでしょうか? これらのハードウェア ロード バランサーでさえ、そのようなレベルには拡張できないと思います。

また、負荷分散はユーザーに対して透過的に行われます。つまり、ユーザーは別のアドレスに転送されることはありませんが、すべてのユーザーがまとめて www.amazon.com にずっと滞在します。

だから私の質問は次のとおりです。Web層の透過的なシャーディングのようなものを達成できる特別なトリックはありますか(一般的に行われているデータベース層ではありません)? Cookie が検査されない限り、どのアプリケーション サーバーがこのセッションを保持しているかを知る方法はありません。

編集：サイトをスパイダーしてブックマークする必要がある場合は、透明性だけが必要であることに気付きました。たとえば、サイトが飛行機や電車のチケット予約システムのような単なる Web アプリである場合、ユーザーを異なる URL の背後にある Web サーバーの特定のクラスター (a17.ticketreservation.com など) にリダイレクトするだけで問題はありません。この特定のケースでは、それぞれが独自のロード バランサーの背後にあるアプリケーション サーバーの複数のクラスターを使用するだけで実現可能です。興味深いことに、この種の概念を使用しているサイトは見つかりませんでした。 編集:この概念がhighscalability.comで議論されているのを見つけました。この議論では、Lei Zhu の記事が参照されています。「Web 2.0 アプリケーションのクライアント側負荷分散」 . Lei Zhu は、クロス スクリプティングを使用して、このクライアント側の負荷分散を透過的に行います。

ブックマークや xss などの欠点があるとしても、これは特定の特別な状況、つまりスパイダーやブックマークを必要としないほとんどコンテンツのない Web アプリケーション (チケット予約など) には非常に良いアイデアのように思えます。システムまたはそのようなもの)。その場合、ロード バランシングを透過的に行う必要はありません。

www.ticketreservation.com から a17.ticketreservation.com へのリダイレクトなど、メイン サイトからサーバーへの単純なリダイレクトが存在する可能性があります。そこから、ユーザーはサーバー a17 に留まります。a17 はサーバーではなく、クラスター自体であり、冗長性を実現できます。

最初のリダイレクト サーバー自体が、ロード バランサーの背後にあるクラスターである可能性があります。このようにして、www の背後にあるプライマリ ロード バランサーは各セッションの開始時に 1 回だけヒットするため、非常に高いスケーラビリティを実現できます。

もちろん、別の URL へのリダイレクトは非常に厄介に見えますが、単なる Web アプリケーション (スパイダー、ディープ リンク、またはディープ ブックマークの必要がない) では、これはユーザーにとって視覚的な問題に過ぎないのでしょうか?

リダイレクト クラスタは、アプリケーション クラスタの負荷をポーリングし、それに応じてリダイレクトを適応させることができるため、単なる負荷分散ではなく、バランスを取ることができます。

データベースに最大 32 GB のデータを入れる必要があるアプリを作成しています。読み取りには範囲クエリがあるため (0 < time < 1hr など)、B ツリー インデックスを使用しています。

最初 (データベース サイズ = 0GB) では、1 ミリ秒あたり 60 回と 70 回の書き込みが発生します。5GB と言った後、私がテストした 3 つのデータベース (H2、berkeley DB、Sybase SQL Anywhere) は、1 ミリ秒あたりの書き込みが 5 回未満になるまで、本当に遅くなりました。

質問:

• これは典型的なものですか？
• インデックス作成を削除しても、このスケーラビリティの問題は引き続き発生しますか?
• この問題の原因は何ですか?

ノート：

各レコードはいくつかの int で構成されます

私は大学の何人かの友人と議論してきましたが、どのフレームワークが Web アプリケーションのスケーラビリティーに優れているか (しかも非常に高速) に到達できません。

1 つは jsp の呼び出し、もう 1 つは ruby​​ の呼び出し、もう 1 つは php の呼び出しなどです。スケーラビリティの向上の可能性について、明確にしていただけますか?

Tks、検索したものと重複していないことを願っていますが、このような以前の質問は見つかりませんでした。

編集：これについて比較することができれば、それは良いことです:)

目標は、バックエンド データベースのアップタイムを保証するために、一部の Web サービスに対して特定の SLA (サービス レベル アグリーメント) を保証する方法を確立することです。理想的には、これはサービスに特定のコードを使用せずに、基盤となるインフラストラクチャ/パイプラインを制御することによって実現する必要があります。

私はhttp://highscalability.com/の大ファンです。現在の開発では、サーバー側、特にデータベース層をスケールアウトできるようにするためのルートとして、機能境界に沿ってアプリケーションを分解することを検討しています。これには、アプリケーションのさまざまな機能コンポーネント (顧客が使用できるいくつかの個別のモジュールがあります) をサーバー上の独自の独立したアプリケーションとして実装することが含まれます。サーバーに接続するクライアントは、さまざまなデータのために接続する必要がある個別のサービスを認識しています統一されたビューがユーザーに表示されます。問題は、異なるコンポーネント内のデータ間にリンクがある場合に発生します。つまり、1 つのコンポーネントがすべてのユーザー データを保持しているが、別のコンポーネントがデータの一部の所有者としてユーザーを参照する必要がある場合です。私' m 現在、リンクの各サイドの主キー情報を保持することでこれを行っています (それらがすべて単一のデータベースに存在する場合と同様)。ただし、このリンク テーブルは両方のコンポーネントに存在して、どちらの方向でもルックアップを実行できるようにする必要があります。 、つまり、「特定のユーザーが所有するものを取得する」と「この特定のものの所有者を取得する」は、それぞれ異なるコンポーネントを使用します。これに代わる方法は、リンク データをコンポーネントの 1 つだけに格納することですが、その場合、逆引き参照には 1 回ではなく 2 回の呼び出しが必要になります。

私の質問はこれです.これらのリンクテーブルの重複は、私が避けるべきある種のコードの臭いですか、それとも、このような機能ラインに沿ってアプリを分割するときの方法ですか?

短縮版

ユーザーをシャードに分割する場合、「ユーザー検索」を提供するにはどうすればよいですか? 明らかに、すべての検索がすべてのシャードにヒットすることは望んでいません。

ロングバージョン

シャードとは、複数のデータベースがあり、それぞれに全データの一部が含まれていることを意味します。(単純な) 例として、データベース UserA、UserB などには、名前が「A」、「B」などで始まるユーザーが含まれている可能性があります。データベース。戻ってきたユーザーがサインインすると、そのユーザーの名前をもう一度調べて、そのユーザーの情報を取得する正しいデータベースを判断します。

シャーディングと読み取りレプリケーションの利点は、読み取りレプリケーションが書き込みをスケーリングしないことです。マスターに送信されるすべての書き込みは、各スレーブに送信する必要があります。ある意味では、読み取り負荷が分散されていても、それらはすべて同じ書き込み負荷を担います。

一方、シャードは互いの書き込みを気にしません。Brian が UserB シャードにサインアップした場合、UserA シャードはそれについて知る必要はありません。Brian が Alex にメッセージを送信した場合、その事実を UserA シャードと UserB シャードの両方に記録できます。このようにして、Alex または Brian のいずれかがログインすると、すべてのシャードにクエリを実行することなく、送受信したすべてのメッセージを自分のシャードから取得できます。

ここまでは順調ですね。検索はどうですか？この例では、Brian が「Alex」を検索すると、UserA を確認できます。しかし、彼が姓の「Smith」で Alex を検索するとどうなるでしょうか。すべてのシャードにスミスがいます。ここから、次の 2 つのオプションが表示されます。

1. アプリケーションで各シャードで Smiths を検索します。これは、ゆっくり (各シャードを連続してクエリする) または迅速に (各シャードを並行してクエリする) 行うことができますが、いずれにしても、すべてのシャードがすべての検索に関与する必要があります。読み取りレプリケーションが書き込みをスケーリングしないのと同じように、検索がすべてのシャードにヒットしても、検索はスケーリングされません。検索ボリュームが各シャードを圧倒するほど高くなる時期に達する可能性があり、シャードを追加しても検索ボリュームは同じになるため役に立ちません。
2. それ自体がシャーディングに耐えられるある種のインデックス作成。たとえば、検索したい一定数のフィールドがあるとします: 名と姓です。UserA、UserB などに加えて、IndexA、IndexB などもあります。新しいユーザーが登録されると、そのユーザーを見つけてもらいたい各インデックスに追加します。そこで私は Alex Smith を IndexA と IndexS の両方に入れました。彼は "Alex" または "Smith" のいずれかで見つけることができますが、部分文字列はありません。この方法では、各シャードに対してクエリを実行する必要がないため、検索がスケーラブルになる可能性があります。

では、検索はスケーリングできますか? もしそうなら、この索引付けアプローチは正しいものですか? 他にある？