タグ付けされた質問 「scalability」

最近、noSQL DBMSについてたくさん読みました。CAP定理、ACIDルール、BASEルール、および基本理論を理解しています。しかし、noSQLがRDBMSよりも簡単にスケーラブルである理由に関するリソースが見つかりませんでした（たとえば、多数のDBサーバーを必要とするシステムの場合）。 制約と外部キーを保持するとリソースにコストがかかり、DBMSが配布されると、はるかに複雑になると思います。しかし、これ以上のものがあると思います。 誰かがnoSQL / SQLがスケーラビリティにどのように影響するか説明してもらえますか？

100 sql  nosql  scalability 

Facebookなどのソーシャルネットワークなど、高度にスケーラブルである必要があるWebサイトの場合、Webサイトを設計する最良の方法は何ですか？ サイトが必要なデータを取得するためにクエリするWebサービスが必要ですか？ または サイトはデータベースを直接照会する必要がありますか？（組み込みの言語構造を使用して、テーブルに自動的に入力するなどを行うことができます）。 ウェブサービスは一元化されたデータアクセスを提供し、キャッシングなどの制御がはるかに簡単になるため、より良いデザインだと思いますが、他の人はどう思いますか？

35 design  architecture  websites  scalability 

通知システムマネージャーを作成する必要があります。 私の要件は次のとおりです。 異なるプラットフォームで通知を送信できる必要がありますが、これは完全に異なる場合があります（たとえば、SMSまたはEメールのいずれかを送信できる必要があります）。 通知は、特定のプラットフォームのすべての受信者で同じ場合もありますが、プラットフォームごとの受信者（または複数）ごとの通知である場合もあります。 各通知にはプラットフォーム固有のペイロードを含めることができます（たとえば、MMSにはサウンドまたは画像を含めることができます）。 システムはスケーラブルである必要があり、アプリケーションまたはサーバーをクラッシュさせることなく、非常に大量の通知を送信できる必要があります。 これは2段階のプロセスです。最初に顧客がメッセージを入力し、送信先のプラットフォームを選択します。その後、リアルタイムで処理されるように通知を作成する必要があります。 次に、システムはプラットフォームプロバイダーに通知を送信する必要があります。 今のところ、私はいくつかの結果になりますが、どれだけスケーラブルであるか、またはそれが良いデザインであるかどうかはわかりません。 私は次のオブジェクトを（疑似言語で）しました： 汎用Notificationオブジェクト： class Notification { String $message; Payload $payload; Collection<Recipient> $recipients; } 次のオブジェクトの問題は、受信者が1.000.000だったらどうなりますか？Recipientオブジェクトが非常に小さい場合でも、メモリを大量に消費します。 受信者ごとに1つの通知を作成することもできますが、一部のプラットフォームプロバイダーはバッチで送信する必要があるため、複数の受信者で1つの通知を定義する必要があります。 作成された各通知は、DBやRedisなどの永続ストレージに保存できます。 これを後で集約してスケーラブルであることを確認するのは良いことでしょうか？ 2番目のステップで、この通知を処理する必要があります。 しかし、適切なプラットフォームプロバイダーへの通知をどのように区別できますか？ をMMSNotification拡張するようなオブジェクトを使用する必要がありabstract Notificationますか？または何かのようなNotification.setType('MMS')？ 大量の通知を同時に処理できるようにするには、RabbitMQのようなメッセージングキューシステムが適切なツールであると考えています。それは...ですか？ これにより、大量の通知をキューに入れ、複数のワーカーに通知をポップして処理させることができます。しかし、上記のように受信者をバッチ処理する必要がある場合はどうなりますか？ 次に、プラットフォームプロバイダーを接続して通知を実行するために、それぞれNotificationProcessor追加できるオブジェクトを担当することを想像します。NotificationHandlerNotificationHandler を使用しEventManagerて、プラグイン可能な動作を許可することもできます。 フィードバックやアイデアはありますか？ お時間をいただきありがとうございます。 注：私はPHPでの作業に慣れており、おそらく選択した言語です。 編集 （morphunrealの答えによる） 1秒間に送信するメッセージの数（現在/初期レベルを定義し、再設計する前にシステムが処理する必要がある最大レベルを定義します） システムのハードウェア制約（システムで使用可能なメモリ、CPUなど） ハードウェアはどのように拡張されますか（つまり、サーバーの追加、クラウドコンピューティングなど） どの言語/システムが通知を生成しますか？ 通知はプログラムで作成しますが、UIから作成するのは私自身です。 ジェネレーターはメッセージの受信者を知っていますか（？）、または他の手段で提供されていますか（つまり、特定のアラートタイプのビジネスルールは特定の受信者に送信されます） 特定の受信者、受信者のグループ（たとえば、タグシステムを使用）、またはプラットフォーム全体に対して通知を作成できる必要があります。 CC / BCC /開封確認を追加するためのビジネスルールはありますか はい。これは実際にはプラットフォーム固有であり、readまたはccはすべてのプラットフォームで利用できるわけではないことに注意してください。 …

