Корректно ли использовать медленный жёсткий диск для моделирования задержки в запросах?

Для оптимизации запросов к БД на продуктовой среде, где стоит ssd, хочу оптимизировать их на медленном объёмном хранилище. Будет ли оптимизация эквивалентной для той же БД с теми же запросами на SSD?


Ответы (1 шт):

Автор решения: S.H.

К сожалению, нет, не будет.

Пример запроса, на выполнение которого не будет влиять скорость диска: попробуйте сделать то, что называется "table scan" - например, поиск по текстовому полю с where Name like '%тра та та%'.

Здесь скорость чтения последовательных данных с диска не будет уже решающей. Запрос будет одинаково плохо работать в обеих слкчаях, тем более, что после первого обращения высока вероятность, что страницы базы данных останутся в memory cache.

Другой сценарий, когда запрос медленный сам по себе: select top 50 * from (...) union (...) order by ..., где вместо многоточий - подзапросы, которые выполняютя на разных частях базы. Этот запрос не может отработать, не сделав полный table scan: нужно сначала вычислить полные подзапросы, потом их объединить, а потом взять top'чик.

И это только тривиальные случаи плохих запросов, на которые иногда приходится натыкаться.

Если Вы хотите моделировать медленную сеть - есть куча "замедлителей запросов", напрмер, вот здесь описана команда, котрая "добавит 250 мс задержки, ограничит пропускную способность до 1 Мбит/с и отбросит 10% пакетов на указанные адреса по указанным протоколам на указанных портах".

Возможно, не всё из этого нужно, но добавление задержки позволяет найти проблемные места, когда клиент "слишком активно" общается с базой, довольно уверенно.

Но для моделирования поведения базы... не знаю. Но замена одного типа жесткого диска на другой - не очень адекватный подход к моделированию: лучше, чем ничего, но не все возможные "тормоза" позволяет выявить

→ Ссылка