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

 

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

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

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


Если вам нравится идея таблиц с индексной организацией, но вы работаете не в Oracle, то вы можете получить практически те же преимущества по времени считывания, построив обычные индексы со всеми столбцами, необходимыми для часто выполняемых запросов. Этой стратегии можно следовать и в Oracle, если вы хотите для большей компактности оставить большие, но редко используемые столбцы за пределами индекса.

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

Однотабличные кластеры

Сами по себе однотабличные кластеры используются дольше, чем их близкие родственники — таблицы с индексной организацией. Однотабличный кластер физически организует строки таблицы в определенном порядке в зависимости от какого-либо ключевого значения. Когда принцип отбора строк хорошо коррелирует с использованным типом сортировки, такая организация доступа к данным улучшает результативность за счет того, что горячие строки находятся рядом. Ho существует устойчивая проблема, которая заключается в том, что трудно сохранять таблицу отсортированной, если только строки не прибывают в нужном порядке. (А если они прибывают уже отсортированными, то кластер не требуется, естественное упорядочение таблицы будет прекрасно работать.) Если же строки прибывают неотсортированными, база данных должна оставлять пространство для размещения новых строк в подходящем месте, иначе придется периодически реорганизовывать строки. Реорганизация дорога, а резервирование пространства приводит к потере памяти и серьезно подрывает эффективность кэша. Резюмируя, могу сказать, что мне никогда не требовались однотабличные кластеры для повышения производительности, и я ожидаю, что вам они также будут не нужны.
42

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

Многотабличные кластеры

Как и однотабличные кластеры, многотабличные кластеры предварительно отсортированы по какому-либо ключу. В случае многотабличных кластеров в одном блоке находятся строки из нескольких таблиц, соединенные на основе этого ключа, что делает операцию соединения таблиц исключительно быстрой. Если вы не обращаетесь одновременно ко всем кластеризованным таблицам, то строки из другой таблицы в считываемом блоке только мешают, поэтому ключевым вопросом является вопрос о том, как часто вы соединяете различные таблицы в запросах приложений. Если у вас есть две или более постоянно соединенные таблицы, которые однозначно связаны друг с другом (то есть эти таблицы совместно используют уникальный ключ), многотабличные кластеры должны работать достаточно хорошо. Ho, в таком случае, зачем вообще разделять эти таблицы? Просто поместите расширенное множество всех столбцов в одну таблицу. Чаще всего между главной и детальной таблицей существует отношение «один ко многим», как, например, между таблицами Orders и OrderJDetail. Здесь проблемой становится изменчивость отношений «один ко многим». В кластерном блоке вы должны предусмотреть возможность размещения множества деталей, но в то же время избежать излишней траты пространства в случае, когда оказывается, что существует лишь одна детальная строка (или не существует вообще ни одной). Как и с однотабличными кластерами, это приводит к проблеме компромисса между потерянным пространством и затратами на реорганизацию. И, как и однотабличные кластеры, многотабличные кластеры мне никогда не требовались для улучшения производительности, и вам, вероятно, они также не пригодятся.

Таблицы с разбиениями

Таблицы с разбиениями — это еще одна особенность Oracle, возникшая из-за необходимости поддерживать действительно огромные таблицы. Представьте, что у вас есть система отслеживания сделок для крупного брокера. Вероятно, у вас есть обширная история отдельных сделок, но вы редко интересуетесь сделками, которые произошли больше года назад. Вы хотите иметь эффективный и непрерывный доступ к недавним сделкам, а также инструменты архивирования самых старых сделок без нарушения целостности системы.

Таблицы с разбиениями выглядят как набор подтаблиц, или разбиений, которые можно поддерживать независимо друг от друга. Например, одно из разбиений можно переключить в автономный режим, не нарушая доступа к остальным. Операторы запросов должны явно упоминать только имя таблицы с разбиениями, представляющей весь набор. Разбиения организованы в соответствии с некоторым классифицирующим условием, которое определяет, какому разбиению принадлежат какие строки. Это классифицирующее условие часто использует дату, например Trade_Date в нашем примере, согласно которому каждое разбиение охватывает значительный диапазон времени, например месяц или год. Если условия запроса исключают некоторые разбиения, запрос может вовсе не обращаться к ним. Он может быть выполнен, даже если эти разбиения находятся в полностью автономном режиме. У таблиц с разбиением есть огромные преимущества в простоте управления, но за всю свою практику я ни разу не использовал их для решения исключительно проблем производительности. Я ожидаю, что они могут быть полезными
Предыдущая << 1 .. 14 15 16 17 18 19 < 20 > 21 22 23 24 25 26 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100