Оригинальная ссылка. http://thedailywtf.com/Articles/The-Certified-DBA.aspx.
Краткое содержание статьи: Администратор базы данных предлагает подход, предусматривающий строгое разбиение на разделы, 10 разделов на диск (3 реальных диска и 3 рейда). Статистика показывает, что производительность не оптимальная. Затем администратор базы данных предлагает альтернативу 1 разделу на диск (с дополнительными дисками). Это тоже не удается. Затем системный администратор настраивает один диск, один раздел и спасает положение.
Размер дисков не упоминается, но приведены типичные на сегодняшний день размеры дисков (порядка 100 ГБ), разделы; будет огромным, меня удивляет, что один диск со всеми разделами превосходит производительность.
Изначально я подозреваю, что данные были разделены и, следовательно, считывались быстрее. Но почему производительность не ухудшалась со временем, когда происходили все вставки и обновления? Видел это на Reddit, но объяснение было явно сосредоточено на шпинделе / пластине. Об этом в статье не упоминалось. Есть ли другая причина? Я могу только догадываться, что в таблицах использовалось неправильное распределение хешей, что приводило к неравномерному распределению по дискам (неправильное разбиение); это увеличило бы время выборки. Есть предположения?
Чтобы понять, почему один раздел всегда превосходит несколько разделов на одном диске (при прочих равных), вам нужно только подумать о том, что должна делать головная сборка. Всегда будет много перемещений вперед и назад, но с несколькими разделами потребность в перемещении сборки будет намного больше. Поскольку это самая медленная часть доступа к диску, влияние на производительность велико.
Все это глупо, извините.
Если у вас 6 дисков, вы можете попробовать
3 пары RAID-1. Каждый с одной перегородкой. Первый раздел для system / tempdb, второй для данных, третий для журналов транзакций.
1 пара RAID-1 и один 4-дисковый RAID-10. По одному разделу каждый.
Если данные в основном предназначены только для чтения, один большой том RAID-5 с одним разделом.
В любом случае нет смысла использовать одну и ту же пластину для разных объемов.
Вся эта штука с разделами звучит глупо. Сожалею. разделение данных на одном диске (то есть нескольких файлов в нескольких разделах) никаким образом не снижает IO по сравнению с размещением всех файлов в одном разделе. Я также нахожу забавным, что администратор баз данных не потрудился провести тесты ввода-вывода с помощью инструмента тестирования, чтобы проверить реальную производительность настройки диска.
Теоретически, независимо от того, насколько запутаны вещи, емкость ввода-вывода НЕСКОЛЬКИХ дисков (а они покупали их все больше и больше) всегда НАМНОГО выше, чем у одного - так что здесь что-то действительно подозрительно. Я не говорю, что статья неправильная - просто скучаю по частям, чтобы аргументировать плохую работу.
В статье много отсутствующей информации, но мне кажется, что администратор базы данных думал, что он пытался представить базу данных с помощью блочного устройства (а не файловой системы), но делал это на каком-то SAN или другом общем хранилище. устройство. К сожалению, он тоже был идиотом.
Возможно, «сертифицированный администратор баз данных» был беженцем из AS / 400 или AIX ... Инструменты системного администратора IBM, позволяющие назначать хранилище в зависимости от физического расположения на диске.
Я делал это (правильно) десять лет назад с базами данных Informix на ящиках Sun, когда мой работодатель был слишком дешев, чтобы покупать Veritas Filesystem. Когда система выйдет из строя, управление диском из базы данных позволит избежать более чем четырехчасового запуска UFS fsck.