32 design  architecture  performance  object-oriented-design  scalability 

この講演のQ＆Aセクションで、Douglas Crockford氏は、jQueryは他の一般的なライブラリと同様に拡張できないと述べています。彼はそれによって何を意味し、他のライブラリをよりスケーラブルにするのは何ですか？

32 javascript  jquery  scalability 

Amazon（または他の大規模なeコマースWebアプリケーション）のような大規模なオンラインストアを運営しており、倉庫内の物理的なアイテムの量が限られている会社を想像すると、どのように最適化できますか？単一のボトルネック？もちろん、レプリケーションを備えた多数のデータベースと、負荷を個別に処理している多くのサーバーが必要です。ただし、複数のユーザーが別々のサーバーでサービスを提供しており、両方が同じアイテムをカートに追加しようとする場合、残りのアイテムは1つだけであるため、そのアイテムの数量には「真実の源」が必要です。これは、少なくとも、単一のアイテムの製品情報にアクセスするすべてのユーザーが、同じデータベースにシリアルでクエリを実行する必要があるという意味ではないでしょうか？ 分散コンピューティングを使用して大規模なストアを運営し、インベントリ情報を含む単一のDBに大きなボトルネックを作成しない方法を理解したいと思います。

29 web-applications  scalability  distributed-computing 

リレーショナルデータベースプログラマーとして（ほとんどの場合）、リレーショナルデータベースがどのようにスケールしないか、MongoDBなどのNoSQLソリューションがどのようにスケールするかについての記事を読みました。これまでに開発したデータベースのほとんどは小規模から中規模であったため、インデックス作成、クエリの最適化、またはスキーマの再設計によって解決されなかった問題は一度もありませんでした。 MySQLはどのようなサイズに苦しんでいると予想されますか。何行ですか？ （これはアプリケーションと保存されるデータの種類に依存することを知っています。基本的には遺伝学データベースだったので、3つまたは4つのルックアップテーブルを持つ1つのメインテーブルがあります。メインテーブルには、他のもの、染色体参照、および位置座標。おそらく、そこに保存されているものを確認するために、染色体上の2つのポーション間の多くのエントリを照会されます。

24 database  sql  nosql  scalability 

FlaskやDjangoなどの多くのWebフレームワークは、デフォルトのデータベースとしてSQLiteを使用します。 SQLiteはPythonに含まれており、管理オーバーヘッドが非常に低いため、魅力的です。 ただし、トラフィックの多い公共の本番サイトのほとんどは、mySQL、Oracle、またはpostgresqlなどのより重いデータベースを使用しています。 質問： 仮定： サイトのトラフィックは中程度であり、データベースへの同時読み取り/書き込みアクセスが発生します SQLite書き込みロックでSQLAlchemyを使用します（ただし、このコメントは少し緊張しますが） データベースにはおそらく60,000レコードが含まれます データ構造は、より重いデータベースにある高度な機能を必要としません 中程度のトラフィックの社内企業ツールとして機能するWebサイトで、SQLiteの同時実行に対して説得力のある事例はありますか？もしそうなら、どのような条件がSQLiteに並行性の問題を引き起こしますか？ 一般的な恐怖/根拠のない指差しではなく、既知の特定の根本原因を探しています。

23 sql  frameworks  scalability  web-framework  sqlite 

できれば多くのユーザーがいるシステムを作成しました。私たちのデータベースは、需要の高いユーザー名を使用するゴミのユーザーでいっぱいになるのではないか、あるいは単に登録して二度と戻ってこないのではないかと心配しています。 私はこれが一般的であることを知っています、3つのGoogleアカウントを持っているので自分でこれを行いますが、1つだけを使用します。

22 scalability  users 

