|
Страница 2 из 38
Как устроены файлы БД внутри Вообще-то писать на эту тему про коммерческие СУБД достаточно сложно, так как большинство поставщиков стремится скрыть внутренние принципы, чтобы не стянули конкуренты. С другой стороны, без определённого уровня знаний невозможно понять, что происходит внутри СУБД и, соответственно, оптимизировать это дело. Во-первых, базы данных хранятся в файлах. Хотя существуют системы, которые позволяют хранить данные прямо в сырых разделах, этот способ уже вышел из моды, так как современные файловые системы не оказывают существенного торможения, как это было когда-то. Далее - файл состоит из байтов (хотя в unixообразных системах бывают и блочные). И в этом массиве байтов нужно размещать кучу всего: записи данных, индексов, хранимые процедуры, метаданные (структура всего остального), и т. д. Все эти вещи имеют самые различные размеры. К некоторым аспектам этой темы я буду возвращаться ниже по мере необходимости, скажем, при обсуждении индексирования или транзакций. Страницы Таким образом, возникает задача динамического распределения адресного пространства внутри файла(ов) БД. Решается она достаточно простым образом - пространство файла делится на страницы фиксированного размера. Размер обычно должен быть кратным степени двойки для упрощения вычислений и достаточно большим, чтобы в него влезало по несколько записей большинства видов. Если же попадается некоторый объект (скажем BLOB), который в одну страницу не умещается, то его делят на части и снабжают внутренней индексной информацией, куда какой кусок поместили. Каждая страница обычно содержит заголовок, в котором хранится тип информации, под которую отведена страница (данные какой-либо таблицы, индекса, кусок блоба, ...), а так же размеры или ссылки на начала записей, размещённых в странице. Это позволяет иметь в одной странице несколько записей переменного размера. В частности, строки обычно содержат заголовок из их длинны, за которым следуют сами символы. Естественно, размер страницы влияет на эффективность использования пространства в БД. Примерно такая же ситуация возникает в файловых системах, когда надо разместить файлы в кластерах. Естественно, в конце каждой страницы остаются небольшие промежутки, в которые не умещается ни одна запись. Поскольку обычно в каждой странице размещается связанная информация, скажем, записи только из одной таблицы, то и размер "хвостов" будет различным в страницах различного типа. Чем больше средний размер записи, тем больше "хвосты". Если размер самих страниц небольшой, то придётся часто делить записи, а обращение к записям и BLOB'ам по частям замедлит производительность. "Хвостов" будет много, но они будут сравнительно небольшие, так что база слегка уплотнится. Большое количество страниц в базе так же слегка замедляет их поиск и обработку. Если же размер будет большим, то "хвостов" будет мало. Размер же их будет зависеть от характера данных. Ещё одна вещь, которую следует помнить, прежде чем бросаться увеличивать страницы, это то, что обращения к базе производятся именно страницами. То есть страница читается из базы целиком, а затем InterBase вытаскивает оттуда нужные записи. Если же требуется обновление, то в страницу вносятся соответствующие изменения, корректируется заголовок (который обычно содержит информацию о размещении записей в пределах страницы и какой-либо вид контрольной суммы) и то, что получилось, пишется на диск. Так что размер страницы не должен быть во много раз больше размера читаемых за раз данных. Хотя если учесть, что данные часто читаются массово, а современные винчестеры как раз хорошо оптимизированы для последовательного чтения данных (как это происходит при вычитывании страницы), то данный фактор обычно не является самым важным. С другой стороны, увеличение размера страницы довольно радикальным образом ускоряет обращения к индексам. О них будет рассказано отдельно. Фактически количество обращений к индексу при поиске записи зависит от глубины дерева, которая напрямую определяется соотношением объёма индексируемых значений и размера страницы. И это - важный повод для того, чтобы сделать страницу по-больше. Размер страницы по умолчанию в interbase составляет 1 КБ. Когда-то я писал, что это нормально. Теперь я так не считаю. Это мало. Рекомендую 4 или 8 КБ. Последнее, насколько я знаю, предел. Базы с 1 КБ можно эксплуатировать только на очень слабой машине, когда экономия памяти (как оперативной, так и дисковой) имеет решающее значение. Хотя лучше в таких условиях базами данных вообще не заниматься. По поводу того, что именно выбрать, 4 или 8, могу скзать следующее. В документации по настройке interbase есть тёмные места, в которых непонятно, о каких страницах идёт речь - страницах БД или страницах виртуальной памяти. Отсюда сложности с точной оценкой поведения сервера. Если же настроить размеры страниц равными, неопределённость устраняется. По этой (возможно, субъективной) причине мне больше нравится размер в 4 КБ. По крайней мере на процессорах Intel виртуальная память работает именно такими страницами. Хотя если в базе есть таблицы с миллионами записей, а оперативная память на сервере - сотни мегабайт, то я всё же порекомендую однозначно 8. |