Предполагая, что рабочая нагрузка для SQL Server - это обычная база данных OLTP и что всего доступно 20 дисков, какая конфигурация будет иметь больше смысла?
Единый RAID 1 + 0, содержащий все 20 дисков. Этот физический том будет содержать как файлы данных, так и файлы журнала транзакций, но из этого RAID будут созданы два логических диска: один для файлов данных и один для файлов журнала.
Или...
Два RAID 1 + 0 по 10 дисков в каждом. Один физический том будет содержать файлы данных, а другой - файлы журнала.
Причина этого вопроса связана с разногласиями между мной (разработчиком SQL) и моим коллегой (администратором баз данных).
Для каждой конфигурации, которую я делал или видел, как это делали другие, файлы данных и файлы журнала транзакций были разделены на физическом уровне и помещены на отдельные RAID-массивы.
Однако мои коллеги аргументируют это тем, что, помещая все диски в один RAID 1 + 0, любой ввод-вывод, выполняемый сервером, потенциально распределяется между всеми 20 дисками, а не только 10 дисками в моей предлагаемой конфигурации.
Концептуально его аргумент мне понятен. Кроме того, я нашел некоторую информацию от Microsoft, которая, кажется, поддерживает его позицию.
http://technet.microsoft.com/en-us/library/cc966414.aspx
В разделе «3. Конфигурация RAID10», показывающем конфигурацию, в которой все 20 дисков выделены одному RAID 1 + 0, говорится:
В этом сценарии параллелизм ввода-вывода может использоваться всеми разделами в полной мере. Следовательно, рабочая нагрузка ввода-вывода распределяется между 20 физическими шпинделями вместо четырех на уровне разделов.
Но ... любая другая конфигурация, которую я видел, предполагает физическое разделение файлов данных и журналов на отдельные RAID-массивы. Все, что я нашел здесь на Server Fault, предполагает то же самое.
Я понимаю, что файлы журнала будут тяжелыми для записи и что файлы данных будут представлять собой комбинацию операций чтения и записи, но требуется ли для этого, чтобы файлы размещались на отдельных RAID, а не на одном RAID?
Аргумент администратора базы данных имеет смысл, но вот загвоздка: если я правильно читаю статью, MS говорит о производительности на уровне раздела БД и таблицы, а не на уровне раздела диска / файловой системы. Я считаю, что администратор баз данных выиграет дискуссию, ЕСЛИ вы говорили о том, какой тип массива создавать ТОЛЬКО для файлов данных. Поскольку вы говорите о том, какой тип массива создать для файлов данных И журналов, я считаю, что ваш аргумент имеет наибольший смысл с точки зрения производительности диска / файловой системы. К файлам базы данных всегда обращаются случайным образом, к файлам журналов всегда обращаются последовательно. Никогда не следует смешивать эти два типа ввода-вывода на одном физическом или логическом диске. Кроме того, создание нескольких логических разделов на одном физическом диске (или массиве дисков) ничего не дает, поскольку базы данных и журналы будут конкурировать за один и тот же физический ресурс.
Моя рекомендация такова:
Создайте один физический массив (RAID10) для файлов базы данных и отдельный физический массив (RAID10) для файлов журнала.
Это будет зависеть от рабочей нагрузки, которую вы возлагаете на систему. Если у вас высокая рабочая нагрузка, вы хотите разбить их на части, потому что файлы данных будут очень случайной рабочей нагрузкой, а журнал транзакций - это очень последовательная рабочая нагрузка. Обычно вы получаете лучшую производительность, если разбиваете их на части, так как вы не хотите, чтобы скорость ввода-вывода для журнала замедлялась или на нее влияла нагрузка из файлов данных.
Ненавижу быть язвительным, но администраторы баз данных ... администраторы баз данных.
Они бесконечно умнее, чем администратор сервера, когда дело доходит до построения сложного запроса, который не выполняет базисных сканирований таблиц, но администратор оборудования / сервера бесконечно умнее, точно так же, в распределении необходимых ресурсов (при условии, что у него седые волосы. или четыре). :)
Мой короткий ответ: все дело в шпинделях, и все дело в шпинделях, а по состоянию на последние несколько лет - в вашем выборе файловой системы и о том, сколько оперативной памяти эта файловая система может вместить.
У меня был потрясающий успех в разделении dbdata / logs / транзакций между (a) разными физическими контроллерами, (b) с использованием настроенных параметров файловой системы (в частности, и это большой, соответствующий параметрам вашей db пишет / читает / фиксирует в сектор / блок того же размера, что и fs) и (c) «Выбор моего яда».
Некритические данные, журналы, данные отката и т. Д. Могут более или менее работать в "уязвимых" файловых системах (memfs, fast-io-fs без журналирования / предполетного / предварительного кэширования), в то время как фактические файлы данных (в зависимости от типа db) остаются красиво распространяется на такие дешевые вещи, как хорошо сконструированный zpool.
Предыдущий постер абсолютно прав в том, что журналы транзакций являются последовательными и могут / должны выполняться на томах, предназначенных для быстрой записи, а не для чтения (и, возможно, не обязательно для «стабильности»), таких как большая полоса. Ответчик («вот в чем загвоздка») также находится справа: конкуренция за диск неприятна, если данные не в оперативной памяти или в дисковом кэше, и без серьезных (произносится «долго, монотонно, утомительно и склонно к ошибкам угадывания») ), вам обязательно следует избегать смешивания дисков с базами данных, которые функционируют иначе. (например, высокая скорость чтения и запись больших данных с низкой передачей - любая стратегия кеширования fubar).
Мой совет «ISO Layer 8» таков: обратитесь к администратору баз данных и скажите: «Эй, я не собираюсь говорить вам, что вы ошибаетесь, и, в свою очередь, вы не собираетесь рассказывать мне, как спроектировать мои системы». часто придерживаются шаблонных рекомендаций, которые в долгосрочной перспективе редко бывают оптимальными. Не потому, что они не знают, что делают, - а потому, что доверяют промежуточной документации, выдвинутой $ vendor как «предназначенной для того, чтобы раздражать наименьшее количество клиентов / приводящей к меньшему количеству клиентов. звонки помощи ".
Если вы хотите написать мне прямое сообщение, не стесняйтесь; Но имейте в виду - глобального идеального конфига не существует. Количество строк, ожидаемое сканирование, мощность и эффективность ваших ключей / индексов, запросов в секунду, полных сканирований таблиц за интервал и т. Д. - все это играет важную роль. Это сложная игра.
Напоминает мне WARGAMES ..
Хотите сыграть в игру?
Да. Поиграем в Global Thermonuclear War.
..
Как насчет хорошей игры в архитектуру базы данных?
[Стратегия Глобальной термоядерной войны была бы проще ..]
:)
Очень упрощенный ответ заключается в том, что это будет зависеть от вашего соотношения чтения / записи. Учитывая OLTP, у вас, вероятно, есть хорошее сочетание, и хранение журналов транзакций отдельно от баз данных позволит транзакции в массив БД «преследовать» массив журналов вместо того, чтобы один массив перемещался между ними.
Журнал транзакций обычно только записывается и записывается последовательно. Если вы храните журналы на собственном наборе дисков, эти диски почти никогда не будут иметь никаких запросов (кроме случаев обновления метаданных файловой системы), просто переходите вперед по одному сектору за раз.
Если журналы и данные перемешаны в одном наборе RAID (даже если они находятся на разных логических устройствах), вы потеряете прирост производительности от последовательной записи журналов транзакций.
Я предполагаю, что если вы будете записывать небольшие объемы данных в каждой транзакции, вы выиграете в производительности, храня журналы в собственном массиве. Если у вас так много данных, что время записи данных на диски существенно по сравнению со временем поиска, было бы лучше иметь один большой массив.