問題タブ [scalability]

WS タイムアウトの上限設計制限を定義する記事/本はありますか? サーバーでタイムアウトしますか、それともクライアント固有のタイムアウトを推奨しますか?

「60 秒以上かかる可能性がある WS を設計しない、非同期トークン パターンを使用する」などの一般的なベスト プラクティスはありますか?

あなたが何をしているのか、またはあなたの意見も知りたいです。

スケーラビリティの問題が発生しているデータベース スキーマを使用しています。スキーマ内のテーブルの 1 つが約 1,000 万行に増えました。私は、このスキーマをより大きなデータセット (たとえば、10 億行から 1,000 億行) にスケーリングできるように、シャーディングとパーティション分割のオプションを検討しています。私たちのアプリケーションは、Oracle、MS SQL Server、MySQL を含むがこれらに限定されないいくつかのデータベース製品にも展開できる必要があります。

これは一般的に大きな問題であり、利用可能なオプションについて調べたいと思います。データベースのシャーディングとパーティショニングの戦略について、どのようなリソース (書籍、ホワイトペーパー、Web サイト) がありますか?

新しい ASP.NET アプリケーションを開始するとき、将来のある時点で拡張する必要があることを認識している場合、全体的なリファクタリングなしで将来の拡張性を可能にする最も重要な設計上の決定は何ですか?

あなたの職場で上司がこう言ったとしましょう。

あちらのシステムは、すべての制度的知識を失いましたが、現在はかなりうまく機能しているように見えますが、データを2倍にして生き残ることができますか?

あなたはシステムにまったく慣れていません。

これは SQL Server 2000 (主にデータベース アプリ) にあります。

テスト環境はありません。

ベンチマークを実行する必要がある場合は、週末にハイジャックできる可能性があります。

その余分な負荷を引き受けることができると自分自身を納得させ、上司に納得させるために行う 3 つのことは何ですか。同じハードウェアでそれができない場合は、その要求を満たすために追加のハードウェア (ドルで測定) が必要になります。

doofledorfer からの応答に対処するために、あなたの仮定はほぼすべて 180 度ずれています。しかし、それはあいまいな質問に対する私のせいです。

1. 主要なサーバーの 1 つは 70% ベースで 7x24 を実行し、そこからスパイクが発生しますが、それが何をしているのか誰も知りません。

2. これは賛同や泣き言の問題ではありません...当社はこの問題に関して多くの選択肢を持っていないかもしれません.

3. これは外部から義務付けられているため、実施が遅れると多額の罰金が科せられる可能性があります。そのため、リスクを評価するための大規模な会議はほとんど不可能です。1 つのリスクがあります。2 倍のデータをダンプすると、既存の顧客のシステムがダウンする可能性があります。

日曜の深夜にシステムをオフラインにし、SQLIO テストを実行して、ストレージ サブシステムがどれだけ飽和に近づいているかを確認してください。そういうもの。

一連のモデムを備えた Linux ボックスがあり、非常に多数のリモート マシンへのデマンド ダイヤル (アウトバウンド) PPP 接続を作成する必要があります。pppdローカル モデムよりリモートの方がはるかに多いため、 inモードのインスタンスを 1 つ以上起動したいのdemandですが、接続が要求されるまで特定のモデムを割り当てません。pppd接続がアイドル状態になったら、別のリモートへの接続に使用できるようにモデムを解放したいと思います。

私はページを読んで、とオプションpppd manの概念、およびファイルとディレクトリを理解しました。ロック ファイルは、どのモデムが使用中または利用可能かを教えてくれます。また、モデムの割り当てをハードコーディングしている限り、複数のリモート ピアに接続できます。しかし、ダイヤルする必要があるときにスクリプトを呼び出すなどして、それらを動的に割り当てる方法が見つかりませんでした。Googleも知らないようです。callconnectoptions.DEVICE/etc/ppp/peersget_available_modempppd

回避策は、外部メカニズムでデマンド ダイヤルの必要性を検出し、それを起動pppdしてサービスを開始することかもしれませんが、機能を内部で活用する方がクリーンに思えpppdます。

任意のポインタやアイデアをいただければ幸いです。ご感想ありがとうございます！

私はお互いにメッセージを送るメンバーがいるウェブサイトを持っています。メッセージを送るのが好きなメンバーが数人になりつつあります。

