|
Страница 3 из 38
Файлы То, что пропускная способность диска - главнейший фактор при работе с большими массивами данных, думаю, ежу понятно. Если слегка подумать над этим вопросом, то возникнет желание распараллелить обращения по нескольким дискам. Кроме этого, некоторые БД имеют тенденцию вырастать до такого размера, что не умещаются на одном диске. В общем, большие и нагруженные базы надо делить. В InterBase каждая база состоит из главного файла (primary file) и необязательного набора дополнительных файлов. К сожалению, насколько удалось выяснить, на этом удобства и заканчиваются. Никаких средств, чтобы указать "эту таблицу помести сюда, а этот индекс - сюда" обнаружить не удалось. А жаль. Кроме этого в Interbase for Netware существует такая полезная вещь, как журнал упреждающей записи (Write Ahead Log). Суть идеи в том, что от базы на отдельный файл (обычно на другом диске) отделяется специальная область для быстрой записи обновлений. Этот журнал по сравнению с основной базой занимает гораздо меньше места, и обновлять его гораздо легче. Кроме того, предусмотрены средства для его деления на части. Таким образом, СУБД получает возможность очень быстро откликаться на обновления, и только затем переносить изменения в основную базу. В фоновом режиме и без задержки пользовательских запросов. Поскольку это удовольствие - только для пользователей Netware, далее на него отвлекаться не буду. При той архитектуре управления транзакциями, которая применяется в interbase толку от этого журнала немного. Все файлы в основном наборе, кроме последнего, имеют фиксированную длинну, задаваемую при их создании, в случае их полного заполнения растёт только последний. Синтаксис соответствующего оператора create database приведён ниже. Предусмотрен оператор для добавления файлов в базу - alter database. Вторая особенность, мимо которой нельзя пройти при обсуждении данной темы - это возможность иметь несколько копий одной и той же базы в виде так называемых теневых файлов (shadow). Набор теневых файлов, как я понял, хранит в себе зеркальное отображение страниц из основной последовательности файлов. У такого решения есть как достоинства, так и недостатки. + Повышается надёжность. Разложив теневые и основные копии по разным дискам можно получить дополнительную гарантию, что при аварии диска хоть одна копия да выживет. + Повышается производительность чтения. Когда при поступлении параллельных запросов или отработке частей одного запроса надо прочитать несколько областей БД, появляется возможность параллельно читать их с разных дисков. Это не всегда возможно без теневых файлов, так как обе области могут оказаться в одном файле на одном диске. - Места на диске расходуется в два (три, четыре, ... в зависимости от количества теней) раза больше. - Могут замедлиться обновления. Всё, что пишется, должно записаться в два или больше файлов. Иначе, какая же это тень? В общем, скорость записи реально определяется скоростью самого тормозного из запараллеленых дисков. |