Я читал, что для повышения производительности и безопасности рекомендуется размещать следующие данные на отдельных дисках:
Когда вы рассматриваете RAID с использованием нескольких дисков, это становится огромным количеством используемых физических дисков.
Я понимаю, что файлы журнала выигрывают от того, что они находятся на собственном физическом диске из-за их последовательной схемы записи, но можно ли разделить другие файлы на «логические» диски вместо физических?
Выбирая решение, вы должны знать максимальную нагрузку, к которой должна быть готова ваша БД.
Если у вас есть продукт, который вы устанавливаете, у этого продукта будут рекомендации по настройке для различных рабочих нагрузок.
Если продукт разработан внутри компании, проведите сравнительный анализ, определите пределы производительности и стоимости. Развертывайте приложение постепенно. Помните приглашения GMail? Они были созданы для тестирования своего приложения в реальных условиях, но с контролируемым числом пользователей.
Разделять данные по разделам практически бесполезно. Единственное преимущество заключается в том, что фрагментация будет немного более локализована, но запросы к БД в основном являются произвольными.
НЕ используйте RADI5. Используйте RAID1 или RAID10. Может быть RAIDZ (ZFS на iSCSI SAN), если целостность данных критична.
Вы смотрите на трехсторонний компромисс.
Максимально высокая скорость и минимальный риск обычно обходятся вам дороже всего. По моему опыту, большинство генеральных и финансовых директоров хотят максимизировать скорость и минимизировать затраты. Требуется некоторое время, чтобы заставить их оценить стоимость принятия рисков, связанных с максимизацией скорости и минимизацией затрат.
С другой стороны, администраторы баз данных стремятся минимизировать риск.
Если вы храните базу данных и ее резервные копии на одном сервере, то все, что могло бы уничтожить сервер, может также уничтожить ваши резервные копии. Это обычно не приемлемый риск, но он зависит от приложения. Для уничтожения сервера требуется довольно большое событие; Не думаю, что когда-либо видел, чтобы один был уничтожен.
Если вы храните базу данных и ее резервные копии на одном физическом диске, то все, что могло бы разрушить диск, может уничтожить как базу данных, так и ваши резервные копии. Я видел, как диски разрушались довольно много раз. Это почти всегда недопустимый риск.
Некоторые проблемы со скоростью можно уменьшить с помощью твердотельных дисков, но они связаны с другими затратами и с некоторыми новыми рисками.
Лично я бы не хотел держать резервные копии на том же сервере, что и база данных, но я мог бы записывать резервные копии на тот же сервер (предполагая высокую скорость и низкую стоимость), а затем скопируйте или переместите их в другое место.
... можно ли разделить остальные файлы на "логические" диски вместо физических?
Вы можете разместить их на разных логических дисках, которые находятся на одних и тех же физических дисках. Это не даст вам всех преимуществ использования отдельных физических дисков, но если вы позже решите, что вам нужно больше физических дисков, вам будет проще переместить логические диски на новые физические диски.
Есть две основные причины для распределения файлов базы данных на нескольких дисках: производительность и доступность.
Доступность сводится к следующему: вы просто не хочу потерять файлы данных, файлы журналов и файлы резервных копий одновременно; потеря одного из них приемлема, потеря двух - большой беспорядок, потеря всех - полная катастрофа. Таким образом, вы кладете их на разные диски, чтобы минимизировать этот риск (а вы действительно должны иметь резервные копии на другом сервере или внешнем хранилище; иногда сервер жестяная банка и воля быть полностью уничтоженным). Чтобы это вообще имело смысл, нужно использовать разные физический Диски: наличие нескольких логических томов на одном физическом хранилище совершенно не поможет вам, когда это физическое хранилище умирает.
Производительность немного сложнее, и для больших баз данных также потребуется более двух или трех мест для хранения файлов; но это сильно зависит от дизайна базы данных и рабочей нагрузки. Однако во всех возможных сценариях это по-прежнему имеет смысл только в том случае, если задействованы разные физические диски: какой смысл в разделении двух дисковых операций ... если они в конечном итоге выполняются одними и теми же дисками? Диски по-прежнему должны будут обрабатывать одновременные запросы с разными шаблонами доступа и действовать в разных секторах, как если бы файлы находились на одном томе.
Одно незначительное преимущество, которое вы получите, даже если вы просто используете отдельные логические диски, заключается в том, что если в каком-либо из отдельных компонентов заканчивается пространство, это не обязательно означает, что все остальные одновременно исчерпали пространство - немного более изящная неудача.