現在、私は、ステータス（未読、保存済みなど）を示すさまざまなステータスIDを持つ「メッセージ」という巧妙なタイトルの適切なリレーショナルテーブルにメッセージが格納されていると述べました。これが事後であることはわかっていますが、このテーブルを他のいくつかのテーブルに分割する必要があると考えています (たとえば、ステータスの種類ごとに複数の場合など)。最善の方法はわかりません。それについて。

私にはいくつかのアイデアがありますが、どれもロケット科学ではありませんが、これに「標準的な解決策」があるかどうかに興味があります. Google はそうではないと提案していますが、この種の問題は、stackoverflow のような場所以外ではそれほど一般的ではないと思います。

すでに行ったことがある人はいますか？

アプリケーションのデータを永続的に保存したいと考えていますが、本格的なリレーショナル データベースは必要ありません。構造が単なる (キー、値) のペアである、基本的な「キャッシュ」のような永続ストレージで本当にうまくいくことができました。

データベースの代わりに最適でスケーラブルなオプションは何ですか?

さまざまなアイテム (メモ、記事、写真、ファイル) を 1 つのテーブルに保存します (カテゴリ、タグ、評価、統計など、すべてのアイテム タイプに共通する多くのメタデータがあります)。

私の最初のデザインは次のようなものでした: テーブルItemsに加えて、各項目タイプ ( NoteItems、ArticleItems、PictureItemsなど)の別の「詳細」テーブル。1 つのアイテムを取得するには、テーブルを 1 対 1 で結合する必要があります (SELECT * FROM Items INNER JOIN PictureItems ON Items.Id = PictureItems.Id WHERE Items.Id = N)。

私はこの「本通りの」設計がうまく機能すると確信しています (それを数回行っています) が、この設計がやり過ぎなのかどうか疑問に思うようになりました。単一のテーブル ( Items )を持つ方がはるかに簡単です。

画像またはファイルの種類のアイテムが約 5% あるとします。

そしてここで、質問: (ほぼ) 単一のテーブル デザインを使用する場合、画像フィールド用の詳細テーブルを作成した方がよいでしょうか (もちろん、画像とファイル アイテム用)。

シナリオ 1: 1 つのテーブルのみ:アイテム(メモ、記事、写真、ファイルを保存するため...)

シナリオ 2: 2 つのテーブル: Items (メモ、記事、画像ファイルを格納するため)、ImageItems (アイテム タイプの画像、ファイルの画像フィールドのみを格納するため)。一対一の関係

(シナリオ 3 は、シナリオ 2 のマイナーなバリエーションです。3 つのテーブル (Items、PictureItems、FileItems) を使用します)

シナリオ 1 の利点は次のとおりです。

• より単純な選択クエリ (結合なし)
• トランザクションのない更新(INSERT/UPDATE では 1 つのテーブルのみが更新されます)
• トランザクションレス更新によるパフォーマンス、スケーラビリティ?

シナリオ 2 の利点は次のとおりです。

• よりクリーンなデザイン
• より少ないデータ消費量(シナリオ 1 では、画像またはファイル以外のタイプのアイテムの約 95% がイメージ フィールドに NULL 値を持ち、ポインターに約 16 バイトが無駄になります)

1 (トランザクションのない更新) または 2 (データ消費量が少ない) のどちらのシナリオを選択しますか? ご意見ありがとうございます。

私はNumViews、DBテーブルの各オブジェクト/行のカウンターを保持する必要がある小さなWebプロジェクトに取り組んでいます。行へのすべての更新が開始されると、テーブルのオブジェクト数が増え、サイトの使用が増えるため、パフォーマンスが大幅に低下するのではないかと心配しています。

重要な場合は、MSSQL2K5で.NET3.5を使用しています。

助言がありますか？

前もって感謝します！

--ジョエル

DBの使用に関する現在の推測では、1秒あたり約66回の読み取りが持続します。

カウンターを別のテーブルに分割するというアイデアが好きです。それをサポートする記事やホワイトページを知っていますか、それとも誰もがしていることの1つですか？:-P

また、更新中に、DBはテーブル全体をロックしますか、それともその特定の行だけをロックしますか？私は一列だけを想定しますが、確かではありませんでした。

ありがとう、

--j

サイトからコミュニティ Web サイトを構築し始めており、Web フレームワークは Asp.net と Mysql になります。

サイトがライブになるとトラフィックが増えることが予想されるため、インフラストラクチャへのスケーラビリティの計画を早期に開始したいと考えています。

asp.net または mysql がスケーリングされている場所を読むことをお勧めし、優れたスケーリング手法を示しているケース スタディはありますか?