最近、スケーラブルなエンタープライズコンピューターアーキテクチャのニュアンスを学び始めました。中心的なコンポーネントの1つはメッセージングキューです。プログラミングパラダイムからできる限り多くを学ぶために、独自のバージョンのメッセージングキューサービスを実装しようとしています。 これまでのところ、私の最初の設計はスレッドソケットリスナーで実行されますが、2つの別々の処理ノードによって同じメッセージが2回ダウンロードされるのを防ぐために、読み取りが開始されるとメッセージキューインデックスレジスタがロックされ、レジスタがロック解除されるとロックが解除されます更新しました。そのため、これはスレッド化の必要性をなくし、メッセージングキューサービスが実行されているサーバーの処理速度に基づいてスケーラブルなシステムのサイズに上限があることを意味します。 これを回避する方法は、複数のサーバーでメッセージキューサービスを実行することですが、これにより、同じメッセージが2回ダウンロードされる可能性が高くなります。このような問題の発生を防ぐ唯一の方法は、（サーバー、または単一サーバー上のスレッドでさえ、情報を同期し、そのような再発行を検出した後）処理ノードに停止するように命令する失効コールバックを含めることです現在のジョブ、および次のメッセージのためにメッセージキューを再クエリしますが、送信されるトラフィックのほとんどが同期および失効コールバックであり、ボトルネックを引き起こし、情報の処理を遅らせる天井があります多くの処理ノードがnull操作を実行し、時間を浪費します。 この問題を回避するために考えることができる最後の方法は、各メッセージキューサーバー（および各サーバーの各スレッド）がキュー内のどこを探しているかに関して特定のオフセットを持たせることですが、それは特に処理を特定の順序で実行する必要がある場合は、アプリケーションのタイプ。 ということで、既存のエンタープライズグレードのメッセージキューサービスがこれらの問題をどのように回避するかを示すことができるメッセージキューアーキテクチャの設計はありますか？

22 design  scalability  message-queue 

BDD（Behaviour Driven Development）について読んだすべてのWebサイトで、要件を定義することがいかに明白で簡単かを示す非常にシンプルで素晴らしい例が見つかります。しかし、このプロセスを（電卓の例ではなく）大きな製品に実装しようとすると、物事がかなり複雑で読みにくくなる（または得られる）ことがわかりました。特に後でリクエストを変更することは、このための統合テストを修正するための多くの作業を意味します。 だから、BDDは本当に価値があるのだろうか？他の手法では解決できない問題を解決できますか？

22 development-process  scalability  bdd  integration-tests 

私はC10Kの問題について読んでいますが、特に注目すべきは非同期サーバーI / Oを指す部分です。http://www.kegel.com/c10k.html#aio これは、スレッドがI / O割り込み（イベント）に依存しながら、スレッドがユーザーの要求を処理できるようにすることで、Node.jsがサーバー上で行うことをほぼ要約していると思います。フルCPUジョブ。スレッドは、他のこと（非ブロッキング）を利用して、ジョブが完了したとき（たとえば、ファイルが見つかった、またはビデオが圧縮されたとき）に通知を受けることができます。 これは、その後、スレッドがソケット、つまりサーバー上のユーザーにとってより「利用可能」であることを意味します。 それから私はこれを見つけました：http : //teddziuba.com/2011/10/straight-talk-on-event-loops.html ライターは、イベント駆動型フレームワーク（割り込みスレッド）がスレッドを解放するかもしれないが、実際にはCPUがしなければならない作業量を減らさないと主張しています。ここでの理由は、たとえば、ユーザーがアップロードしたビデオを圧縮するように要求した場合、CPUは実際にこのジョブを実行する必要があり、それを実行中にブロックすることです（簡単にするために、ここでは並列性を忘れます-もっとよく知って！）。 私は簡単なコーダーであり、サーバー管理者などではありません。知りたいのは、Node.jsが「クラウドコンピューティング」の神からの贈り物なのか、それとも熱気であり、実際にスケーラビリティを改善して企業の時間やお金を節約できないのか、ということです。 どうもありがとう。

21 scalability  node.js  server 

特定のアプリケーションのスケーラビリティについて、いくつかの技術的なプレゼンテーションを行うよう依頼されました。アプリケーションは、Java、Spring MVC、Hibernateを使用して開発されています。アプリケーションのソースコードにアクセスできます。 （ソースを使用して）ソフトウェアスケーラビリティを測定するにはどうすればよいですか？また、ソフトウェアスケーラビリティを測定する際に注意する必要があるメトリックは何ですか？

21 scalability  metrics 

あなたが会社で働いていて、あなたがしていることは彼らのためにソフトウェアを開発しているとしましょう。あなたは全体像を知らないか、わずかかもしれません。あなたが持っているのは、問題追跡システムを介して割り当てられたタスクです。タスクが与えられ、タスクがそれらを説明するように動作させ、送り返します。2つの整数を追加するのと同じように： function add(a,b){return a + b;} しかし、後でプロジェクトが進むにつれて、addより複雑になるにつれて、パラメーターを追加して値を返す関数だけでなく、何らかのアーキテクチャが必要になっていることに気付くでしょう。しかし、あなたはそれを知りませんでした。そもそも、彼らが必要とするのはその単純なことだけでしたadd。addがそれほど複雑になるとは思わなかった。 プロジェクトはより多くの機能を備えて進行しますが、そもそもこれは期待していなかった機能です。そして最後には、既存のコードを壊したり書き換えたりすることを避けるために、ハッキングを積み重ね続け、関数のレイヤーを重ねます。 これらの状況にどのように対処しますか？「最低開発者」としての技術的負債とどのように戦いますか？ 明確化： あなたは「実装者」であり、階層の最下位です。 問題は見えますが、問題については発言権がありません。 技術的な負債を定量化したり、ツールを探したりするわけではありません。 3番目の「重複」について リファクタリングとリライト-あなたはあなたのタスクにロックされています。あなたは余分に行うために支払われていません。 アーキテクチャの概要-システム全体は知っていますが、アーキテクチャについてはわかりません。 コードフリーズ-電話ではありません。あなたは管理者ではありません。 モジュール化-アーキテクチャのアイデアはありません。モジュールは要件の変化に応じて変化します。 自動テスト-なし。

