バースト使用のためのIO要件の見積もり

SQLデータベースを1日中定期的に照会するアプリケーションがあります。比較的大量のデータに対する個々のリクエストが散在する、ゼロまたはわずかなアクティビティの期間があります。これらの要求が発生した場合、主な目的はデータを迅速に提供することであり、副次的な目的はそれを費用対効果の高い方法で行うことです。アプリケーションの性質上、データ/インデックスが前のクエリ（異なるユーザー、データの異なる部分で作業）からRAMにキャッシュされることはほとんどありません。

比較的安定した使用を経験するシステムの場合、ディスクキューの長さを観察し、その数を比較的小さく保つという経験則を聞きました。これは特にAWSで実行され、100 IOPSあたり1のディスクキューの長さが妥当であるという経験則を確認しました。

そのようなシステムのIO要件をどのように見積もることができますか？個別のバースト性のあるクエリを処理する場合、ディスクキューの長さは信頼できる指標ですか？考慮すべき他の指標はありますか？

SQL ServerのIOについて常に考慮してきた主要なメトリックは、IOPまたはディスクキューの長さではなく、ディスクスループット（秒/読み取りおよび秒/書き込み）です。全体として、データベースはディスクに投げることができる操作の数ではなく、それらの操作がどれだけ速く完了するかということではありません。一般的な経験則は、20ms /オペレーション未満にすることです（ただし、低いほど常に優れています）。詳細については、この記事をご覧ください。

Disk Queue Lengthは偽の統計であり、関連性はなくなりました。問題は、値が単一のドライブのキューを測定することですが、RAID、SAN、および他の分散ストレージの時代に生きている今、この値を意味のある数値に適切に変換する方法がありません。パフォーマンスメトリックの優れた出発点は、クエスト/デルからのこのポスターで、それらが重要である理由とそうでない理由について多くのことと説明を提供します。それらのすべてを使用する必要はありませんが、それらは開始です。

IOをテストするには、ピーク時のワークロードを理解する必要があります。キャッシュされるトランザクションの数と量 これらを知っていて測定していない限り、判断するのは本当に難しいです。ワークロードを作成し、SQLIOなどのツールを使用してストレージをテストできますが、適切なテストを構築するにはワークロードパターンが必要です。

最後に、AWSに関する注意：私の知る限り、AmazonはAWSでのIOパフォーマンスを保証しません。これは主に、ストレージが大規模な共有リソースであり、ストレージの特定の領域でのあなたとあなたの隣人のパターンを測定することが不可能だからです（ノイズの多い隣人の問題を参照）。

私の推奨は、できるだけ多くのメモリを割り当てることです。SQL Serverは、（LRU-Kに基づいて）バッファプールの圧力と領域が不足している場合にのみ、メモリからデータをプッシュします。したがって、バッファプールがデータベースのほとんどをメモリに格納できる場合、バースト性のあるパフォーマンスの一部を軽減できます。また、キャッシュオブジェクトを「ウォーム」に保つことができる戦術を検討してください。最後に、SQL 2014と新しいHekaton機能に注目してください。