Характеристики файлов таблицы

Для того чтобы разбить таблицу на файлы (а затем файлы разместить на разных внешних устройствах с целью повысить скорость работы СУБД при обращении к данным такой таблицы), требуется глубокое знание операционной среды, особенностей ее работы с файлами, поэтому в большинстве случаев достаточно создавать таблицу из одного файла данных и одного индексного файла. Однако в некоторых случаях разбиение файла данных или индексного файла на несколько файлов может привести к увеличению эффективности работы СУБД.

Решение вопроса о целесообразности такого разбиения опирается на механизм использования файлов таблицы ядром СУБД. При загрузке этот механизм схематично выглядит следующим образом (для файлов данных):

  1. все новые данные поступают только в первый файл до тех пор, пока будут исчерпаны возможности его естественного расширения (исчерпается файловое пространство на диске или для дальнейшего расширения потребуется расширение битовой карты файла);

  2. только после этого СУБД начинает помещать данные в следующий файл (опять же, до тех пор, пока будут исчерпаны возможности его естественного расширения);

  3. после этого (если есть возможность) СУБД расширит битовую карту первого файла и возобновит запись в первый файл, расширяя его (переход на пункт 1 и т.д.).

Из приведенной схемы следует, что пользователь БД не может прямо управлять размещением своей информации в файле данных (а только косвенно и достаточно грубо). Например, в случае, когда объем данных планируется настолько большим, что для их размещения требуется файл с двумя страницами битовой карты, то данные можно разместить и в двух файлах с одной страницей битовой карты в каждом. При этом первая часть информации, вносимой в таблицу, обязательно попадет в первый файл, вторая часть во второй файл. Если при этом файл загрузки информации отсортирован по какому-то полю, то записи с меньшими значениями этого поля попадут в первый файл, а записи с большими значениями во второй.

В этом случае SQL-запросы, использующие обе половины данных (из обеих частей файла), будут работать быстрее, если разместить файлы данных на разных дисковых носителях.

Если же отсортировать информацию в порядке убывания частоты использования (предположим, что пользователь обладает подобной статистикой), то в первый файл попадет наиболее часто используемая информация. Многие операционные системы позволяют создавать виртуальные диски в оперативной памяти (или на дисках с большей скоростью доступа). Именно на них рекомендуется расположить файл с часто используемой информацией.

Необходимость в нескольких файлах данных может возникнуть еще и при переполнении дисков (аналогично при ограничениях квоты использования дискового пространства). В этом случае гибкая многофайловая система, принятая в СУБД ЛИНТЕР, позволит более полно использовать имеющиеся ресурсы.

Работа СУБД с индексными файлами управляется пользователем. Он указывает, в каком из индексных файлов расположить тот или иной индекс. При этом весь индекс (B*-дерево) будет располагаться в указанном индексном файле.

Целесообразность построения индексов в нескольких отдельных файлах опять же заключается в том, чтобы расположить часто используемые индексы на быстрых носителях. Даже простое разнесение индексов по разным файлам на независимые физические носители данных может дать выигрыш.

СУБД ЛИНТЕР в определенных пределах может расширять файлы таблицы, что делается только по необходимости, т.е. в случае, если для записи какой-либо информации в файле больше нет места.

Таким образом, если заранее нельзя указать размер файлов, достаточный для размещения данных, то можно остановиться на минимальных размерах. СУБД увеличит файлы именно до таких пределов, чтобы поместить туда необходимую информацию. Однако не следует слишком часто пользоваться «расширяемостью» файлов, т.к. этот режим работы с файлами наименее эффективен.

СУБД ЛИНТЕР максимально использует возможности файловой системы ОС. Файловая система при расширении файла обычно присоединяет к нему первую свободную область нужного размера, поэтому использование расширяемых файлов приведет к фрагментации диска и к замедлению некоторых операций. Используя расширяемые файлы, можно минимизировать размер файлов (несколько проиграв в эффективности).