|
Джеймс Мэдисон
Построение гибридной модели хранилища данных
(Building a Hybrid Data Warehouse Model, by James Madison)
Источник: сайт корпорации Oracle, 09 Apr 2007,
http://www.oracle.com/technology/pub/articles/madison-models.html?rssid=rss_otn_articles
Как описывается в данном примере-реализации, в некоторых случаях “смешивание” реляционной и многомерной (dimensional) моделей может быть правильным подходом к проектированию хранилища данных.
Реляционное и многомерное моделированное часто применяются отдельно, но в случае необходимости они могут успешно использоваться в одном и том же проекте. Сначала создается нормализованная реляционная модель, а затем добавляются многомерные конструкции (constructs), в основном на физическом уровне. Результат – это единая модель, которая достаточно хорошо объединяет сильные стороны “родительских” моделей: она представляет сущности (entities) и отношения (relationships) с точностью традиционной реляционной моделиl, и она же обрабатывает многомерно профильтрованные, агрегированные по факту (fact-aggregated) запросы со скоростью, сравнимой со скоростью обработки в рамках традиционной многомерной модели.
Практика была мотивом для появления этой статьи: в трех проектах по созданию хранилищ данных, в которых я работал как программист, архитектор и менеджер соответственно, я обнаруживал “поведение” данных/базы данных, которое в большей степени соответствовало гибридной комбинации многомерного и реляционного моделирования, чем одному из них.
В этой статье обсуждается гибридное проектирование и предлагается его полнофункциональная эталонная реализация-пример, которая выполняется в среде СУБД Oracle Database 10g. Этот пример содержит весь код, необходимый для построения схем баз данных, генерации данных примера, загрузки их в эти схемы, построения индексов и материализованных представлений, выполнения запросов примера, “захвата” данных во время выполнения (capture the runtimes) и формирование статистики на их основе.
Гибридная модель не является решением на все случаи жизни. Для многих проектов лучшим выбором является использование только одной из традиционных моделей или использование обоих моделей, но отдельно друг от друга с передачей данных между ними. Но если ставится цель создать единую базу данных, которая сможет хранить данные в должном образе нормализованной форме и выполнять запросы к агрегированным данным (run aggregation queries) с хорошей производительностью, то гибридная модель должна быть рассмотрена.
Бизнес-область примера
Бизнес-область примера – это страхование, используются следующие сущности:
|
Сущность |
Описание |
|
ACCOUNT |
Информация о клиенте и его взаимодействии с этой страховой компанией |
|
POLICY |
Контракт по страхованию – конкретное соглашение с клиентом |
|
VEHICLE |
Транспортное средство, принадлежащее клиенту и предмет контракта по страхованию |
|
COVERAGE |
Типы убытков, покрываемых для транспортного средства по данному контракту |
|
PREMIUM |
Ежемесячный платеж от клиента согласно данному контракту |
Примерные бизнес-вопросы, используемые для анализа производительности системы, отражая реальность бизнеса, связаны с такими ситуациями обработки данных, как: сканирование таблицы фактов для выборки множества строк, выборка очень малой части строк фактов, c ограничениями топ-таблицей, каждой таблицей, только нижними (lower) таблицами и т.д. Такого рода вопросы требуют использования не реляционных, а многомерных моделей. Вопросы, которые требуют применения реляционной модели, не рассматриваются, так как в этом случае предполагается превосходство этой модели над многомерной, например: "Покажите мне все автомашины с данным полисом."
Вопросы, используемые в данном анализе, таковы:
|
ID# |
Бизнес-вопросы для многомерной модели |
|
1 |
Какова была общая сумма премии, собираемой ежегодно (так далеко в прошлое, насколько это возможно)? |
|
2 |
Какова сумма премии, собранной в штатах Новой Англии в 2002? |
|
3 |
Сколько премии мы получили за средние риски аварий в Коннектикуте ежегодно (так далеко в прошлое, насколько это возможно)? |
|
4 |
Сколько премии мы получили по полисам с планами, управляемыми по времени (time-managed plan types) в Калифорнии в 2001? |
|
5 |
Сколько автомашин с пассажирами получили возмещение за столкновения (collision coverage) в ноябре 2003? |
|
6 |
Какова была премия за красные автомашины в Вермонте с 1000 долларов франшизы? В частности, в расчете на одного человека и по лимитам на инцидент? |
|
7 |
Какова была премия за возмещения с 1000 долларов франшизой, с лимитом в 100000 долларов на человека и с 800000 долларовым лимитом на инцидент? |
|
8 |
Какими были ежемесячные премии в 1999 году за красные автомашины с двигателями 750 cc? |
Модели
Три модели представлены на рисунках 1, 2 и 3. Гибридная модель основана на реляционной с двумя изменениями, которые следуют из практики многомерного моделирования:
(1) Создать отношение (relationship) из таблицы PREMIUM к каждой таблице в верхней части данной иерархии и
(2) Добавить временное измерение (time dimension).
Рисунок 1. Реляционная модель
Рисунок 2. Многомерная модель
Рисунок 3. Гибридная модель
Пример-реализация
В основном стандартные приемы были использованы для конвертирования этих моделей в их физические реализации в схемах баз данных. Реляционная схема была создана с применением техники нормализации, а многомерная - согласно работе Ральфа Кимбалла (Ralph Kimball). Создание гибридной модели заключалось в копировании реляционной схемы и затем создании слоя (layering) многомерных конструкций поверх ее (В Приложении "Описание файлов" перечислены наиболее важные файлы данного примера, которые включают файлы с DDL, проверкой системы (system validation), запросами (queries) и автоматизированным анализом, используемым для генерации кода примера.)
Поскольку используются только три неключевых атрибута, атрибут SIZING с типом CHAR(100) добавлен к каждой таблице, чтобы сделать длину строки (row size) более реалистической.
Некоторые параметры базы данных должны быть установлены таким образом, чтобы соединения конструкций типа звезда (star joins) могли происходить и материализованные представления (materialized views) можно было применять.
Эти важные параметры показаны ниже:
Название Значение
------------------------------ --------------------
compatible 10.2.0.1.0
optimizer_features_enable 10.2.0.1
optimizer_mode first_rows
pga_aggregate_target 83886080
query_rewrite_enabled true
query_rewrite_integrity stale_tolerated
sga_target 167772160
star_transformation_enabled true
Проверка того, что соединение конструкций осуществляется по типу звезда, производится по EXPLAIN PLAN, что подробно описано в документации по Oracle.
Все три схемы были загружены одинаковыми данными. Лучшим свидетельством правильности загрузки является то, что все три схемы выдают одни и те же ответы на запросы примера.
Объем данных, используемых для анализа, показан ниже.
OWNER TABLE_NAME NUM_ROWS AVG_ROW_LEN LAST_ANALYZED
------ ------------ ---------- ----------- -------------------
DIM ACCOUNT_DIM 2000 128 2006-01-14:19-51-56
COVERAGE_DIM 900 17 2006-01-14:19-51-57
POLICY_DIM 6000 128 2006-01-14:19-51-58
PREMIUM_FACT 1371183 23 2006-01-14:19-52-14
TIME_DIM 3600 21 2006-01-14:19-52-39
VEHICLE_DIM 24000 130 2006-01-14:19-52-39
HYB ACCOUNT 2000 128 2006-01-14:19-53-42
COVERAGE 144000 28 2006-01-14:19-53-47
POLICY 6000 142 2006-01-14:19-53-53
PREMIUM 1373463 49 2006-01-14:19-54-41
TIME_DIM 3600 21 2006-01-14:19-55-08
VEHICLE 24000 144 2006-01-14:19-55-10
REL ACCOUNT 2000 124 2006-01-14:19-39-22
COVERAGE 144288 27 2006-01-14:19-39-30
POLICY 6000 138 2006-01-14:19-39-31
PREMIUM 1389963 29 2006-01-14:19-40-08
VEHICLE 24000 139 2006-01-14:19-40-13
Цель заключалась в том, чтобы обеспечить достаточно большой объем данных для того, чтобы не позволить оптимизатору использовать такие приемы (shortcuts), как чтение целых таблиц в оперативную память вместо применения индексов и методов оптимизации, что обесценивает данный анализ. Согласно Oracle Database Data Warehousing Guide 10g Release 2 (10.2), Schema Modeling Techniques, преобразование звезда (star transformation) может не происходить, если оптимизатор обнаружит, что "таблицы слишком малы, чтобы преобразование имело смысл."
Поэтому было принято, что в данном примере фактографическая таблица должна содержать, как минимум, 1 миллион строк. Учитывая, что все планы запросов, многомерных и гибридных, сгенерированные с применением QUERIES.SQL, соответствуют критерию соединений типа звезда (star joins), использованные объемы данных, похоже, достаточны для целей данного анализа.
Число строк COVERAGE_DIM в многомерной схеме меньше, чем в таблицах DIMENSION других двух схем из-за способа представления “слабой” сущности (weak entity) в многомерной схеме.
Ниже приведены размеры пространств, занятых различными схемами:
OWNER TOTAL_SIZE
--------------- ----------------
DIM 129,499,136
HYB 244,056,064
REL 130,023,424
Так как гибридная схема является комбинацией реляционной и многомерной схем, то объем ее пространства должен быть примерно равен сумме пространств двух других минус общие элементы, что и подтверждают приведенные выше цифры.
Прогоны системы
Каждый из запросов выполнялся 21 раз и медианное значение времени выполнения было использовано как репрезентативная величина, как показано ниже.
EVENT WINNER_TIME RNR_UP_TIME LOSER_TIME
----- -------------------- -------------------- --------------------
1. DIM = 00:00:06.049 REL = 00:00:09.023 HYB = 00:00:09.644
3. DIM = 00:00:03.415 HYB = 00:00:04.938 REL = 00:00:05.428
4. DIM = 00:00:00.140 HYB = 00:00:00.190 REL = 00:00:06.990
5. HYB = 00:00:00.131 DIM = 00:00:00.651 REL = 00:00:05.418
6. DIM = 00:00:00.530 HYB = 00:00:01.392 REL = 00:00:05.478
7. DIM = 00:00:00.520 HYB = 00:00:01.572 REL = 00:00:07.9718.
DIM = 00:00:00.461 HYB = 00:00:00.731 REL = 00:00:01.882
Переходим к процентной шкале, чтобы рассматриваемые значения стали относительными, и принимая время быстрейшего выполнения за 100%, получаем такие проценты:
EVENT WINNER_OFFSET RNR_UP_OFFSET LOSER_OFFSET
----- -------------------- -------------------- --------------------
1. DIM = 100% REL = 149% HYB = 159%
2. DIM = 100% HYB = 190% REL = 193%
3. DIM = 100% HYB = 145% REL = 159%
4. DIM = 100% HYB = 136% REL = 4993%
5. HYB = 100% DIM = 497% REL = 4136%
6. DIM = 100% HYB = 263% REL = 1034%
7. DIM = 100% HYB = 302% REL = 1533%
8. DIM = 100% HYB = 159% REL = 408%
Сравнивая реляционное и многомерное
Видно, что многомерная схема превосходит реляционную при выполнении функций многомерных запросов, как сути этого эксперимента, и предоставляет базу для рассмотрения производительности гибридной схемы. Как вы можете увидеть ниже, многомерная схема постоянно превосходит по производительности реляционную, что и ожидалось.
EVENT WINNER_OFFSET RNR_UP_OFFSET LOSER_OFFSET
----- -------------------- -------------------- --------------------
1. DIM = 100% REL = 149%
2. DIM = 100% REL = 193%
3. DIM = 100% REL = 159%
4. DIM = 100% REL = 4993%
5. DIM = 497% REL = 4136%
6. DIM = 100% REL = 1034%
7. DIM = 100% REL = 1533%
8. DIM = 100% REL = 408%
В случае же запроса #4 достигается почти 50-кратное превышение! Запрос #4 – это самый предельный случай, в котором единственное (не по времени - nontime) ограничение налагается на атрибуты самой верхней (topmost) таблицы. В реляционной схеме это означает, что все таблицы ниже по иерархии должны соединяться, чтобы добраться до числовой информации – это дорогая операция. В многомерной схеме такое соединение (join) – это прямое соединение от одного измерения к таблице фактов — эффективная операция.
Гибридная vs многомерная
Будет ли гибридная схема соответствовать по производительности многомерной – это основной вопрос данной статьи. Как вы можете увидеть ниже, гибридная схема работает весьма хорошо, хотя и не так хорошо как (только) многомерная.
EVENT WINNER_OFFSET RNR_UP_OFFSET LOSER_OFFSET
----- -------------------- -------------------- --------------------
1. DIM = 100% HYB = 159%
2. DIM = 100% HYB = 190%
3. DIM = 100% HYB = 145%
4. DIM = 100% HYB = 136%
5. HYB = 100% DIM = 497%
6. DIM = 100% HYB = 263%
7. DIM = 100% HYB = 302%
8. DIM = 100% HYB = 159%
Запрос #5 – это отклонение, но для всех других запросов гибридный вариант требует от 136% до 302% времени, используемого в случае многомерной схемы. Это сразу же показывает, что есть некоторые ограничения на производительность гибридной схемы, но чтобы их понять, нужен анализ планов запросов. Обзор таких планов, зафиксированных во время выполнения, позволяет выделить три типа “поведения”:
Запросы, чьи планы идентичны и многомерном, и в гибридном случае (запросы #1, #3, #4, #8).
Запросы, чьи планы различны в обоих этих случаях (запросы #2, #6, #7).
Очень хорошее соответствие запроса гибридной схеме (запрос #5).
Идентичные планы. Вот три плана для запроса #1:
Query #1, план реляционной схемы:
SELECT STATEMENT (rows=195)
SORT GROUP BY (rows=195)
TABLE ACCESS FULL PREMIUM (rows=1377304)
Query #1, план многомерной схемы:
SELECT STATEMENT (rows=300)
SORT GROUP BY (rows=300)
HASH JOIN (rows=1372568)
TABLE ACCESS FULL TIME_DIM (rows=3600)
TABLE ACCESS FULL PREMIUM_FACT (rows=1372568)
Query #1, план гибридной схемы:
SELECT STATEMENT (rows=300)
SORT GROUP BY (rows=300)
HASH JOIN (rows=1360176)
TABLE ACCESS FULL TIME_DIM (rows=3600)
TABLE ACCESS FULL PREMIUM (rows=1360176)
Отметим, что, как и следовало ожидать, план реляционный отличается от плана многомерного. Но планы в многомерном и гибридном случае идентичны. А это показывает способность оптимизатора “заметить” многомерную природу данного запроса благодаря многомерным конструкциям гибридной схемы, что и является желательным. Планы, реляционный и многомерный, также идентичны для запросов #3, #4, and #8.
Меньшая производительность (в гибридном случае), несмотря на идентичные планы приводит к заключению, что гибридная схема медленнее просто из-за больших размеров своего пространства. Как ранее отмечено, гибридная схема требует примерно вдвое больше пространства, чем любая из двух схем. Это означает меньше строк на блок, больше тотальных чтений для любой данной операции и больше передаваемых байтов, чем для многомерной схемы. Вполне возможно, что все эти дополнительные передаваемые байты и являются причиной замедления.
Различные планы. А сейчас рассмотрим три плана для запроса #7:
Query #7, план реляционной схемы:
SELECT STATEMENT (rows=6)
SORT GROUP BY (rows=6)
HASH JOIN (rows=77)
TABLE ACCESS FULL COVERAGE (rows=800)
TABLE ACCESS FULL PREMIUM (rows=13773)
Query #7, план многомерной схемы:
SELECT STATEMENT (rows=1)
SORT GROUP BY (rows=1)
HASH JOIN (rows=1)
TABLE ACCESS BY INDEX ROWID COVERAGE_DIM (rows=6)
BITMAP CONVERSION TO ROWIDS (rows=)
BITMAP AND (rows=)
BITMAP INDEX SINGLE VALUE BX_COVERAGE_ACCD_LIMIT (rows=)
BITMAP INDEX SINGLE VALUE BX_COVERAGE_DEDUCTIBLE (rows=)
BITMAP INDEX SINGLE VALUE BX_COVERAGE_PERS_LIMIT (rows=)
TABLE ACCESS BY INDEX ROWID PREMIUM_FACT (rows=48)
BITMAP CONVERSION TO ROWIDS (rows=)
BITMAP AND (rows=)
BITMAP MERGE (rows=)
BITMAP KEY ITERATION (rows=)
TABLE ACCESS FULL TIME_DIM (rows=12)
BITMAP INDEX RANGE SCAN BX_PREMIUM_TIME (rows=)
BITMAP MERGE (rows=)
BITMAP KEY ITERATION (rows=)
TABLE ACCESS BY INDEX ROWID COVERAGE_DIM (rows=6)
BITMAP CONVERSION TO ROWIDS (rows=)
BITMAP AND (rows=)
BITMAP INDEX SINGLE VALUE BX_COVERAGE_ACCD_LIMIT (rows=)
BITMAP INDEX SINGLE VALUE BX_COVERAGE_DEDUCTIBLE (rows=)
BITMAP INDEX SINGLE VALUE BX_COVERAGE_PERS_LIMIT (rows=)
BITMAP INDEX RANGE SCAN BX_PREMIUM_COVERAGE (rows=)
Query #7, план гибридной схемы:
SELECT STATEMENT (rows=1)
LOAD AS SELECT SYS_TEMP_0FD9D697C_1278CF0 (rows=)
TABLE ACCESS BY INDEX ROWID COVERAGE (rows=6)
INDEX FULL SCAN UX_COVERAGE_COVERAGE_KEY (rows=6)
SORT GROUP BY (rows=1)
HASH JOIN (rows=1)
TABLE ACCESS FULL SYS_TEMP_0FD9D697C_1278CF0 (rows=6)
TABLE ACCESS BY INDEX ROWID PREMIUM (rows=47)
BITMAP CONVERSION TO ROWIDS (rows=)
BITMAP AND (rows=)
BITMAP MERGE (rows=)
BITMAP KEY ITERATION (rows=)
TABLE ACCESS FULL TIME_DIM (rows=12)
BITMAP INDEX RANGE SCAN BX_PREMIUM_TIME (rows=)
BITMAP MERGE (rows=)
BITMAP KEY ITERATION (rows=)
TABLE ACCESS FULL SYS_TEMP_0FD9D697C_1278CF0 (rows=1)
BITMAP INDEX RANGE SCAN BX_PREMIUM_COVERAGE (rows=)
Как и ранее, реляционный план не соответствует ни одному из двух других, но теперь не идентичны многомерный и гибридные планы. То есть, к сожалению, оптимизатор не использует преимуществ многомерного плана, даже если он возможен из-за наличия в схеме всех необходимых конструкций. Пример такой работы оптимизатора – планы для запросов #2 и #6.
Разумное объяснение этой ситуации заключается в том, что наличие реляционных конструкций в схеме в то время, когда оптимизатор выполняет многомерные запросы, заставляет его генерировать план запроса не такой эффективный, как в случае, когда в наличии только многомерные конструкции.
Важно отметить, что во всех четырех случаях использования многомерного плана на гибридной схеме он превосходит все три случая, когда к гибридной схеме применяются запросы с планом, который не является чисто многомерным. Это подчеркивает ценность использования многомерного плана всегда, когда это возможно.
Perfect alignment. Запрос #5 представляет тот уникальный случай, когда гибридная схема выигрывает, так как природа запроса очень хорошо соответствует природе гибридной схемы. А именно, запрос #5 использует таблицы VEHICLE, COVERAGE и TIME. COVERAGE – это “слабая” сущность (weak entity), и, как таковая, она содержит все идентификаторы VEHICLE в своем первичном ключе и в реляционной, и в гибридной схеме. Но в многомерной схеме все эти атрибуты VEHICLE вынесены из нее, так что измерение COVERAGE будет "чистым" измерением — чистым в том смысле, что все связи, которые оно имеет с VEHICLE, реализуются через таблицу фактов. Это делается для создания настоящей многомерной схемы, при этом разделение таблиц VEHICLE и COVERAGE в этой схеме происходит в большей степени, чем в реляционной и гибридной схемах.
Когда оптимизатор использует таблицы VEHICLE и COVERAGE в запросе #5, он должен в полной мере соединять их в случае многомерной схемы, но в гибридной и реляционной схемах он может обнаружить их уже вместе через ключ таблицы COVERAGE. То, что гибридная схема уже обладает такими конструкциями, когда они нужны оптимизатору, является одним и ее преимуществ, но, вообще-то, это не типичное преимущество. Оно проявляется только тогда, когда запрос и схема очень хорошо соответствуют друг другу, как в запросе #5.
Заключение по анализу запросов
Обобщим наши выводы: если гибридная схема очень хорошо соответствует природе запроса, то она может значительно превзойти (по производительности) многомерную, но вообще-то это не типичный случай (один из восьми). В большинстве случаев (четыре из восьми), гибридный план запроса будет идентичен многомерному, но гибридная схема будет отрабатывать медленнее, возможно, из-за количества передаваемых байтов. В некоторых случаях (три из восьми), план запроса для гибридной схемы будет другим, не оптимальным, и результат – это время выполнения, которое ощутимо больше, чем в случае многомерной схемы.
Агрегаты – материализованные представления
Как правило, агрегаты (Aggregates) используются в многомерном моделировании для повышения производительности, а материализованные представления (materialized views) - для создания агрегатов. Чтобы показать эффект агрегатов – материализованных представлений (materialized view aggregates (MVAs)) на гибридной схеме, были добавлены два таких MVA. Таблица 1 показывает, что перечисленные в самой правой колонке четыре из рассмотренных запросов могут быть переписаны с использование MVA.
| Query |
Account dim. |
Policy dim. |
Vehicle dim. |
Coverage dim. |
Time dim. |
Aggregate utilized |
| 1 |
Agg |
Agg |
|
|
Qry/Agg |
Agg_acct_pol_time |
| 2 |
Qry |
|
|
Qry |
Qry |
|
| 3 |
Qry/Agg |
Qry/Agg |
|
|
Qry/Agg |
Agg_acct_pol_time |
| 4 |
Qry/Agg |
Agg |
|
|
Qry/Agg |
Agg_acct_pol_time |
| 5 |
|
|
Qry |
Qry |
Qry |
|
| 6 |
Qry/Agg |
Qry/Agg |
Qry/Agg |
Qry/Agg |
|
Agg_acct_pol_veh_cov |
7 |
|
|
|
Qry |
Qry |
|
| 8 |
|
|
Qry |
|
Qry |
|
Таблица 1 . Агрегаты – материализованные представления (MVA) добавлены для оптимизации некоторых запросов
"Qry" отмечает, что запрос ссылается на это измерение в своей фразе WHERE, и "Agg" отмечает, что MVA ссылается на это измерение. Чтобы переписывание состоялось, "Qry" не должен быть в ячейке один.
Как и следовало ожидать, изменения в производительности в связи с применением MVA в целом положительны. Интересно, что MVA с гибридной схемой в сравнении с многомерной работают хорошо, как показано ниже:
VENT WINNER_TIME RNR_UP_TIME LOSER_TIME
----- -------------------- -------------------- --------------------
1. HYB = 00:00:00.941 DIM = 00:00:01.382 REL = 00:00:08.943
2. DIM = 00:00:04.246 REL = 00:00:08.041 HYB = 00:00:08.121
3. HYB = 00:00:00.942 DIM = 00:00:01.262 REL = 00:00:05.388
4. HYB = 00:00:00.120 DIM = 00:00:00.180 REL = 00:00:07.381
5. HYB = 00:00:00.290 DIM = 00:00:01.222 REL = 00:00:05.989
6. HYB = 00:00:00.731 DIM = 00:00:00.912 REL = 00:00:05.437
7. DIM = 00:00:00.691 HYB = 00:00:01.993 REL = 00:00:07.962
8. DIM = 00:00:00.511 HYB = 00:00:00.801 REL = 00:00:02.063
EVENT WINNER_OFFSET RNR_UP_OFFSET LOSER_OFFSET
----- -------------------- -------------------- --------------------
1. HYB = 100% DIM = 147% REL = 950%
2. DIM = 100% REL = 189% HYB = 191%
3. HYB = 100% DIM = 134% REL = 572%
4. HYB = 100% DIM = 150% REL = 6151%
5. HYB = 100% DIM = 421% REL = 2065%
6. HYB = 100% DIM = 125% REL = 744%
7. DIM = 100% HYB = 288% REL = 1152%
8. DIM = 100% HYB = 157% REL = 404%
Фактически, в 100% случаев применения агрегатов (4 из 8 запросов), гибридная схема выигрывает по производительности. Это показывает, что использование материализованных представлений является преимуществом для гибридной и многомерной схем, особенно для гибридной. Это очень важный факт, показывающий, что применение MVA в гибридной схеме позволяет достичь производительности многомерной схемы, сохраняя все реляционные отношения.
Будущие исследования и некоторые соображения
"Can" vs. "Should" (“Может” vs ”Должен”). Как уже отмечалось, мотивом для данного исследования была необходимость построения единой системы для удовлетворения требований бизнеса по оперативной (OLTP) обработке данных и поддержке принятия решений (DSS). Однако, если в проекте нужен только один из этих типов обработки данных, либо есть и деньги, и время для построения двух отдельных сред (обработки данных) с передачей данных между ними, то, возможно, лучше не применять гибридную схему.
Human understanding (Понимание людьми). В этом анализе рассматриваются аспекты реализации гибридной схемы, но одно из преимуществ многомерного проектирования – это легкость его понимания теми, кто не является экспертами в области баз данных. Но это не присуще гибридному проектированию. Более того, оно является наиболее сложным из трех рассмотренных в этой статье. Это является большим недостатком для систем, в которых опытным пользователям дается прямой доступ к базе данных.
Other physical optimization (Другая оптимизация физических структур). В данном анализе не использовалось секционирование (partitioning). Соединения двоичных индексов (bitmap join indexes) были добавлены и проанализированы, но результаты показали, что их преимущества невелики (см. код для выявления деталей). Эти и другие техники оптимизации физических структур должны быть (дополнительно) проанализированы, чтобы определить, принесут ли они преимущества гибридному проектированию, как в случае многомерного проектирования.
Особенности платформы. Эта система выполнялась на сервере с ЦП Intel Pentium и ОС Windows XP. Были протестированы три такие платформы. Объем оперативной памяти (RAM) менялся от 256 Мбайт до 1 Гбайта. Другие платформы могут работать быстрее или медленнее в целом, но отличия платформ могут также приводить к изменению производительности схем относительно друг друга. Такая возможность тем более вероятна, так как СУБД Oracle способна учитывать состояние ресурсов платформы и адаптировать планы (запросов) соответствующим образом.
Заключение
В общем, приведенные результаты показывают, что идея комбинирования реляционного и многомерного имеет смысл, хотя и с некоторыми проблемами. Но заметим – совершенство не достижимо. Применяемая единолично реляционная схема не может достигнуть производительности многомерной; а многомерная схема не может эффективно представлять отношения. У каждой из трех схем есть свои ограничения. С учетом этого, небольшое снижение производительности, которое обусловлено большим размером строк и возрастанием сложности физических структур, - это относительно небольшая плата за такое преимущество, как возможность иметь одновременно полное реляционное представление и намного улучшенную производительность.
Джеймс Мэдисон (James Madison) работает в области ИТ с начала 1990-х годов и большую часть этого времени с СУБД Oracle. Он приветствует ваши отклики, направленные по адресу madjim@bigfoot.com.
Приложение: Описания файлов
В этом примере используется несколько десятков файлов-источников и генерируется девять выходных файлов во время прогонов. Ниже перечислены только самые важные или потенциально способные ввести в заблуждение файлы и директории. Менее важные не перечислены, но с ними легко можно легко разобраться по коду и выходу.
|
File/Pattern |
Назначение |
|
go.cmd |
Основная точка входа в систему. Этот файл запускает все. Его 13 переменных среды определяют поведение прогона; просмотрите их тщательно. За исключением нескольких маленьких утилит весь код системы связан с этим корнем root |
|
*master*.* |
Этот код использует четвертую схему, "master" для построения и выполнения трех основных |
|
build*.* |
DDL для схем |
|
validation.sql |
Проверяет, что построение схем и загрузка данных сделаны правильно |
|
queries.sql |
Запускает запросы |
|
q????.sql |
Это восемь запросов, используемых со всеми тремя моделями. Они представлены таким образом, чтобы их можно было вызывать во всех трех схемах как для прогона, так и для анализа планов. Через файл queries.sql выполняется вся необходимая параметризация и настройка (parameterization and sequencing) |
|
analysis.sql |
Выполняет анализ. Формирует выходные таблицы во время выполнения (runtime output tables), shown in the figures |
|
agg_*.sql |
Строит агрегаты Builds the aggregates |
|
bitmapjoin.sql |
Строит битмэп-индексы для соединений (bitmap join indexes). Они не обсуждены выше, но здесь доступны |
|
runs |
Директория, в которую помещаются сгенерированные файлы |
|
runs\base_*.txt |
Три файла с проверкой, выходом запросов и анализом для схем без материализованных представлений иди битмэп-индексов для соединений |
|
runs\mv_*.txt |
Те же три файла, но с материализованными представлениями |
|
runs\bmji_*.txt |
Те же три файла, но с двоичными индексами для соединений |
|
oracle_config |
Директория с файлами для выполнения некоторой системной установки (system setup). Ваша система изменится. |
|
