問題タブ [horizontal-scaling]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
architecture - スケールアウト:分業または冗長性?
これは私がいつも疑問に思っていたものです。水平スケーリングとは、マシンをさらに追加することであると理解しています。しかし、これには2つのアプローチが考えられます。使用したいサーバーが20台(およびデータベース)あるとします。私は出来ます:
- 20台すべてのサーバーをアプリケーションサーバーとして実行します。
- さまざまなサーバーにタスクのさまざまな部分を実行させます。たとえば、あるサーバーセットで要求を処理し、次に別のセットでビジネスロジックを適用し、別のセットでデータベース呼び出しを行うようにします。
1番はより一般的で理解しやすいようですが、2番は「ベストプラクティス」と見なされているようです(ほとんどがn層アーキテクチャであるため)。これら2つのモデルからどのように選択しますか?そして、それぞれのアプローチの長所と短所は何ですか?
language-agnostic - スケーリングについて考え始めるのに適した時期はいつですか?
私はここ数日サイトをデザインしており、サイトを水平方向にスケーリングするさまざまな側面について調査を行っています。計画通りに進めば、数か月後 (数年後?) にサイトのスケールアップとスケールアウトについて心配する必要があることはわかっています。
このことから、スケーラビリティについて考え、スケーラビリティの設計を開始するのに最適な時期はいつか、と考えるようになりました。あまりにも早い段階で開始すると、設計が複雑になりすぎて、実際に構築することが不可能になる可能性があります。また、細部やアーキテクチャなどにとらわれすぎて、何もできなくなる可能性もあります。また、それが機能するようになったが、サイトがうまくいかない場合は、余分な労力のかなりの部分を無駄にしている可能性があります.
一方で、将来的にはかなりの労力を節約できる可能性があります。ゼロから大きくなるように設計すると、後で大きくするのがはるかに簡単になり、書き換えはほとんど行われません。
私が取り組んでいることはわかっています。現在、スケーリングの側で少なくともいくつかの選択を行うことにしましたが、完全にスケーリングするために考え方を完全に変えるつもりはありません。特に、私はデータベースを従来のリレーショナル設計から、以下にリンクされている Reddit サイトで提案されているものと同様の設計に再設計しました。memcache を試してみます。
では、基本的な質問は、スケーリングについて考えたり心配したりするのに適した時期はいつで、そうするときの良い設計やヒントなどは何でしょうか?
興味のある人のために、私が読んでいるいくつかのこと:
http://www.codinghorror.com/blog/2009/06/scaling-up-vs-scaling-out-hidden-costs.html
performance - Hadoop アプリケーションのスケーラビリティを最適化するためのツール?
私は私のチームと一緒に、多くの入力 (1 日のログファイル) を取り、いくつか (現在は 4、将来的にはおそらく 10) の map-reduce ステップ (Hadoop & Java) の後に有用な出力を生成する小さなアプリケーションで作業しています。 .
このアプリの部分的な POC を実行し、4 つの古いデスクトップ (私の Hadoop テスト クラスター) で実行しました。私が気付いたのは、パーティショニングを「間違って」行うと、水平スケーリングの特性が認識できないほど破壊されるということです。1 つのノード (たとえば 20 分) でのテスト実行と 4 つのノードすべてでのテスト実行を比較すると、75% (または少なくとも >70%) の高速化 (約 5または6分)。
map-reduce スケールを水平方向に作成する一般的な原則は、パーティションが可能な限り独立していることを確認することです。私の場合、デフォルトのハッシュパーティショナーを使用しただけなので、各ステップのパーティショニングを「間違って」行ったことがわかりました。これにより、レコードは次の map-reduce ステップで別のパーティションに移動します。
可能な限り多くのレコードを同じパーティションに保持する (つまり、カスタム パーティショナーを構築する) ことができれば、処理速度が向上し、スケーリングが大幅に向上することを期待しています (まだ試していません)。
上記のケースでは、この解決策を手作業で見つけました。私は仕事に行く車の中でこれについて一生懸命考えて、何が悪いのかを推測しました.
皆さんに質問です: - このような問題を検出するために利用できるツールは何ですか? - 従うべきガイドライン/チェックリストはありますか? - 「パーティションをジャンプしたレコードの数」などを測定するにはどうすればよいですか?
提案 (ツール、チュートリアル、本など) は大歓迎です。
real-time - 分散アプリの水平スケーラビリティ、それを達成する方法は?
ここでは Web アプリケーションを無視したいと思います。それらを水平方向にスケーリングする、つまり複数のサーバー インスタンスを一緒に使用するには、マシン上でサーバー ソフトウェアを複製し、リクエストをサーバーに転送する一種のルーターを使用するだけで「十分」です。ビジーでない」サーバーマシン。
しかし、サーバー アプリケーションでユーザーがリアルタイムで共同作業できるとしたらどうでしょうか。
特定のクライアント X の要求に対する応答が、接続が別のマシンによって管理されているクライアント Y のコンテキストに依存する場合、「マシン間」通信が必要になります。
そのような場合に人々が使用した「設計ソリューション」の種類を知りたいです。
たとえば、Facebook の人々は、ソーシャル アプリのチャット機能を有効にするときに、そのような状況に既に遭遇したに違いありません。
アドバイスをよろしくお願いします。
mysql - MySQLの読み取り/書き込み分割で結果整合性の問題を処理する方法
私はMySQLをスケーリングするためのソリューションを検討してきました。Memcachedレイヤーの追加以外によく発生するのは、読み取り/書き込み分割です。すべての書き込みはマスターに送信され、すべての読み取りは負荷分散されたスレーブのセットに送信されます。
このアプローチで明らかに発生する問題の1つは、「結果整合性」です。マスターで書き込みを実行すると、読み取りスレーブへのレプリケーションに一定の時間がかかります。したがって、新しく作成された行を要求すると、そこにない可能性があります。
この問題を処理するための具体的な戦略を知っている人はいますか?「何を書くかを読む」機能の概念的な部分的な解決策について読みました。しかし、概念的に、または具体的にはSpring / Hibernateスタックにあるかどうかにかかわらず、そのようなソリューションを実装する方法を誰かが知っている人はいますか?
javascript - HighCharts: 横棒グラフの対数スケール
棒グラフを作成するためにHighChartsを使用しています。私の値は、最小の 0 から最大の 100k までの範囲です (例)。したがって、グラフの 1 つのバーが非常に小さく、もう 1 つのバーが非常に長くなる場合があります。HighCharts は、「対数スケーリング」の機能を導入しました。その例はここで見ることができます
私のjsコードはこのjsfiddleファイルに書かれています。横軸 (x 軸) を対数で表示したいと考えています。例に示すようにキータイプを挿入しましたが、スクリプトは停止する必要がある無限ループに入ります。
実行の欠陥は何ですか、または HighCharts の対数スケーリングはまだ成熟していませんか?
PS jsfiddle のコメント行が問題を引き起こしています
jsf-2 - JSF 2.0 アプリケーションの水平スケーリング
JavaServer Faces がサーバー側で本質的にステートフルであることを考えると、JSF 2.0 アプリケーションを水平方向にスケーリングするにはどのような方法が推奨されますか?
アプリケーションが複数の JSF サーバーを実行する場合、次のシナリオを想像できます。
- スティッキー セッション: 特定のセッションに一致するすべてのリクエストを同じサーバーに送信します。
- 質問:これを実現するために一般的に使用されているテクノロジーは何ですか?
- 問題:サーバー障害の結果、セッションが失われます...そして、特に新しく開始する場合 (既存のアプリケーションをスケーリングしようとしない場合) は、一般的に壊れやすいアーキテクチャのように見えます。
- 状態 (セッション) レプリケーション: クラスタ内のすべての JSF サーバーで JSF 状態をレプリケートします。
- 質問:これを実現するために一般的に使用されているテクノロジーは何ですか?
- 問題:スケーリングしない。クラスタの合計メモリ = 最小サーバーの合計メモリ
- 外部リソース (たとえば、非常に高速なメモリ内データベースを実行している別のサーバー) にその状態を格納するように (構成を介して) JSF に指示し、アプリケーションの状態が必要なときに JSF サーバーからそのリソースにアクセスしますか?
- 質問:これは可能ですか?
- ステートレスになるように (構成を介して) JSF に指示しますか?
- 質問:これは可能ですか?
[編集]
スティッキー セッションに関する Ravi の提案に応じて更新
git - 水平方向にスケーラブルなGitソリューションを作成する方法
だから私は自分のgitサーバーをうまくセットアップしました。その背景は次のとおりです。
サーバー:Ubuntu Git Serice:Gitolite Webインターフェイス:GitWeb
これで、このサーバーに多数のプロジェクトが追加される予定です。私の10gigインスタンスは簡単に使い果たされます。私の質問は、gitがすべてのファイルをファイルシステムに保存するので、どうすれば水平方向にスケーリングできますか?
sql-server - SQL Azure テーブル/スキーマをスケーリングするためのアーキテクチャ要件
SQL Azure でスキーマやいくつかのテーブルを設定していますが、スケーラビリティ、特に水平方向のスケーラビリティを促進するためにアーキテクチャ的に行う必要があるかどうかを知りたいと考えていました。ID は特定のタイプである必要がありますか? 主キーは特定のタイプですか?
今後のリスク/問題を回避したいと考えています...お知らせください。
ありがとう、
mysql - 2 つのインデックスを持つ mysql テーブルの水平分割
さまざまなアイテムのユーザー評価を格納する mysql テーブルがあります。次のフィールドがあります。
- id (整数、pk)
- ユーザー ID (整数)
- itemId (整数)
- 評価 (フロート)
- タイムスタンプ (整数)
および次のインデックス:
- (userId, rating): 特定のユーザーが評価したすべてのアイテムに関するクエリの場合
- (itemId, rating): 特定のアイテムを評価したすべてのユーザーに関するクエリ用
このテーブルには 1,000 万行を超える行があります。よりスケーラブルにするために、水平分割を実行したいと思います。特に、テーブルを 20 個のテーブルに分割する予定です。
- tbl_rating_by_item_0: itemId が 0 で終わる店舗評価
- tbl_rating_by_item_1: itemId が 1 で終わる店舗の評価
- ……
- tbl_rating_by_item_9: itemId が 9 で終わる店舗評価
と
- tbl_rating_by_user_0: userId が 0 で終わる評価を保存します
- tbl_rating_by_user_1: userId が 1 で終わる評価を保存します
- ……
- tbl_rating_by_user_9: userId が 9 で終わる評価を保存します
itemId でクエリを実行する場合は tbl_rating_by_item_itemId から読み取り、userId でクエリを実行する場合は tbl_rating_by_user_userId から読み取ります。欠点は、評価を挿入または削除するたびに、2 つのテーブルに挿入または削除する必要があることです。
他の解決策はありますか?