Предположим нам надо прочитать 100Мб последовательных данных с дисковой системы (full table scan). На правильный операционной системе с правильной файловой системой одно логической чтение имеет лимит 1Мб. Итого нам потребуется минимум 100 логических чтений каждое на 1 Мб. Можно тогда ограничиться рассмотрением чтения 1Мб, поскольку далее мы просто повторяем это 100 раз. У нас есть доступ к массиву жестких дисков неограниченного размера, и мы можем конфигурировать его как хотим. Берем 128*2 дисков и делаем RAID10 с stripe=8k. Наше логическое чтение 1Мб контроллером размазывается на 128 чтений по 8Кб каждое на своем диске и мы без учета накладных расходов на контроллере получаем наш ответ за одно физическое чтение с каждого жесткого диска. Но суммарно мы сгенерировали 128 физических чтений. То есть для одной сессии мы производительность максимизировали, но для 100 сессий такого типа суммарная производительность массива неоптимальна. Такой stripe может иметь смысл для data warehouse и прочих DSS. Сделали stripe=512k. Чтение размазалось только на два шпинделя, мы создали только 2 физических чтения на 1 логическое, что хорого для конкурирующих чтений от других сессий, но производительность чтения нашей сессии упала, поскольку мы вынуждены ждать когда каждый диск сможет нам отдать наши 512Кб. К счастью с высокой вероятностью эти 512Кб записаны последовательно, а скорость последовательного чтения с жесткого диска в десятки раз выше случайного чтения. Так что можно надеяться получить скорость чтения всего в несколько раз меньше, чем с массива из 128 пар дисков.
Для случайной записи, конечно, фокус не придет, и надо как можно больше шпинделей, но нормально базы данных пишут гораздо меньше, чем читают.