Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 21

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 15 16 17 18 19 20 < 21 > 22 23 24 25 26 27 .. 161 >> Следующая

і іути доступа для одной таблицы

43

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

Растровые индексы

Растровые индексы были созданы специально для решения особых задач организации информационных хранилищ. Главное достоинство растровых индексов заключается в том, что они позволяют эффективно комбинировать несколько не очень селективных условий, которым соответствуют различные индексы, для получения одного короткого списка строк, удовлетворяющего сразу всем условиям. Однако один индекс, состоящий из нескольких столбцов, позволит совершить практически то же самое, но без недостатков, описанных в следующем абзаце, поэтому я считаю, что растровые индексы редко оказываются полезными. Определенно, для настройки запроса они мне никогда не требовались. Ho я не очень много работал с информационными хранилищами, поэтому вам растровые индексы вполне могут понадобиться, если вы вплотную занимаетесь хранилищами данных.

Каждое значение растрового индекса указывает на некоторый объект, который можно назвать списком битов со значениями «да» и «нет». Этот список, в свою очередь, отображается на полный список строк таблицы, причем биты «да» отображаются на строки, в которых для индексированного столбца существует значение. На этих битовых строках и битовых строках других растровых индексов удобно выполнять операции AND и OR, комбинируя условия для нескольких растровых значений многих индексов. Существенным недостатком битовых строк является дороговизна поддержки их синхронизации с часто меняющимся содержимым таблиц, особенно если обновления производятся в середине таблицы. Растровые индексы хорошо работают для таблиц, содержимое которых только считывается и очень редко меняется, но, с другой стороны, большие таблицы не разрастаются, если не изменять их содержимое, а для небольших таблиц специальные индексы эффективного доступа к данным не требуются. Наилучшее применение такого индекса — это действительно информационное хранилище, для которого он и был разработан. Например, база данных хранилища, доступная только для чтения в течение дня и периодически, например по ночам или по выходным, проводящая обновление всех таблиц при помощи некоторой базы данных транзакций, таблицы в которой постоянно увеличиваются в размере.

Пути доступа для одной таблицы

Самый элементарный запрос запрашивает некоторое подмножество данных из одной таблицы. Подобные запросы редко интересуют нас с точки зрения настройки, но даже самый сложный запрос, соединяющий множество таблиц, начинает с одной ведущей таблицы. Вам необходимо выбрать путь доступа к ведущей таблице в многотабличном запросе так же, как для однотабличного запроса. Однотабличный запрос всегда можно получить, разобрав многотабличный запрос на составляющие, удалив соединения, не ведущие в искомую таблицу, и условия для
44

2. Основы доступа к данным

них. Таким образом, каждая задача оптимизации запроса включает выбор оптимального однотабличного пути доступа к ведущей таблице. Реализации таблиц и методов доступа к таблицам слегка различаются у разных поставщиков баз данных. Чтобы быть как можно более точным и конкретным, в этом разделе я буду рассматривать доступ к таблицам в Oracle, поскольку различия между Oracle и прочими марками баз данных несущественны для настройки SQL.

Полное сканирование таблицы

Основной путь доступа к таблице — это полное сканирование таблицы, то есть чтение таблицы полностью без использования индекса. На рис. 2.4 иллюстрируется этот метод в приложении к типичной таблице в Oracle.

Считыввнив нескольких блоков по 64 Кбайт

Рис. 2.4. Полное сканирование таблицы

Так как будет считана вся таблица, Oracle понимает, что следует выполнять операции физического ввода-вывода частями, размер которых больше, чем блок — в этом случае считываться будет по 64 Кбайт за раз. В результате выполняется меньшее количество объемных физических считываний, что занимает меньше времени, чем множество небольших физических считываний тех же блоков. He все поставщики баз данных следуют этому методу, однако выясняется, что этим они достигают немногого, так как дисковые подсистемы и операционные системы обычно считывают сегменты большого размера, даже если база данных запрашивает один блок. База данных может выдать много запросов на считывание небольших объемов данных, но они преобразуются на низших системных уровнях в несколько запросов объемных операций считывания, а требование небольших запросов удовлетворяется за счет кэша дисковой подсистемы. Данные считываются с первого блока до отметки заполнения, включая все встречающиеся пустые блоки. В случае, когда каждый из набора 64-килобайтовых блоков уже находится в кэше, кэширование позволяет базе данных избежать операции физического считывания нескольких блоков. База данных считывает блоки небольших и средних по размеру таблиц в кэш обычным образом, и они удаляются оттуда через несколько минут, если никакой другой запрос не обратится к ним. Кэширование небольших и средних таблиц целиком часто бывает полезным, и такие таблицы остаются в кэше надолго, если базе данных приходится часто сканировать их полностью.
Предыдущая << 1 .. 15 16 17 18 19 20 < 21 > 22 23 24 25 26 27 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100