Файловые системы по сравнению с "чистыми" (неструктурированными) дисками
Большинство СУБД позволяют администратору системы выбрать способ размещения файлов СУБД (на "чистых" дисках или в стандартной файловой системе UNIX). Некоторые системы, наиболее известными из которых являются Ingres и Interbase, навязывают использование файловой системы UNIX. Для систем, которые допускают выбор указанных возможностей, приходится оценивать целый ряд разных критериев.
Хранение данных в файловой системе оказывается менее эффективным (отличие составляет по крайней мере 10%), поскольку при выполнении каждого обращения к диску со стороны СУБД в работу включается дополнительный слой системного ПО. Поскольку в больших СУБД часто одним из ограничивающих ресурсов является мощность процессора, использование "чистых" разделов (raw partition) улучшает производительность системы при пиковой нагрузке. Только по этой причине большинство администраторов баз данных обычно предпочитают хранение данных на "чистых" разделах дисков. Если ожидается, что система достигнет своих пределов производительности, особенно в части использования мощности ЦП, то это может быть наиболее подходящий выбор. Однако следует отметить, что эффективность процессора в действительности становится под вопрос только под пиковой нагрузкой. Большинство же систем испытывают эти пиковые нагрузки только в очень редких случаях.
Хранение данных в файловой системе имеет также определенную цену в терминах потери емкости памяти. Файловая система UNIX потребляет примерно 10% от форматированной емкости дисков для метаданных о файлах и файловой системе. Более того, файловая система резервирует 10% оставшегося пространства, чтобы обеспечить быстрый поиск свободного пространства в случае расширения файлов (этот дополнительный объем памяти в принципе может быть использован, но за счет потенциально значительных дополнительных задержек, которые возникнут при открывании или расширении файлов файловой системы). Если СУБД работает с данными через файловую систему, то по сравнению с "чистым" диском емкость дисковой памяти в целом уменьшается на 19%.
Если хранение данных в файловой системе обходится дороже как с точки зрения потребления мощности процессора, так и с точки зрения потерь емкости памяти, возникает вопрос: "А зачем все это нужно?". Имеется несколько важных причин, по которым в СУБД используется хранение данных в файловой системе. Большинство из них связано с обеспечением гибкости или относятся к разряду более знакомой для пользователя технологии.
Во-первых, и что возможно наиболее важно, использование файловой системы позволяет работать с памятью с помощью стандартных утилит UNIX. Например, стандартные утилиты UNIX ufsdump и ufsrestore могут использоваться для того, чтобы производить надежное резервное копирование и восстановление памяти СУБД. Для этого могут также использоваться не связанные с операционной системой инструментальные средства резервного копирования, подобные Online:Backup 2.0 компании Sun. Кроме того, гораздо проще осуществлять манипулирование отдельными частями базы данных. Например, можно осуществлять прямое перемещение таблицы с одного диска на другой, даже если используются диски разного размера и типа. Поскольку каждый из поставщиков СУБД предлагает свои собственные внутренние утилиты резервного копирования и восстановления, все они различны. Более того, некоторые из них выполняются настолько медленно, что заказчики часто прибегают к использованию копирования физических томов (т.е. используют команду dd(1)) со всеми присущими такому копированию сложностями. Хранение данных в файловой системе позволяет выполнять единообразные, надежные процедуры для того, чтобы работать через систему и сеть. При этом, если необходимо, могут также использоваться инструментальные средства поставщиков СУБД.
При некоторых обстоятельствах операции через файловую систему дают возможность оптимизации, которую сама СУБД не может реализовать. В частности, файловая система UNIX пытается кластеризовать данные в более крупные физические единицы, чем большинство СУБД. Поскольку дисковое пространство для таблиц часто заранее распределено, файловой системе обычно удается агрегатировать данные в блоки объемом по 56 Кб, в то время как менеджеры памяти СУБД обычно оперируют только страницами размером в 2 (или иногда 8) Кб. Последовательное сканирование таблиц или индексов, хранящихся таким образом часто может оказаться более эффективным, чем эквивалентных таблиц, хранящихся более традиционным способом. Если в операциях системы доминирует последовательное сканирование (или операции соединения (joins), которые часто подразумевают последовательное сканирование), хранение данных в файловой системе обеспечивает более высокую производительность.
Рекомендации:
Для обеспечения максимальной пиковой производительности следует конфигурировать "чистые" диски.
При размещении таблицы СУБД в файловой системе UNIX следует добавить 19% дополнительного дискового пространства на накладные расходы файловой системы.
Для обеспечения максимальной гибкости можно размещать таблицы СУБД в файловых системах.
Если СУБД хранит таблицы в файловой системе UNIX следует сконфигурировть 15% дополнительной памяти (или соответственно более маленький кэш разделяемых данных).
Обычно пользователи рассматривают СУБД как средство хранения и последующего поиска своих данных и вовсе не задумываются о том, что же в действительности хранится на диске. На практике, программное обеспечение СУБД поддерживает значительное количество дополнительной информации. Было бы серьезной ошибкой предполагать, что для размещения заданного количества данных пользователя потребуется тот же самый объем дискового пространства. Схема базы данных, табличные индексы, B-деревья узлов каталогов, временные таблицы, заранее выделенное пространство для хеш-таблиц и индексов, пространство для сортировки, файлы журнала, архивы и мириады других функций - все это включается в дисковое пространство системы.
Если отсутствует более точная информация, то обычно разумно было бы предусмотреть примерно удвоенный объем дискового пространства по сравнению с объемом "чистых" данных. Это обеспечивает некоторую гибкость для создания индексов и т.п., и в итоге позволяет улучшить производительности приложения. Хотя коэффициент 2 на первый взгляд кажется чрезмерным, следует, например, иметь в виду, что индексация, навязываемая предложенным тестом TPC-D потребляет более 400 Мб. При этом объем "чистых" данных составляет примерно 650 Мб. При использовании устанавливаемых по умолчанию параметров памяти СУБД Oracle, объем "чистых" данных, необходимых для реализации теста TPC-C, увеличивается на 30% при хранении их в базе данных Oracle даже без индексации. Поэтому можно легко потребовать для системы даже гораздо больше, чем 100% дополнительного пространства.
Рекомендации:
Объем дискового пространства базы данных должен по крайней мере на 50% превышать требования по объему "чистых" данных (к этому необходимо добавить накладные расходы файловой системы, если таковая применяется). Более безопасная цифра - 100%.
Для размещения журналов транзакций и архивов необходимо выделить отдельное дисковое пространство. Его объем следует оценить отдельно, поскольку они должны размещаться на других физических дисках, чем сама база данных.
