機能についての話ではありませんが、ちょっと考えを整理するためのメモとして。
データベースサーバー以外でもそうだと思いますがサーバーを利用する際の基本的な構成は以下のようになるかと思います。 
サーバー上でアプリケーションを実行している場合はネットワークは経由しませんが、外部でアプリケーション (サーバーを利用するリソース) が動作している場合、サーバーからの情報はネットワークを介して行われます。
また、接続の形態は SAS/SATA や PCI-e の HBA 等いろいろとありますが何かしらの方法でストレージ (記憶媒体) まで接続がされています。
バランスの取れた I/O 構成を考える場合、これら全体のバランスがどうなっているかを考慮する必要が出てきます。
たとえば、ストレージまでの接続が、
- PCI Express 2.0 x4
- PCI Express 2.0 x8
で行われている場合、バスの帯域上限が異なってきます。
前者の場合は片方向の帯域の上限は 1.6GB/sec、後者の場合は片方向の帯域の上限は 3.2GB/sec 程度になると思います。
これ以上の I/O をかけようとしてもストレージバスが飽和してしまい I/O がかけられなくなってきますので複数のバスを使用するというような対応が必要となってきます。
この上限はあくまでもストレージへの接続の上限ですのでストレージ自体のキャパシティとは異なってきます。
バスの帯域が確保できていてもストレージの性能上限以上は I/O を出すことはできませんので、ストレージの性能以上のバス帯域を確保していても有効に活用できません。
そのため、ストレージで実行可能な I/O とストレージバスの帯域はバランスがとれた形で構成しておく必要があります。
ストレージバスとストレージのバランスがとれていればよいかというとそれで終わりではなく、CPU にも気を付けておく必要があります。
SQL Server の Fast Track Data Warehouse (FTDW) では FTDW CPU Core Calculator という想定されているワークロードの I/O をこなすためのコア数を算出する Excel が提供されています。
Many Core の時代になっていますが、ひとつの CPU コアで処理できる性能には限界があり、たいていの場合はシングルスレッドでストレージの性能を上限まで使用することはできないかと思います。
ストレージの性能を最大限まで発揮するためにはマルチスレッドで処理を実行する必要があります。
SQL Server でいうと MAXDOP の設定ですね。
最近は 10 コア/HT で 20 コアというような CPU も出てきていますのでコア数が 100 を超える構成というものも組むことができます。
100 コアあった場合、SQL Server の 1 クエリで 100 コアすべてを使用することができるかというとここは難しいと思います。
max degree of parallelism オプション には以下の記述があります。
並列処理の最大限度を 0 に設定すると、使用可能なすべてのプロセッサ (最大 64 プロセッサ) を使用できます。
MAXDOP=0 を指定した場合、最大で 64 スレッド使用して並列処理をすることができます。
MAXDOP=90 のようにすれば 64 スレッド以上で並列処理をすることも可能なのですが、そこまで並列度を上げるとオーバーヘッドのほうが大きく、リニアに性能が伸びないかもしれないですね。 
SQL Server ではデータの論理的整合性や物理的整合性を保つためにロック/ラッチが使用されています。
これら制御はストレージのデータをメモリ上に読み込んだ後も、メモリ上のデータを使用して行われますので、ディスク I/O が発生しない状態での処理の待機となります。
これらの待機が多い場合には、ストレージの I/O ではなくロックの粒度やロックの保持期間に注視する必要が出てきます。 
データの変更が多い場合にはチェックポイント発生時のメモリからディスクへの書き戻しの速度にも影響が出てくることもありますのでこの辺も意識をしたほうがよいかもしれないですね。
サーバーで処理したデータはサーバー上でアプリケーションを動かしていない場合はネットワークを介してアプリケーションに返されます。
そのため、取得したデータを効率よく流せるネットワーク帯域が確保できないと、いくらサーバーで高速に処理をしても最後で遅延が発生してしまうことになります。
最近はストレージの速度が向上していますので、CPU の過負荷がネックになってしまうことがありますが、サーバーの構成やレスポンスが悪化した際にはどこがネックになっているのかを全体的に見て判断をしていけるようにしたいですね。