Цели распределенных баз данных

1. Локальная независимость – узлы в распределенной системе должны быть независимы или атомарны, т.е. все операции на узле контролируются этим узлом. Никакой узел X не должен зависеть от некоторого узла Y, чтобы успешно функционировать. Локальная независимость также означает, что локальные данные имеют локальную принадлежность, управление и учет. Все данные «реально» принадлежат одной и той же локальной базе данных, даже если доступ к ней осуществляется с других, удаленных узлов. В действительно локальная независимость не вполне достижимы, поэтому говорят, что узлы должны быть независимыми в максимально возможной степени.

2. Отсутствие опоры на центральный узел предполагает, что все узлы в распределенной системе должны рассматриваться как равные.

3. Непрерывное функционирование – в общем случае преимущество распределенных систем состоит в том, что они должны предоставлять более высокую степень надежности (высокая степень вероятности работоспособности системы в любой заданный момент) и доступности (высокая степень вероятности того, что система окажется работоспособной и будет непрерывно функционировать).

4. Независимость от расположения – пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.

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

6. Независимость от репликации – система поддерживает репликацию данных, если данная хранимая переменная-отношение (фрагмент переменной-отношения) может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах.

7. Обработка распределенных запросов – обработка запросов, к различным узлам распределенной базы данных.

8. Управление распределенными транзакциями – оба аспекта управления транзакциями, рассмотренные нами ранее (а именно, управление восстановлением и управление параллельностью) имеют расширенную трактовку в среде распределенных систем. В распределенной системе отдельная транзакция может включать в себя выполнение кода на многих узлах, поэтому говорят, что каждая транзакция содержит нескольких агентов (процесс, который выполняется в рамках транзакции на определенном узле). Для обеспечения атомарности транзакций используется протокол двухфазной фиксации, а управление параллельностью в большинстве современных систем основано на механизме блокирования.

9. Аппаратная независимость.

10. Независимость от ОС.

11. Независимость от сети.

12. Независимость от типа СУБД – необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс и совсем необязательно, чтобы это были копии одной и той же СУБД.

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

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

"База данных -> Средство Анализа"

На практике в большинстве случаев такие системы манипулируют оперативными данными и относятся к классу OLTP-систем (Online Transaction Processing), в которых отсутствуют средства обработки исторических данных.

Традиционные реляционные базы данных в каждый момент времени хранят «мгновенный снимок» данных, соответствующий модели некоторой предметной области. Любое изменение данных в момент времени t приводит к недоступности их значений в предыдущий момент времени. В связи с этим для хранения исторических данных приходится разрабатывать и использовать использовать какие-либо дополнительные программные средства, что весьма проблематично при использовании традиционных OLTP-систем.(я)

Концепция Хранилищ данных (ХД- DataWarehouse) предлагает изменить эту схему, добавив еще одно звено, в котором концентрируется решение части указанных проблем.

"База данных -> Объекты Хранилища данных <-> Средство Анализа"

Существуют различные подходы к представлению исторических данных, среди которых: использование Хранилищ данных (DataWarehouse) и OLAP-систем (Online Analysis Processing - систем оперативной аналитической обработки) на основе многомерных СУБД (MOLAP), реляционных СУБД (ROLAP) или гибридных систем (HOLAP), а также использование объектно-ориентированных СУБД и СУБД «не первой нормальной формы» (NFNF, NF2).

* Хранилище данных

Это понятие является, наверное, наиболее широко трактуемым. для начала приведем ставшее уже классическим определение Б.Инмона: Хранилище данных (Data Warehouse) это - "предметно-ориентированный, интегрированный, неизменяемый, поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений". Достаточно часто под ХД подразумевается не только набор данных, но также и вся технология использования ХД.

* Витрина данных

Это понятие возникло несколько позже термина ХД, поэтому в некоторых источниках оно слито с понятием ХД. В данном материале под Витриной (или Киоском) данных (Data Mart) мы будем понимать сравнительно небольшое ХД, сконструированное для использования неким подразделением с одним существенным отличием от ХД - в Витрине данных конечный пользователь может создавать свои собственные структуры данных. Есть еще одна особенность у Витрин данных (ВД) - источником для большинства хранящихся там данных является ХД. Это приводит к тому, что при создании ВД редко используется инструменты по очистке, денормализации и унификации данных.

* Технология ХД

Под этим термином будем понимать технологию использования всех объектов связанных с ХД, как то:

• Хранилища данных
• Витрины данных
• Программное обеспечение

* Средства OLAP (Online Analysis Processing)

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

• MOLAP(multidimensional OLAP) - для работы с многомерными БД (Multidimensional Data Base или MDDB)

По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения "предприятие - подразделение - отдел - служащий". Измерение Время может даже включать два направления консолидации - "год - квартал - месяц - день" и "неделя - день", поскольку счет времени по месяцам и по неделям несовместим. В этом случае становится возможным произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим

• ROLAP(relational OLAP) - для работы с реляционными БД.

Денормализуется, схемы звезда, снежинка.

Помимо этих двух типов хранения данных, есть ещё один:

• HOLAP(hybrid OLAP) – является комбинацией MOLAP и ROLAP. Позволяет хранить одну часть данных в хранилище MOLAP, а другую в хранилище ROLAP, получая выгоду от обоих типов хранилищ.

Свойства хранилищ данных

Уильям Инмон, считающийся основателем нового направления развития технологии БД, дал классическое определение информационного хранилища в 1990 г. Он охарактеризовал его как специальным образом администрируемую базу данных, содержимое которой имеет следующие свойства:

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

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

Предметная ориентация позволяет также хранить в ХД только те данные, которые необходимы для Средств Анализа, что существенно сокращает затраты на носители информации и повышает безопасность доступа к данным.

Интеграция

Данные в информационное хранилище поступают из различных источников, где они могут иметь разные имена, атрибуты, единицы измерения и способы кодировки. После загрузки в DW данные очищаются от индивидуальных признаков, т. е. как бы приводятся к общему знаменателю. С этого момента они представляются пользователю в виде единого информационного пространства.

Если в четырех разных приложениях пол клиента кодировался четырьмя различными способами, то в информационном хранилище будет использована единая для всех данных схема кодировки (например, f,m).

Инвариантность во времени

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

В OLTP-системах информация часто модифицируется как результат выполнения каких-либо транзакций. Временная инвариантность данных в DW достигается за счет введения полей с атрибутом "время" (день, неделя, месяц) в ключи таблиц. В результате записи в таблицах DW никогда не изменяются, представляя собой снимки данных, сделанные в определенные отрезки времени. В DW содержатся как бы моментальные снимки данных. Каждый элемент в своем ключе явно или косвенно хранит временной параметр, например день, месяц или год.

Неизменяемость

В OLTP-системах записи могут регулярно добавляться, удаляться и редактироваться. В DW-системах, как следует из требования временной инвариантности, однажды загруженные данные теоретически никогда не меняются. По отношению к ним возможны только две операции: начальная загрузка и чтение (доступ). Это и определяет специфику проектирования структуры базы данных для DW. Если при создании OLTP-систем разработчики должны учитывать такие моменты, как откаты транзакций после сбоя сервера, борьба с взаимными блокировками процессов (deadlocks), сохранение целостности данных, то для DW данные проблемы не столь актуальны - перед разработчиками стоят другие задачи, связанные, например, с обеспечением высокой скорости доступа к данным.

Сеть супермаркетов Hyundai

Было реализовано Хранилище данных, дающее оперативную информацию и возможность выполнять сложные детализированные запросы. Оно выполнено на базе многопроцессорных серверов фирмы NCR (WorldMark 4800 и WorldMark 4400) и дискового массива EMC объемом 830 Гб.

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

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

Корпорация NCR

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

На сегодняшний день Хранилище данных - это централизованный репозиторий, содержащий интегрированные данные по всем видам деятельности NCR. Здесь хранятся сведения о заказах, счетах, коммерческих предложениях компании, о выполнении технического обслуживания, а также каталоги товаров, финансовая и кадровая информация. Более 2 500 внутренних и 8 000 внешних пользователей осуществляют доступ к Хранилищу через защищенный web-портал.

В результате NCR удалось существенно повысить производительность во всех подразделениях.
В частности, учетный цикл при составлении финансовой отчетности сократился с 14 до 6 дней. Теперь финансовый аналитик может с легкостью переходить от сводных данных к детализированным. За счет повышения эффективности и централизации управления удалось сократить расходы на финансовые операции на 50 миллионов в год. Кроме того, глобальное управление ресурсами позволило сэкономить 10 миллионов долларов: были снижены расходы на поддержание товарно-материальных запасов. Компания стремиться получать данные от своих отделений по всему миру три раза в день, что приближает ее к работе в режиме реального времени.

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

Не осталась в стороне и служба поддержки клиентов. Теперь заказчики могут получить дополнительные услуги, обращаясь к Хранилищу через Web. Пользователям предоставляется возможность проверять текущий статус обслуживания, генерировать отчеты о том, как выполняются "соглашения об уровне сервиса" (SLA - Service Level Agreement). До внедрения новой технологии сотрудники NCR в ручную собирали эту информацию и распространяли по клиентам.