20 architecture  software  scalability  maintainability  technical-debt 

私がここ数年取り組んでいる大きなプロジェクトは、ファームウェアの心臓部である高度なデバイスの制御（およびすべて）アプリケーションです。 デバイスは非常に高度であり、メモリから言うことができるよりも多くの異なる機能を備えており、それらの98％はこの1つの巨大な実行可能ファイルによって処理されます。一方では、プログラムは非常に保守性が高く、内部で適切にモジュール化され、適切に文書化されており、ディレクトリやファイルなどによって機能が合理的に分離されています。 しかし、最終的には、リモートデータベース通信、タッチスクリーン処理、多数のさまざまな通信プロトコル、測定、いくつかの制御アルゴリズム、ビデオキャプチャ、イースターの日の出時刻と日付（真剣に、非常に深刻な目的のために必要です！）...一般に、非常に薄く関連しているもの、多くの場合、いくつかの遠いモジュール間で少しずつ流れるいくつかのデータを通してのみ関連するもの。 ソケットを介して、より具体的な目的で、必要に応じてロード/アンロードするなど、互いに通信する複数の個別の実行可能ファイルとして実行できます。この方法で作成された理由は特にありません。 片手で機能し、大丈夫です。プロジェクトは、複数のバイナリのビルドを維持することなく、よりシンプルです。内部構造も簡単です。ソケットや共有メモリを介して通信するのではなく、メソッドを呼び出すか、変数を読み取るだけです。 しかし、一方で、このことの大きさ、規模は私をゾッとさせるだけで、タイタニックを操縦しているように感じます。私は常にモジュール化することを教えられましたが、すべてを1つの巨大なファイルにまとめるのは間違っているように感じます。私が知っている問題の1つは、1つの（わずかな）モジュールがすべてクラッシュするという重大なクラッシュです。それ以外の場合、内部の分離と防御的なプログラミングにより、何らかの理由で内部モジュールの半分が正常に機能しなくなった場合でも、これがほとんど正しく実行されることが保証されます。 他にどんな危険を見落としましたか？なぜこれが私を怖がらせるのですか？これは単なる不合理な未知への恐怖ですか？このように深刻な大きなプロジェクトを作成することは、受け入れられている慣行ですか？不安を和らげるか、バージョン2.0を複数の小さなバイナリにリファクタリングする正当な理由を教えてください。

20 architecture  project  scalability  risk-assesment 

過去には、さまざまな環境で働いてきました。デスクトップアプリ、ゲーム、埋め込みコンテンツ、Webサービス、コマンドラインジョブ、Webサイト、データベースレポートなど。これらの環境はすべて同じ特徴を共有しました。複雑さやサイズに関係なく、テストするマシンまたは開発環境でアプリケーションのサブセットまたはスライスを常に保持できました。 今日はしません。今日私は、スケーラビリティに主眼を置いている環境にいることに気づきました。環境を再現することは法外に費用がかかります。環境の一部を取りますが、もっともらしい（一部のピースはシミュレートする必要があるか、実行しないようにシングルインスタンスモードで使用する必要があります）が、同時実行性とロードを不明瞭にするため、目的を無効にします実際のシステムが遭遇します。小さな「テスト」システムにも欠陥があります。2つのノードがある場合と64のノードがある場合は、動作が異なります。 最適化への私の通常のアプローチ（測定、何かを試す、正しさを検証する、違いを測定する、繰り返す）は、重要な問題の部分（同時実行性の堅牢性とパフォーマンスの下で効果的にステップ2と3を実行できないため、ここでは実際に機能しません負荷）。ただし、このシナリオはユニークではないようです。この種の環境でこの種のタスクを行うための一般的なアプローチは何ですか？ 関連する質問がいくつかあります。 この質問は、ハードウェア（スペクトルアナライザーなど）が利用できないことに関するものであり、（比較的）簡単にエミュレートできます。 この質問は、実稼働環境にのみ存在するバグを追跡することに関するものです。これは役に立ちますが、異なる種類のアクティビティです。

17 testing  optimization  scalability