2009-06-01 4 views
15

フレームワーク(.net。ruby on rail、django、springなど)について読むと、私はそう見ています。フレームワークが「規模の拡大」とはどういう意味ですか?

誰かがフレームワークが「スケールが良い」と言っているとはどういう意味ですか、フレームワークが「スケールが良くない」とはどういう意味ですか?

ありがとうございます。

+9

スケールは、比較のために測定するための昔ながらのデバイスです。彼らは通常、バランスによって構築されます...残念ながら、これは、多くの周りを動揺してジャンプするものを測定することを困難にします - したがって、フレームワークはまだ "規模を拡大する"と考えられ、一方毎日のガロンのコーヒースケールにあまりにも多くのコークスを混入させてしまった。 – Shog9

+0

ハハハ、素晴らしい比較、Shog9。 –

+6

「フレームワークXのスケールがうまくいかない」とは、しばしば「フレームワークXに対しては不合理な憎しみがある」と言っています。一方、「フレームワークYはうまくスケールする」とは、「私はフレームワークYが好きですが、光沢のあるボタンを作成しやすいので、好きなことを認めたくありません」という行に沿った何かを意味します。 – Pesto

答えて

15

リソース使用量(メモリ、時間、ディスク容量、ネットワーク帯域幅)を同時ユーザーに対してプロットすると、アプリケーションがさまざまなスケールファクタでどのように動作するかを示す関数が得られます。

小規模 - 少数のユーザー - いくつかのリソースを使用します。

大規模 - 多数のユーザー - 多数のリソースを使用します。

重要な質問は、「線形にどれだけ近似するか」です。線形にスケーリングすると、2,000人の同時ユーザーには1,000人のユーザーに2倍、500人に4倍のコストがかかります。これはツール/フレームワーク/言語/プラットフォーム/ OSです。予測可能で予測は線形です。

直線的に拡大しないと、4,000人のユーザーにサービスを提供するユーザー数は2,000ユーザーに比べて1,000倍になり、500ユーザーに100倍のコストがかかります。これはうまく拡張できませんでした。使用状況が上がったときに何かが間違っていた。予測可能ではなく、線形ではありません。

+1

また、線形性も必ずしも良好ではありません。理想的には、ユーザーの数がクリティカルボリュームに達すると、それを平準化または平準化することが望ましいでしょう。しかし、これはいつも可能なわけではなく、おそらく多くの時間では不可能かもしれません。ただ理想的です。 –

+0

私はこの答えは少し一般的だと言います。線形スケーリングまたはスケーリングについて説明します。実際には、単一のステーションのパラメータであるメモリ、時間、ディスクおよび帯域幅に対して。通常、フレームワークは分散環境で使用され、これらのパラメータは評価するのが明らかでない場合があります。 1,000人のユーザーと10000ユーザーのスケーリングについてコメントできますか? – mariotti

+0

管理のスケーラビリティも重要な考慮事項です。 5台のサーバー設定で1台のDBAが必要で、10台のサーバーで2台のDBAが必要な場合は、DBAを十分に雇用して訓練することができない場合があります。フレームワークを維持する人間の要素は非常に重要です。 –

7

これは、特定のフレームワークが、より多くのユーザーがそれを要求する増加した要求を満たす(またはしない)ことを意味します。 VBScriptで書かれたアプリケーションをお持ちの場合、たとえばFacebookの40,000,000人のユーザーを処理するうまい仕事をしていないかもしれません。

This blog postは、Twitterが1年ほど前に経験したスケーラビリティの痛みについて説明しています。それは、あなたの質問への答えにいくつかの洞察を提供することができます。

言語やフレームワークを批判するためにスケーラビリティが欠けていることがありますので、注意してください。実際の測定基準を示す研究に固執する。これは前の段落の私のVBScriptの例にも当てはまります。

+0

2009年にfacebookが40万人のユーザーを抱えていたと推測して、彼らがうまく拡張したプラットフォームを持っていなかったら、今1000mのユーザーを処理できなくなるでしょう。 – Ozzy

+0

それは狂気ではありませんか? 3年間の違いは?ナイスキャッチ。 –

3

フレームワークまたはアプリケーションのスケーラビリティが高い場合は、より大きな負荷を処理できることを意味します。サイトの訪問者数が増え、1日のヒット数が増えるにつれ、サイトの規模が大きくなると、負荷が小さくなるのと同じように大きな負荷が処理されます。 1時間に1ヒットしたときと同じように、1時間に200,000ヒットを受け取ると、うまくスケーリングされたフレームワークが同じように動作します。ヒットしただけでなく、複数のサーバーに展開されている可能性もあります。これらの増加する要求にもうまく対応できるフレームワークが得られます。

たとえば、twitterは昨年一晩ほとんど爆発しました。これはRuby On Railsを使って開発されたもので、Railsがうまくスケーリングできるかどうかについての議論の中で注目されています。

+0

どうしたの?彼らはRailsを続けましたか? – johnny

+0

彼らは部分的にはRailsに、一部はScalaに切り替えています。 http://www.theregister.co.uk/2009/04/01/twitter_on_scala/ –

2

私の心の中で、それにはいくつかの要素があります。 1つ目は、明らかに1つのパフォーマンスのスケーリングです。あなたのフレームワークは、高容量、ハイスループットのシステムを構築するために使用できますか、それとも小さなアプリケーションを構築するために使用できますか?それはハードウェア(例えば並列ライブラリ)上で垂直にスケーリングされ、水平に拡大する(例えば、ウェブファーム)。

第2は、大規模なチームや企業に拡大することができます。つまり、大きなコードベースではうまくいくのですか?大規模な開発チーム?それは良いツールサポートを持っていますか?展開が簡単ですか?数十、数百、または数千のユーザーに展開できますか?すべての道のりは、このスキルを持つ人々を雇うことは簡単です。このフレームワークで作業する20人または50人の開発チームをまとめようと考えてください。それは簡単か不可能か?

0

IMHOは、フレームワークが「うまくスケールする」と言うのは通常、大衆連鎖の誰かがそれを使用して大量のボリュームを処理できるということです。

通常、スケーラビリティは、並列化されたときのアルゴリズムの実行方法を記述するために使用されます。 1:1のスピードアップを持つアルゴリズムはまれな獣ですが、2倍のハードウェア/ CPU、3倍のハードウェア/ CPUなどで2倍の性能を発揮します。

私の経験では、十分な専門知識があれば、スケールアップすることができます。

フレームワークが使いやすくなるほど、専門知識が不十分な開発者がスケーラビリティの問題に遭遇する可能性が高くなります。

0

これは、尊敬している企業の中には、何か真剣なことをしていて、何の問題もないことを意味します。

0

スケーリングとは、より多くのハードウェアを使用することによって、より多くの需要を満たすことがどれほど容易かを意味します。

例:ウェブサイトの言語は1日1000回です。あなたはいくつかの著名な雑誌に登場し、あなたのユーザー数は増えます。突然、あなたは1日に1000000回訪問します。それは1000回もあります。成長したリソースの必要性を満たすために1000台以上のサーバーを使用することができれば、Webサイトの規模はよくなります。一方、2000台のサーバーを追加しても、ユーザーが接続できない場合、データベースは1日あたり1000件の要求しか処理できないため、Webサイトの拡張性が損なわれます。

関連する問題