ディスク上にストレージがあると仮定した場合、単一のデータベース サーバー (マスター スレーブ アーキテクチャではない) の大まかなパフォーマンス制限 (読み取り/秒、書き込み/秒) はどれくらいですか? ディスクの種類 (SSD と非 SSD) によって、読み取り/秒、書き込み/秒はどれくらいになりますか? 単純な操作 (主キーで 1 行を選択し、1 行を更新し、正しくインデックス付けする) を前提としています。この制限はディスクのシーク/書き込みに依存すると想定しています。
編集: 私の質問は、データベースがサポートする操作数の大まかなメトリックを取得することに関するものです。たとえば、300 挿入/秒をトリガーする新しい機能が、追加のサーバーでスケールアウトせずにサポートできるかどうかを知ることができるようにします。
答え1
多くのベンチマーク結果を読むことができますここあたかもそのウェブサイトが信頼できる情報源であるかのように。
答え2
大胆に言っておきますが、あなた自身の質問に対する答えを得るために、これを試してみることを提案します。WindowsがSSIO.exe開発ボックスでディスクのパフォーマンスをテストし、何もしないときのパフォーマンスを把握します。
次に、パフォーマンス モニターを実行します (MS-SQL TKProf を使用していると仮定します。おそらく Oracle です。mysql やその他のツールは使用しないでください。同様のツールがあるはずです)。クエリを実行し、読み取り/書き込みの数と、それを実行するのにかかった CPU の量を確認します。次に、SSIO とパフォーマンス モニターの数値を比較し、現在の機器に基づいて、この更新に必要なユーザー数/頻度を処理するためにハードウェア要件を調整できます。
とはいえ、300 行というのは、かなり低速なディスクであっても、妥当な SQL Server で変更される行数としてはごくわずかです。大規模な複合インデックスや BLOB などがない限り、ユーザーが 150 万行を作成するクエリを監視しているときに、比較的控えめなハードウェアで 1 秒未満で実行されるライブ イン プロセスがあります。
答え3
あなたできないアプリと負荷をベンチマークせずに判断します。
それは、RAID レベル、スピンドル速度、トランザクションのサイズ (「挿入」だけではありません)、トリガー、外部キー、ハイパースレッディング、サーバー上の他のアプリ、サーバー内の RAM、ディスクの配置方法 (tempdb 用に個別のボリューム、DB t-log ごとに 1 つ、MDF など)、サービス パック レベル、RAID コントローラー キャッシュ構成、CPU Ls + L3 キャッシュ、コア数、スキーマ設計、コードなどになります。
スケールアップはスケールアウトよりも簡単です。サーバーを統合したりテーブルをパーティション分割したりするとオーバーヘッドが追加されます。RAM とスピンドルを追加する方が安価です。
良い記事とはポール・ニールソンの 35k TPS300 程度よりも少なくとも 100 倍高い負荷がかかります。