Редкие объекты базы данных

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

Таблицы с индексной организацией

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

Рассмотрите возможность использования таблиц с индексной организацией в следующих условиях.

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

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

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

Редкие объекты базы данных 41

ких случаях оба этих фактора будут говорить в пользу таблиц с индексной организацией.

Вы редко добавляете, удаляете и модифицируете строки. Обычные таблицы лучше обрабатывают частое изменение данных, чем таблицы с индексной организацией. В приложениях оперативной обработки транзакций (Online Transaction Processing, OLTP) данные в больших таблицах изменяются часто; в противном случае они бы слишком разрослись. Это аргумент против больших таблиц с индексной организацией в среде OLTP.

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

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

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

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

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

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

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

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

Таблицы с разбиениями выглядят как набор подтаблиц, или разбиений, которые можно поддерживать независимо друг от друга. Например, одно из разбиений можно переключить в автономный режим, не нарушая доступа к остальным. Операторы запросов должны явно упоминать только имя таблицы с разбиениями, представляющей весь набор. Разбиения организованы в соответствии с некоторым luiac-сифицирующим условием, которое определяет, какому разбиению принадлежат какие строки. Это классифицирующее условие часто использует дату, например Trade Date в нашем примере, согласно которому каждое разбиение охватывает значительный диапазон времени, например месяц или год. Если условия запроса ис-гшючают некоторые разбиения, запрос может вовсе не обращаться к ним. Он может быть выполнен, даже если эти разбиения находятся в полностью автономном режиме. У таблиц с разбиением есть огромные преимущества в простоте управления, но за всю свою практику я ни разу не использовал их для решения исгшючи-тельно проблем производительности. Я ожидаю, что они могут быть полезными