Taming Data Giants
Stephen Brobst, a founder and managing partner at Strategic Technologies & Systems
E-mail:
Owen Roberston, a senior DBA at Tanning Technoology Corp.
E-mail:
В статье приводится обзор критических проблем, связанных с
администрированием сверхбольших баз данных (VLDB - Vary Large
DataBases), таких как управление производительностью и достижение
высокого уровня доступности. Кроме того, обсуждаются роль
стратегии индексации, оптимизаторы запросов, параллельная
обработка, масштабируемость, трехуровневые архитектуры. В
заключение описывается, как некоторые лидирующие РСУБД
поддерживают работу со сверхбольшими базами данных.
Единственным способом эффективного управления таблицами,
содержащими миллионы строк, является использование какой-либо
формы разделения данных. Для разделения используются три основных
метода: разделение на основе хэширования, разделение в
соответствии с диапазонами значений ключа и циклическое
разделение (round-robin). При использовании разделения на основе
хэширования DBA (DataBase Administrator) должен выбрать один или
несколько столбцов из каждой таблицы для использования в качестве
исходных данных для хэш-функции, результирующее значение которой
определяет, в каком разделе базы данных будет храниться данная
строка таблицы. Хорошая хэш-функция должна быть эффективной и
удовлетворительно балансирующей распределение данных между
разделами. При разделении данных в соответствии с диапазонами
значений ключа строки данных таблицы помещаются в раздел базы
данных исходя из заранее приписанного к этому разделу диапазону
значений ключа. В некоторых базах данных требуется, чтобы такого
рода разделение выполнялось только для первичного (уникального)
ключа. Для больших таблиц в качестве ключа разделения часто
используется столбец временной метки. Циклическое разделение
данных организуется самым простым образом - все разделы
связываются в циклически связанную цепочку, и следующая строка
таблицы помещается в следующий раздел.
Основным преимуществом
циклического разделения является эффективное распределение
данных по разделам при выполнении массивной загрузки большой
таблицы.
В большинстве СУБД, ориентированных на поддержку систем класса
DSS (Decision Support System - системы поддержки принятия
решений), используется разделение на основе хэширования,
обеспечивающее равномерное распределение данных между разделами и
облегчающее выполнение соединений, если две таблицы разделены по
одному и тому же ключу (конечно, в этом случае строки обеих
таблиц с одинаковым значением хэш-функции от значения ключа
должны храниться в одном и том же разделе). В СУБД разряда
"shared-nothing" (такие системы основываются на
несимметричных мультипроцессорных архитектурах, в которых
процессоры не имеют совместно используемых ресурсов основной и
внешней памяти) соединения совместно разделенных таблиц
выполняются существенно быстрее, чем при применении других
способов разделения. Реально, если соединяются две таблицы, не
являющиеся совместно разделенными, используется динамическое
перераспределение строк соединяемых таблиц. Стоимость
перераспределения различна для разных серверов баз данных и
сильно зависит от размеров таблиц. В системах типа Extended
Parallel Server (XPS) компании Informix Software Inc., в которых
обеспечивается очень высокая эффективность коммуникаций между
узлами, соединения не совместно разделенных таблиц выполняются
всего на 10% медленнее, чем если бы они были совместно
разделенными. Однако в системах типа shared-nothing, не
обеспечивающих должную оптимизацию перераспределений, не
совместно разделенные таблицы соединяются более чем в два раза
медленнее. Разделение на основе хэширования применяется в
системах Teradata (NCR Corp.), DB2/6000 Parallel Edition (IBM
Corp.), MPP (Sybase Inc.). В системах Non-Stop SQL (Tandem
Computers Inc.) и DB2 V.4 для MVS, которые ориентированы на
эффективную поддержку мощных систем класса OLTP (On-Line
Transaction Processing - оперативная обработка транзакций), для
больших таблиц применяется разделение по диапазонам ключа. В
сервере баз данных компании Informix можно использовать все три
вида разделения. Компания Oracle не будет поддерживать разделения
таблиц до выпуска восьмой версии, однако уже в версии 7.3
существует возможность моделировать разделение путем создания
отдельной таблицы для каждого раздела и определения
представления, в котором все эти таблицы объединяются.
Используется специально разработанная техника оптимизации
запросов, адресованных к подобным представлениям.
Масштабируемость СУБД, ориентированных на OLTP-приложения
продолжает оставаться ограниченной, хотя, например, сервер Oracle
7.3 продемонстрировал хорошие возможности масштабируемости на
симметричном мультипроцессоре Cray Research 6400. Ограниченность
масштабируемости связана с использованием одного экземпляра базы
данных и соответствующим наличием критических участков в работе
сервера (например, при сериализации транзакций с помощью
синхронизационных блокировок). Одним из наиболее существенных
нововведений в Oracle 7.3 было применение нескольких списков
свободных блоков с целью снижения уровня конкуренции за этот
ресурс.
В отличие от реализаций распределенных баз данных, в которых
каждый экземпляр базы данных является относительно независимым, в
реализациях баз данных с несколькими экземплярами (multiple
database instances), таких как Oracle Parallel Server или
Informix XPS, все экземпляры представляют единый образ базы
данных. Для организации баз данных с несколькими экземплярами
применяются архитектуры с разделением (shared-everything) и без
разделения (shared-nothing) ресурсов. В архитектурах с
разделением ресурсов для каждого экземпляра базы данных доступен
любой блок базы данных; разделение данных не зависит от наличия
нескольких экземляров базы данных, хотя в некоторых реализациях
допускается связь между экземплярами базы данных и разделами
таблиц. В реализациях без разделения ресурсов экземпляры базы
данных явно привязываются к разделам таблиц.
Обращения к блокам
раздела можно выполнять только в том экземпляре базы данных, к
которому приписан раздел.
При интенсивной загрузке в режиме OLTP проблемой архитектур баз
данных с разделением ресурсов является необходимость поддержки
когерентности буферных кэшей разных экземпляров базы данных.
Приходится использовать специальные блокировки для изменяемых
разделяемых блоков. Если один экземпляр хочет прочитать или
изменить блок данных, который был изменен в буферном кэше другого
экземпляра, то наиболее свежая версия блока должна быть
вытолкнута из буфера второго экземпляра и сделана доступной для
первого экземпляра. В случае сильно изменчивой базы данных, что
типично для OLTP-приложений, механизм поддержания когерентности
кэшей приводит к борьбе экземпляров за часто изменяемые блоки.
Постоянно возникающая потребность в выталкивании содержимого
блока из буферов приводит к тому, что при доступе к такому блоку
экземпляры базы данных работают со скоростью диска, которая на
три порядка меньше скорости устройств основной памяти.
Решением, которое позволяет добиться требуемого уровня
производительности реализаций баз данных с разделением ресурсов,
является использование трехуровневых архитектур приложений.
Распространенные двухуровневые конфигурации (сервер баз данных и
рабочие станции пользователей) не масштабируются к объемам
информации, характерным для VLDB. В трехуровневой архитектуре
появляется промежуточный уровень, в основе которого обычно
находятся мониторы транзакций. Мониторы транзакций Tuxedo (BEA
Systems Inc.) и Encina (Transarc Corp., теперь эта компания
принадлежит IBM) доминируют на рынке UNIX-систем; CICS - на рынке
MVS. Использование надежного промежуточного программного
обеспечения дает много преимуществ. Прежде всего, логика
бизнес-приложений явно отделяется от уровней представления и
доступа к базе данных. Проблема доступа к часто изменяемым блокам
решается за счет явного использования средств маршрутизации в
зависимости от данных (Data-Dependent Routing - DDR).
Такие
средства поддерживаются в большинстве мониторов транзакций для
осмысленной маршрутизации транзакций к конкретным экземплярам
базы данных. Трехуровневая архитектура обеспечивает высокий
уровень масштабируемости приложений, поскольку мониторы
транзакций обеспечивают возможности подключения к базе данных
гораздо более эффективно, чем в двухуровневой модели. Наконец,
использование мониторов транзакций позволяет повысить уровень
доступности баз данных.
В системах без разделения ресурсов отсутствует проблема доступа к
часто изменяемым блокам. Однако при использовании таких систем в
режиме OLTP возникает другая проблема. В большинстве реализаций
индексные структуры являются локальными для разделов. Индексы,
указывающие на строки раздела таблицы управляются одним
экземпляром базы данных. С одной стороны это упрощает реализацию,
но с другой стороны - вызывает трудности с масштабированием
масштабных OLTP-приложений. В случае, когда транзакция производит
сильно селективный индексный доступ к разделенной таблице, а
индексный столбец не тот, по которому производилось разделение,
СУБД не знает, в каком разделе содержатся желаемые строки.
Приходится адресовать запрос ко всем разделам и использовать их
локальные индексные структуры. Понятно, что использование
широковещательного стиля выполнения запроса приводит к утрате
масштабируемости, поскольку сколько бы экземпляров базы данных не
добавлялось к системе, все они будут участвовать в выполнении
транзакции. Заметим, что локальная индексация вполне хорошо
работает в режиме DSS, поскольку в этих системах запросы обычно
не слишком селективны, и накладные расходы на широковещание
допустимы. Среди систем без разделения ресурсов только Non-Stop
SQL демонстрирует хорошую масштабируемость в режиме OLTP.
Ключем к достижению масштабируемости в режиме OLTP систем без
разделяемых ресурсов является использование глобальных индексных
структур, обеспечивающих глобальный доступ к блокам данных вне
зависимости от того, к каким экземплярам базы данных относятся
эти блоки. Индекс должен допускать наличие указателей (логических
или физических) на блоки данных, находящиеся под управлением
экземпляров базы данных, отличные от экземпляра, которому
принадлежит индекс. Конечно, для обеспечения масштабируемости и
управляемости индексами для очень больших таблиц эти индексы
должны сами быть разделенными (обычно применяется схема
диапазонов значений ключа), но разделение глобального индекса
должно выполняться в соответствии с его столбцами. Наличие
глобального индекса устраняет потребность в широковещательных
запросах. Глобальные индексы обеспечивают возможность
масштабирования системы, ориентированной на OLTP-системы, однако
в режиме DSS локальные индексы могут оказаться более
эффективными. Есть основания рассчитывать, что в будущих системах
будут поддерживаться обе схемы индексации.
В системах класса OLTP оказывается достаточным использовать
оптимизацию запросов, основанную на правилах, или упрощенную
оптимизацию, основанную на оценках. Однако в системах класса DSS
при наличии сложных и непредсказуемых запросов качество
оптимизатора, основанного на оценках, становится критическим
фактором. Компания Oracle впервые применила этот подход к
оптимизации запросов в версии 7.0 (до этого оптимизация
основывалась на использовании правил). В версии 7.3 оптимизатор
существенно усовершенствован. Внедрен набор стратегий
оптимизации, позволяющих использовать параллелизм для ускорения
выполнения отдельных запросов. При оценке стоимости плана запроса
используются гистограммные статистики, характеризующие истинное
распределение значений столбцов. В версии Oracle8 ожидается
появление дополнительных возможностей оптимизации. Компания IBM
собирается внедрить стратегии оценочной оптимизации,
разработанные в рамках проекта Starburst, в реализации DB2 как
для MVS, так и для UNIX. Ожидается, что это произойдет в первой
половине 1997 г. с выпуском продукта Common Server. Сервер XPS
компании Informix обладает очень высокой производительностью
благодаря эффективной реализации алгоритма соединения на основе
хэширования с возможностями распараллеливания. Oracle внедрил
алгоритм хэширования с соединением в версию 7.3, другие компании
собираются скоро это сделать. В СУБД компании Red Brick Systems
Inc. используются стратегии оптимизации, специально
ориентированные на звезднообразную схему организации баз данных.
Благодаря продуманному применению техники индексации и
оптимизации для специфических для DSS запросов, во многих случаях
продукт демонстрирует производительность, на порядок
превосходящую производительность реляционных систем. В продукте
Sybase IQ применяется аналогичный подход с комбинацией побитовой
индексации и разумного разделения таблиц.
Координаты компаний:
Cray Research Inc. (Silicon Graphics Company):
IBM Corp.:
Informix Software Inc.:
NCR Corp.:
Oracle Corp.:
Sybase Inc.:
Tandem Computers Inc.:
