Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Базы данных. Лекции по курсу. В 4 частях. Ч.1. Учебное пособие
.pdf
Рис. 19. План выполнения SQL-запроса
Рис. 20. Операции при выполнении SQL-запроса
Выполним вертикальную фрагментацию таблицы books на две таблицы
books_main_info и books_description.
Будем считать, что количество строк в таблице
books_main_info со-
ставляет 200 000, размер одной строки ~145 байт, общий размер таблицы 35 Мбайт. Таблица
books_description содержит такое же количе-
ство строк, размер одной строки 1353 байта, общий размер таблицы
306 Мбайт.
Перепишем исходный SQL-запрос таким образом, чтобы он работал с фрагментированной таблицей
books:
select p.name, b.cnt
from publishers p
(select publisher_id, count (*) cnt
from books_main_info
group by publisher_id
) b
where b.publisher_id = p.id
51
Ниже приведены план SQL-запроса, в котором используется вертикально фрагментированная таблица
books (рис. 21), и последователь-
ность выполняемых операций (рис. 22). Стоимость плана составляет
8395 условных единиц, время выполнения запроса ~ 216 мс.
Таким образом, вертикальная фрагментация более чем в пять раз
позволила уменьшить стоимость плана выполнения SQL-запроса и в
3,5 раза уменьшить время его выполнения.
Рис. 21. План выполнения SQL-запроса с вертикально фрагментированной
таблицей books
Рис. 22. Операции при выполнении SQL-запроса с вертикально
фрагментированной таблицей books
Подводя итог, следует отметить, что язык SQL имеет как сильные,
так и слабые стороны.
52
К достоинствам следует отнести:
повсеместную распространенность;
быстрое обучение в простых случаях;
связывание с различными языками программирования;
поддержка стандартов ODBC и JDBC;
высокое качество реализации языка SQL в компиляторах.
Среди недостатков надо отметить:
неполное соответствие языка реляционной модели данных (воз-
можное наличие дубликатов, необязательность первичного ключа,
возможность упорядочения результатов);
недостаточно продуманный механизм неопределенных зна-
чений;
сложность формулировок и громоздкость для сложных запросов.
ВОПРОСЫ
1. Что входит в стандарт языка SQL3?
2. Что входит в международный стандарт SQL:2003?
3. От чего зависит скорость выполнения SQL-запроса?
4. Какие приемы для повышения эффективности следует использо-
вать при написании SQL-запросов?
5. Какого правила следует придерживаться при соединении таблиц
в запросах с соединениями?
6. Каковы общие рекомендации к порядку предпочтения конструк-
ций SQL-запроса (соединение
, коррелированный, некоррелированный
запрос)?
7. Почему для фильтрации записей следует использовать конструк-
цию
where, а не having?
8. Что такое
rowid-столбец?
9. Что такое рефакторинг?
10. Какова последовательность действий при выполнении SQL-
запроса посредством программы PgAdmin?
11. Какова последовательность действий при выполнении SQL-
запроса посредством программы phpPgAdmin?
12. Что такое план выполнения запроса?
53
13. Какие характеристики анализирует сервер баз данных при вы-
боре оптимального плана выполнения запроса?
14. Как пользователь может получить план выполнения запроса?
15. Что такое индексирование?
16. Каким SQL-оператором создается индекс таблицы?
17. Как выполняется горизонтальная фрагментация таблиц?
18. Как выполняется вертикальная фрагментация таблиц?
19. Каковы сильные стороны языка SQL?
20. Каковы слабые стороны языка SQL?
54
3. РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ
Под распределенной базой данных (Distributed DataBase – DDB)
обычно подразумевают множество взаимосвязанных баз данных, расположенных на различных узлах сети компьютеров и, возможно,
управляемых различными СУБД. Распределенная база данных выглядит с точки зрения пользователей и прикладных программ как обычная
локальная.
Система управления DDB – программная система, позволяющая
управлять базой данных таким образом, чтобы ее распределенность
была прозрачна для пользователей.
База данных физически распределяется по узлам данных при помощи двух инструментов: фрагментации и репликации (синоним термина репликация – тиражирование). Отношения реляционной базы
данных могут быть фрагментированы на горизонтальные или вертикальные разделы. Горизонтальная фрагментация реализуется при помощи операции селекции, которая направляет каждый кортеж отношения
в один из разделов, руководствуясь предикатом фрагментации.
Например, для отношения
ответствии с территориальным распределением рабочих мест сотрудников.
При вертикальной фрагментации отношение делится на разделы при
помощи операции проекции. Например, один раздел отношения
может содержать поля
рес_сотрудника,
(рис. 23).
тель
Цель фрагментации состоит в том, что, во-первых, данные приближаются к месту их наиболее интенсивного использования, что потенциально снижает затраты на их пересылку, и, во-вторых, уменьшаются
а другой – поля Номер_сотрудника, Оклад, Руководи-
Сотрудники возможна фрагментация в со-
Employee
Номер_сотрудника, ФИО_сотрудника, Ад-
55
размеры отношений, участвующих в запросах. Если отношения содержат миллионы записей, это очень существенно уменьшает время обработки.
Рис. 23. Горизонтальная и вертикальная фрагментация
Вторым инструментом обеспечения распределенности является тиражирование данных с учетом спроса на доступ к ним. В различных
узлах сети могут быть приложения, выполняющие одинаковые функции. В таком случае более эффективно будет поддерживать копии данных на всех узлах, чем непрерывно пересылать данные между узлами
(рис. 24).
Рис. 24. Тиражирование данных
Следует отметить сложность проблемы тиражирования: необходимо решить, что, когда и как тиражировать. Существуют различные
схемы тиражирования, например, в случае банковской системы популярной схемой является схема центр-филиалы.
56
3.1. СВОЙСТВА РАСПРЕДЕЛЕННОЙ БАЗЫ ДАННЫХ
В свое время К. Дэйт (C.J. Date) определил 12 свойств (качеств)
идеальной распределенной базы данных.
Локальная автономия (local autonomy).
Независимость узлов (no reliance on central site).
Непрерывные операции (continuous operation).
Обработка распределенных транзакций (distributed transaction
processing).
Обработка распределенных запросов (distributed query proces-
sing).
Прозрачность распределенности (location independence).
Прозрачная фрагментация (fragmentation independence).
Прозрачное тиражирование (replication independence).
Независимость от оборудования (hardware independence).
Независимость от операционных систем (operation system
independence).
Прозрачность сети (network independence).
Независимость от баз данных (database independence).
Локальная автономия
Это качество означает, что управление данными на каждом из узлов распределенной системы выполняется локально. База данных, расположенная на одном из узлов, является компонентом распределенной
системы, но в то же время каждая из них функционирует как полноценная локальная база данных независимо от других узлов системы.
Независимость узлов
Все узлы (data site) равноправны и независимы, а расположенные
на них базы данных являются равноправными поставщиками данных в
общее пространство данных.
Непрерывные операции
Это качество можно трактовать как возможность непрерывного доступа к данным (свойство, известное как «24 часа в сутки, семь дней в
неделю») вне зависимости от их расположения и от операций, выпол-
57
няемых на локальных узлах. Лозунг: «Данные доступны всегда, а операции над ними выполняются непрерывно».
Обработка распределенных транзакций
Прежде чем рассмотреть это свойство, введем классификацию типов запросов.
1. Дистанционный запрос. Это единичный запрос, передаваемый на
обработку только одному серверу распределенной базы данных.
2. Дистанционная транзакция. Это транзакции, состоящая из нескольких запросов, передаваемая единственному серверу распределенной базы данных.
3. Распределенная транзакция. Это транзакции, состоящая из нескольких запросов,
передаваемая различным серверам распределенной
базы данных. При этом каждый из запросов обрабатывается одним и
только одним сервером.
4. Распределенный запрос. Это запрос, при обработке которого
требуется участие нескольких серверов. Каждый запрос обрабатывается несколькими серверами, но эта обработка остается прозрачной (невидимой) для клиента.
Свойство обработки распределенных транзакций DDB можно трак-
товать
как возможность выполнения операций обновления распределенной базы данных (INSERT, UPDATE, DELETE), не разрушающих
целостность и согласованность данных.
Ниже приведен пример распределенной транзакции:
begin work
insert into local_tab . . .
insert into db1@online1:tab1 . . .
insert into db2@online2:tab2 . . .
insert into db2@online2:tab3 . . .
commit work
В приведенном фрагменте в первом операторе insert указано имя
таблицы текущей базы данных сервера-координатора,
@online2
db2
– сетевые имена машин, tab1, tab2, tab3 – имена таблиц, db1,
– имена баз данных, оператор commit work инициализирует прото-
@online1,
кол двухфазной фиксации изменений.
58
Согласованность данных достигается применением протокола
двухфазной фиксации транзакций (two-phase commit protocol – 2PC
протокол). Его применение гарантирует согласованное изменение данных в нескольких узлах в рамках распределенной транзакции. Протокол двухфазной фиксации транзакций будет описан ниже.
Обработка распределенных запросов
Обработка распределенных запросов (Distributed Query – DQ) – задача более сложная, нежели обработка локальных запросов, и она требует
интеллектуального решения с помощью особого компонента – оптимизатора DQ. Основная цель оптимизатора DQ – повышение производительности, а основными факторами, влияющими на нее, являются:
объем информации;
скорость передачи;
загрузка сети;
производительность узлов.
Ниже приведен пример распределенного запроса:
select Customer.name, Customer.address, Order.number, Order.date from
Customer@london, Order@paris
where Customer.cust_number = Order.cust_number
В запросе предполагается, что таблица Customer хранится в узле в
городе
London, а таблица Order хранится узле в городе Paris (рис. 25).
Рис. 25. Расположение данных
Рассмотрим данное свойство на примере. Будем считать, что выполняются следующие условия.
В базе данных узла А описаны 10 000 изделий, запись о каждом из
которых занимает 100 байт (общий объем таблицы 1 Мбайт), и инфор-
59
мация о комплектации этих изделий деталями (поставки). Размер таблицы поставок составляет 1 000 000 записей по 100 байт, т. е. всего 100
Мбайт. В узле Б имеется таблица с записями о 100 000 деталей по 100
байт, что дает общий объем 10 Мбайт (рис. 26). Будем также предполагать, что передача данных по сети выполняется по скоростью
1 Мбайт/с.
Задача состоит в том, чтобы получить информацию обо всех собираемых в Беркли изделиях, при сборке которых используются деталь с
названием «Болт». При этом будем предполагать, что в Беркли собирается 1000 изделий, для их сборки выполнено 100 000 поставок, в число
которых входит 10 типов болтов.
Рис. 26. Расположение данных в узлах распределенной базы данных
Можно записать несколько вариантов SQL-запросов решения этой
задачи. Два из них приведены ниже:
60
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]