Что представляет собой реляционная бд. Функции Iif() и Format(). Типы данных MS Access
Функции СУБД.
Функции СУБД бывают высокого и низкого уровня.
Функции высокого уровня:
1. Определение данных – с помощью этой функции определяется какая информация будет храниться в БД (тип, свойства данных и как они между собой будут связаны).
2. Обработка данных. Информация может обрабатываться разными способами: выборка, фильтрация, сортировка, объединение одной информации с другой, вычисление итоговых значений.
3. Управление данными . С помощью этой функции указывается, кому разрешено знакомиться с данными, корректировать их или добавлять новую информацию, а также определять правила коллективного доступа.
Функции низкого уровня:
1. Управление данными во внешней памяти;
2. Управление буферами оперативной памяти;
3. Управление транзакциями;
4. Введение журнала изменений в БД;
5. Обеспечение целостности и безопасности БД.
Транзакцией называется неделимая последовательность операций, которая отслеживается СУБД от начала и до завершения, и в которой при невыполнении одной операции отменяется вся последовательность.
Журнал СУБД – особая БД или часть основной БД, недоступная пользователю и используемая для записи информации обо всех изменениях базы данных.
Введение журнала СУБД предназначено для обеспечения надёжности хранения в базе данных при наличии аппаратных сбоев и отказов, а так же ошибок в программном обеспечении.
Целостность базы данных – это свойство БД, означающее, что в ней содержится полная, непротиворечивая и адекватно отражающая предметную область информация.
Классификация СУБД.
СУБД можно классифицировать:
1. По видам программ:
a. Серверы БД (например, MS SQL Server, InterBase (Borland)) – предназначены для организации центров обработки данных в сетях ЭВМ и реализуют функции управления базами данных, запрашиваемые клиентскими программами с помощью операторов SQL (т.е. программы, которые отвечают на запросы);
b. Клиенты БД – программы, которые запрашивают данные. В качестве клиентских программ могут использоваться ПФСУБД, электронные таблицы, текстовые процессоры, программы электронной почты;
c. Полнофункциональные БД (MS Access, MS Fox Pro) – программа, имеющая развитый интерфейс, позволяющий создавать и модифицировать таблицы, вводить данные, создавать и форматировать запросы, разрабатывать отчёты и выводить их на печать.
2. По модели данных СУБД (как и БД):
a. Иерархические – основаны на древовидной структуре хранения информации и напоминают файловую систему компьютера; основной недостаток - невозможность реализовать отношение многие - ко – многим;
b. Сетевые – которые пришли на смену иерархическим и просуществовали недолго т. к. основной недостаток – сложность разработки серьёзных приложений. Основное отличие сетевой от иерархической в том, что в иерархической структура «запись – потомок» имеет только одного предка, а в сетевой потомок может иметь любое количество предков;
c. Реляционные – данные которых размещены в таблицах, между которыми существуют определённые связи;
d. Объектно – ориентированные – в них данные хранятся в виде объектов и основное преимущество при работе с ними в том, что к ним можно применить объектно – ориентированный подход;
e. Гибридные, т. е. объектно – реляционные – совмещают в себе возможности реляционных и объектно – ориентированных баз данных. Примером такой базы данных является Oracle (ранее она была реляционной).
3. В зависимости от расположения отдельных частей СУБД различают:
a. локальные – все части которой располагаются на одном компьютере;
b. сетевые.
К сетевым относятся:
- с организацией файл – сервер ;
При такой организации все данные находятся на одном компьютере, который называется файл – сервер, и который подключён к сети. При отыскании нужной информации передаётся весь файл, содержащий в том числе и много избыточной информации. И лишь при создании локальной копии отыскивается нужная запись.
- с организацией клиент – сервер;
Сервер БД принимает запрос от клиента, отыскивает в данных нужную запись и передаёт её клиенту. Запрос к серверу формируется на языке структурированных запросов SQL, поэтому серверы БД называют SQL – серверами.
- распределённые СУБД содержат несколько десятков и сотен серверов, размещённых на значительной территории.
Основные положения реляционной модели БД.
Реляционной базой данных называется такая база данных, в которой все данные организованы в виде таблиц, а все операции над этими данными сводятся к операциям над таблицами.
Особенности реляционных баз данных:
1. Данные хранятся в таблицах, состоящих из столбцов и строк;
2. На пересечении каждого столбца и строки находится одно значение;
3. У каждого столбца - поля есть своё имя, которое служит его названием - атрибут, и все значения в одном столбце, имеют один тип;
4. Столбцы располагаются в определённом порядке, который задаётся при создании таблицы, в отличие от строк, которые располагаются в произвольном порядке. В таблице может не быть ни одной строчки, но обязательно должен быть хотя бы один столбец.
Терминология реляционной базы данных:
| Элемент реляционной БД | Форма представления |
| 1. База данных | Набор таблиц |
| 2. Схема базы данных | Набор заголовков таблиц |
| 3. Отношение | Таблица |
| 4. Схема отношения | Строка заголовков столбцов таблицы |
| 5. Сущность | Описание свойств объекта |
| 6. Атрибут | Заголовок столбца |
| 7. Домен | Множество допустимых значений атрибута |
| 8. Первичный ключ | Уникальный идентификатор, однозначно определяющий каждую запись в таблице |
| 9. Тип данных | Тип значений элементов в таблице |
| 10. Кортеж | Строка (запись) |
| 11. Кардинальность | Количество строк в таблице |
| 12. Степень отношения | Количество полей |
| 13. Тело отношения | Множество кортежей отношения |
При проектировании реляционной БД данные размещают в нескольких таблицах. Между таблицами устанавливают связи с помощью ключей. При связывании таблиц выделяют основную и дополнительную (подчинённую) таблицу.
Существуют следующие виды связей между таблицами:
1. Связь вида 1:1 (один к одному) означает, что каждой записи в основной таблице соответствует одна запись в дополнительной таблице и, наоборот, каждой записи в дополнительной таблице соответствует одна запись в основной таблице.
2. Связь вида 1:М (один ко многим) означает, что каждой записи в основной таблице соответствует несколько записей в дополнительной таблице и, наоборот, каждой записи в дополнительной таблице соответствует только одна запись в основной таблице.
3. Связь вида М:1 (многим к одному) означает, что одной или нескольким записям в основной таблице соответствует только одна запись в дополнительной таблице.
4. Связь вида М:М (многим ко многим) – это, когда нескольким записям основной таблицы соответствует несколько записей дополнительной и наоборот.
5. Основные компоненты MS Access.
Основными компонентами (объектами) MS Access являются:
1. Таблицы;
3. Формы;
4. Отчёты;
5. Макросы:
Модули.
Таблица – это объект, предназначенный для хранения данных в виде записей (строк) и полей (столбцов). Каждое поле содержит отдельную часть записи, а каждая таблица используется для хранения сведений по одному конкретному вопросу.
Запрос – вопрос о данных, хранящихся в таблицах, или инструкция на отбор записей, подлежащих изменению.
Форма – это объект, в котором можно разместить элементы управления, предназначенные для ввода, изображения и изменения данных в полях таблицах.
Отчёт – это объект, который позволяет представить определённую пользователем информацию в определённом виде, просматривать и распечатывать её.
Макрос – одна или несколько макрокоманд, которые можно использовать для автоматизации конкретной задачи. Макрокоманда – основной строительный блок макроса; самостоятельная инструкция, которая может быть объединена с другими макрокомандами, чтобы автоматизировать выполнение задачи.
Модуль – набор описаний, инструкций и процедур, сохранённых под одним именем. В MS Access имеется три вида модулей:модуль формы, отчёта и общий модуль. Модули формы и отчётов содержат локальную программу для форм и отчётов.
6. Таблицы в MS Access.
В MS Access существуют следующие методы создания таблиц:
1. Режим таблицы;
2. Конструктор;
3. Мастер таблиц;
4. Импорт таблиц;
5. Связь с таблицами.
В режиме таблицы данные вводятся в пустую таблицу. Для ввода данных предоставляется таблица с 30 полями. После её сохранения MS Access сам решает, какой тип данных присвоить каждому полю.
Конструктор предоставляет возможность самостоятельно создавать поля, выбирать типы данных для полей, размеры полей и устанавливать свойства полей.
Для определения поля в режиме Конструктор задаются:
1. Имя поля , которое в каждой таблице должно иметь уникальное имя, являющееся комбинацией букв, цифр, пробелов и специальных символов, за исключением «.!” “ ». Максимальная длина имени 64 символа.
2. Тип данных определяет вид и диапазон допустимых значений, а также объём памяти, выделенный для этого поля.
Типы данных MS Access
| Тип данных | Описание |
| Текстовый | Текст и числа, например, имена и адреса, номера телефонов, почтовые индексы (до 255 символов). |
| Поле Memo | Длинный текст и числа, например комментарии и пояснения (до 64000 символов). |
| Числовой | Общий тип данных для числовых данных, допускающих проведение математических расчётов, за исключением денежных расчётов. |
| Дата / время | Значения даты и времени. Пользователь может выбирать стандартные формы или создавать специальный формат. |
| Денежный | Денежные значения. Для денежных расчётов не рекомендуется использовать числовые типы данных, т.к. они могут округляться при расчётах. Значения типа «денежный» всегда выводятся с указанным числом десятичных знаков после запятой. |
| Счётчик | Автоматически выставляющиеся последовательные номера. Нумерация начинается с 1. Поле счётчика удобно для создания ключа. Это поле является совместимым с полем числового типа, для которого в свойстве Размер указано значение «Длинное целое». |
| Логический | Значения «Да / Нет», «Истинно / Ложь», «Вкл / Выкл», одно из двух возможных значений. |
| Поле объекта OLE | Объекты, созданные в других программах, поддерживающие протокол OLE. |
3. Наиболее важные свойства полей:
- Размер поля задаёт максимальный размер данных, сохраняемых в поле.
- Формат поля является форматом отображения заданного типа данных и задаёт правила представления данных при выводе их на экран или печать.
- Подпись поля задаёт текст, который выводится в таблицах, формах, отчётах.
- Условие на значение позволяет осуществлять контроль ввода, задаёт ограничения на вводимые значения, при нарушении условий запрещает ввод и выводит текст, заданный свойством Сообщение об ошибке;
- Сообщение об ошибке задаёт текст сообщения, выводимый на экран при нарушении ограничений, заданных Условием на значение.
Тип элемента управления – свойство, которое задаётся на закладке Подстановка в окне конструктора таблиц. Это свойство определяет, будет ли отображаться поле в таблице и в какой форме – в виде поля или поля со списком.
Уникальный (первичный) ключ таблицы может быть простым или составным, включающим несколько полей.
Для определения ключа выделяются поля, составляющие ключ, и на панели инструментов нажимается кнопка ключевое поле или выполняется команда Правка / ключевое поле .
©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-16
Реляционные базы данных позволяют хранить информацию в нескольких «плоских» (двухмерных) таблицах, связанных между собой посредством совместно используемых полей данных, называемых ключами. Реляционные базы данных предоставляют более простой доступ к оперативно составляемым отчетам (обычно через SQL) и обеспечивают повышенную надежность и целостность данных благодаря отсутствию избыточной информации
Всем известно, что представляет собой простая база данных: телефонные справочники, каталоги товаров и словари - все это базы данных. Они могут быть структурированными или организованными каким-то иным образом: как плоские файлы, как иерархические или сетевые структуры или как реляционные таблицы. Чаще всего в организациях для хранения информации используются именно реляционные базы данных.
База данных - это набор таблиц, состоящих из столбцов и строк, аналогично электронной таблице. Каждая строка содержит одну запись; каждый столбец содержит все экземпляры конкретного фрагмента данных всех строк. Например, обычный телефонный справочник состоит из столбцов, содержащих телефонные номера, имена абонентов и адреса абонентов. Каждая строка содержит номер, имя и адрес. Эта простая форма называется плоским файлом в силу его двухмерной природы, а также того, что все данные хранятся в одном файле.
В идеале каждая база данных имеет по крайней мере один столбец с уникальным идентификатором, или ключом. Рассмотрим телефонную книгу. В ней может быть несколько записей с абонентом Джон Смит, но ни один из телефонных номеров не повторяется. Телефонный номер и служит ключом.
На самом деле все не так просто. Два или несколько человек, использующих один и тот же телефонный номер, могут быть перечислены в телефонном справочнике по отдельности, в силу чего телефонный номер появляется в двух или более местах, поэтому существует несколько строк с ключами, которые не являются уникальными.
Данные создают проблемы
В самых простых базах данных каждая запись занимает одну строку, иными словами, телефонной компании необходимо заводить отдельный столбец для каждого фрагмента бухгалтерской информации. То есть одну - для второго абонента «спаренного» телефона, еще одну - для третьего и т. д., в зависимости от того, сколько дополнительных абонентов понадобится.
Это значит, что каждая запись в базе данных должна иметь все эти дополнительные колонки, даже если больше они нигде не используются. Это также означает, что база данных должна быть реорганизована всякий раз, когда компания предлагает новую услугу. Вводится обслуживание тонального набора - и меняется структура базы, поскольку добавляется новая колонка. Вводится поддержка идентификации номера звонящего абонента, ожидания звонка и т. д. - и база данных перестраивается снова и снова.
В 60-е годы только самые крупные компании могли позволить себе приобретать компьютеры для управления своими данными. Более того, базы данных, построенные на статических моделях данных и с помощью процедурных языков программирования, таких как Кобол, могут оказаться слишком дорогими в том, что касается поддержки, и не всегда надежными. Процедурные языки определяют последовательность событий, через которую компьютер должен пройти, чтобы выполнить задачу. Программирование таких последовательностей было сложным делом, особенно если требовалось менять структуру базы данных или составлять новый вид отчетов.
Мощные связи
Эдгар Кодд, сотрудник исследовательской лаборатории корпорации IBM в Сан-Хосе, по существу, создал и описал концепцию реляционных баз данных в своей основополагающей работе «Реляционная модель для крупных, совместно используемых банков данных» (A Relational Model of Data for Large Shared Data Banks. Communications of the ACM, июнь 1970).
Кодд предложил модель, которая позволяет разработчикам разделять свои базы данных на отдельные, но взаимосвязанные таблицы, что увеличивает производительность, но при этом внешнее представление остается тем же, что и у исходной базы данных. С тех пор Кодд считается отцом-основателем отрасли реляционных баз данных.
Эта модель работает следующим образом. Телефонная компания может создать основную таблицу, используя в качестве первичного ключа номер телефона, и хранить его с другой базовой информацией о потребителях. Компания может определить отдельную таблицу со столбцами для этого первичного ключа и для дополнительных служб, таких как поддержка идентификации номера звонящего абонента и ожидание звонка. Она также может создать еще одну таблицу для контроля счетов за переговоры, где каждая запись состоит из номера телефона и данных об оплате звонков.
Конечные пользователи могут легко получить ту информацию, которую они хотят, и в том виде, в каком она им требуется, хотя эти данные хранятся в различных таблицах. Поэтому представитель службы поддержки потребителей телефонной компании может отобразить на одном и том же экране информацию о счетах абонента, а также о состоянии специальных служб или о том, когда была получена последняя оплата.
Кодд сформулировал 12 правил для реляционных баз данных, большинство которых касаются целостности и обновления данных, а также доступа к ним. Первые два достаточно понятны даже пользователям, не обладающим техническими навыками.
Правило 1, информационное правило, указывает, что вся информация в реляционной базе данных представляется как набор значений, хранящихся в таблицах.
Правило 2, правило гарантии доступа, определяет, что доступ к каждому элементу данных в реляционной базе данных можно получить с помощью имени таблицы, первичного ключа и названия столбца. Другими словами, все данные хранятся в таблицах, и, если известно название таблицы, первичный ключ и столбец, где находится требуемый элемент данных, его всегда можно извлечь.
Суть работы Кодда заключалась в том, что предлагалось с реляционными базами данных использовать декларативные, а не процедурные языки программирования. Декларативные языки, такие как язык запросов SQL (Structured Query Language), дают пользователям возможность, по существу, сообщить компьютеру: «Я хочу получить следующие биты данных из всех записей, которые удовлетворяют определенному набору критериев». Компьютер сам «поймет», какие необходимо совершить шаги, чтобы получить эту информацию из базы данных.
Для работы с огромным количеством активно используемых баз данных применяются программные системы управления реляционными базами данных, созданные такими авторитетными производителями, как Oracle, Sybase, IBM, Informix и Microsoft.
Хотя большую часть вариантов реализаций SQL можно назвать интероперабельными лишь с известным приближением, этот утвержденный в качестве международного стандарта механизм позволяет создавать сложные системы, основу которых составляют базы данных. Удобный для программирования интерфейс между Web-сайтами и реляционными базами данных дает конечным пользователям возможность добавлять новые записи и обновлять существующие, а также создавать отчеты для самых разных служб, таких как выполнение интерактивных торговых операций и доступ к интерактивным библиотечным каталогам.
Реляционная модель
Реляционная база данных использует набор таблиц, связанных друг с другом посредством определенного ключа (в данном случае это поле PhoneNumber)
Базой данных (БД) называется организованная в соответствии с определенными правилами и поддерживаемая в памяти компьютера совокупность сведений об объектах, процессах, событиях или явлениях, относящихся к некоторой предметной области, теме или задаче. Она организована таким образом, чтобы обеспечить информационные потребности пользователей, а также удобное хранение этой совокупности данных, как в целом, так и любой ее части.
Реляционная база данных представляет собой множество взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определенного вида. Каждая строка таблицы содержит данные об одном объекте (например, автомобиле, компьютере, клиенте), а столбцы таблицы содержат различные характеристики этих объектов - атрибуты (например, номер двигателя, марка процессора, телефоны фирм или клиентов).
Строки таблицы называются записями. Все записи таблицы имеют одинаковую структуру - они состоят из полей (элементов данных), в которых хранятся атрибуты объекта (рис. 1). Каждое поле записи содержит одну характеристику объекта и представляет собой заданный тип данных (например, текстовая строка, число, дата). Для идентификации записей используется первичный ключ. Первичным ключом называется набор полей таблицы, комбинация значений которых однозначно определяет каждую запись в таблице.
Рис. 1. Названия объектов в таблице
Для работы с данными используются системы управления базами данных (СУБД). Основные функции СУБД:
Определение данных (описание структуры баз данных);
Обработка данных;
Управление данными.
Разработка структуры БД - важнейшая задача, решаемая при проектировании БД. Структура БД (набор, форма и связи ее таблиц) - это одно из основных проектных решений при создании приложений с использованием БД. Созданная разработчиком структура БД описывается на языке определения данных СУБД.
Любая СУБД позволяет выполнять следующие операции с данными:
Добавление записей в таблицы;
Удаление записей из таблицы;
Обновление значений некоторых полей в одной или нескольких записях в таблицах БД;
Поиск одной или нескольких записей, удовлетворяющих заданному условию.
Для выполнения этих операций применяется механизм запросов. Результатом выполнения запросов является либо отобранное по определенным критериям множество записей, либо изменения в таблицах. Запросы к базе формируются на специально созданном для этого языке, который так и называется «язык структурированных запросов» (SQL - Structured Query Language).
Под управлением данными обычно понимают защиту данных от несанкционированного доступа, поддержку многопользовательского режима работы с данными и обеспечение целостности и согласованности данных.
Свойства реляционной таблицы
ОСНОВНЫЕ ПОНЯТИЯ БАЗ ДАННЫХ
База данных (БД) – именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области данных.
Примеры предметных областей данных: склад, магазин, вуз, больница, учебный процесс и т. д. Именно предметная область определяет совокупность данных, которые должны храниться в базе данных.
Система управления базами данных (СУБД) – совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования базы данных многими пользователями.
Другие определения, имеющие отношение к БД и СУБД.
Банк данных (БнД) – это система специальным образом организованных данных – баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и многоцелевого использования данных.
Информационная система (ИС) – взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной задачи.
Основой практически любой информационной системы является база данных.
Сервер – компьютер или программа, владеющая определенным информационным ресурсом и предназначенная для обработки запросов от программ-клиентов.
Основными моделями данных, определяющие структуру базы данных, являются:
иерархическая модель;
сетевая модель;
реляционная модель.
РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ
Теоретической основой этой модели является теория отношений и основной структурой данных – отношение. Именно поэтому модель получила название реляционной (от английского слова relation - отношение).
Отношение представляет собой множество элементов, называемых кортежами. Наглядной формой представления отношения является двумерная таблица . Смысловые значения некоторых элементов реляционной модели приведены в следующей таблице.
Подавляющее число создаваемых и используемых баз данных являются реляционными . Их создание и развитие связано с научными работами известного американского математика, специалиста в области систем баз данных Э. Кодда.
Свойства реляционной таблицы
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
· каждый элемент таблицы - один элемент данных;
· все столбцы (поля, атрибуты) в таблице однородные, т.е. все элементы в одном столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
· каждый столбец имеет уникальное имя;
· одинаковые строки (записи, кортежи) в таблице отсутствуют;
· порядок следования строк и столбцов может быть произвольным.
Каждое поле содержит одну характеристику объекта предметной области. В записи собраны сведения об одном экземпляре этого объекта.
Ключи
Поле, каждое значение которого однозначно определяет соответствующую запись, называется простым ключом (ключевым полем). Ключ, состоящий из нескольких полей называется составным ключом . В СУБД Access в качестве ключа может быть использован Счетчик, который автоматически возрастает на единицу при вводе в таблицу новой записи. Такой ключ называют искусственным. Он семантически не связан ни с одним полем таблицы. Из-за этого он допускает повторный ввод одних и тех же записей. Но с помощью него просто устанавливать связь между таблицами. Основное свойство ключа – уникальность, неповторимость.
Типы связей между таблицами
Структура базы данных определяется структурой таблиц и связями между ними.
Связи между таблицами бывают трех типов:
«один-к-одному» (1:1) – одной записи в главной таблице соответствует одна запись в подчиненной таблице,
«один-ко-многим» (1:М) – одной записи в главной таблице соответствует несколько записей в подчиненной таблице,
«многие-ко-многим» (М:М) – нескольким записям в главной таблице соответствуют несколько записей в подчиненной таблице. Или одной записи в первой таблице может соответствовать несколько записей во второй таблице. И одной записи во второй таблице могут соответствовать несколько записей в первой таблице.
Создание связей между таблицами
Связь между таблицами устанавливается с помощью ключей. Главной называют таблицу, первичный ключ которой используется для установления связи с другой таблицей, которая в этом случае называется подчиненной.
Чтобы связать две реляционные таблицы, необходимо ключ главной таблицы ввести в состав подчиненной таблицы. Название ключа может быть другим, но обязательно одинаковыми с первичным ключом должны быть тип и размер вторичного ключа в подчиненной таблице. Для удобства лучше обозначение вторичного ключа оставлять таким же, как и первичного. Однако если ключом выбран Счетчик , то вторичный ключ должен иметь тип Числовой - длинное целое (но не Счетчик !). Вторичный ключ – это или обычное поле, или часть первичного ключа в подчиненной таблице.
СУБД Access для реализации связи «многие-ко-многим» требует создать таблицу связи и ввести в нее в качестве вторичных ключей первичные ключи двух таблиц, которые должны иметь такую связь (М:М). После этого устанавливается связь 1:М каждой из двух таблиц с таблицей связи. Между двумя таблицами таким образом реализуется связь М:М. Если в БД «Моя библиотека» создать таблицы Книги и Авторы, то связь между ними будет вида М:М, так как одной записи в таблице Книги (реквизиты одной книги) может соответствовать несколько записей в таблице Авторы. Потому что у одной книги может быть несколько авторов. В свою очередь, одной записи в таблице Авторы могут соответствовать несколько записей в таблице Книги, так как один автор может написать несколько книг. Таблицу связи можно назвать КнигиАвторы, в которую будут включены ключи обеих таблиц – Книги и Авторы. Если требуется, в таблицу связи можно включить и другие поля.
Среди реляционных баз данных следует различать корпоративные и настольные базы данных.
Из корпоративных реляционных СУБД наиболее распространенными являются: Oracl, IBM DB2, Sybase, Microsoft SQL Server, Informix. Из постреляционных СУБД известна СУБД Cache компании InterSystems.
Наиболее известны в настоящее время следующие настольные БД: Microsoft Access, Paradox (фирмы Borland), FoxPro (Microsoft), dBase IV (IBM), Clarion.
Эти СУБД занимают более 90% всего рынка СУБД.
В следующем разделе дана краткая характеристика СУБД Microsoft Access.
Все современные БД используют CBO (Cost Based Optimization), стоимостную оптимизацию. Суть её заключается в том, что для каждой операции определяется её «стоимость», а затем общая стоимость запроса уменьшается с помощью использования наиболее «дешёвых» цепочек операций.Для лучшего понимания стоимостной оптимизации мы рассмотрим три распространённых способа объединения двух таблиц и увидим, как даже простой запрос на объединение может превратиться в кошмар для оптимизатора. В нашем рассмотрении мы будем ориентироваться на временнỳю сложность, хотя оптимизатор вычисляет «стоимость» в ресурсах процессора, памяти и операциях ввода/вывода. Просто временнáя сложность - понятие приблизительное, а для определения необходимых ресурсов процессора нужно подсчитывать все операции, включая добавление, операторы if, умножение, итерации и т.д.
Кроме того:
- Для выполнения каждой высокоуровневой операции процессор выполняет разное количество низкоуровневых операций.
- Стоимость процессорных операций (с точки зрения циклов) разная у разных видов процессоров, то есть она зависит от конкретной архитектуры ЦПУ.
Мы говорили о них, когда рассматривали В-деревья. Как вы помните, индексы уже отсортированы. К слову, есть и другие виды индексов, например, битовые (bitmap index). Но они не дают выигрыша с точки зрения использования процессора, памяти и дисковой подсистемы по сравнению с индексами В-деревьев. Кроме того, многие современные БД могут динамически создавать временные индексы для текущих запросов, если это поможет уменьшить стоимость выполнения плана.
4.4.2. Способы обращений
Прежде чем применять операторы объединения, нужно сначала получить необходимые данные. Сделать это можно следующими способами.
- Полное сканирование. БД просто считывает целиком таблицу или индекс. Как вы понимаете, для дисковой подсистемы индекс читать дешевле, чем таблицу.
- Сканирование диапазона.
Используется, например, когда вы используете предикаты наподобие WHERE AGE > 20 AND AGE < 40. Конечно, для сканирования диапазона индекса вам нужно иметь индекс для поля AGE.
В первой части статьи мы уже выяснили, что временнáя сложность запроса диапазона определяется как M + log(N), где N - количество данных в индексе, а М - предположительное количество строк внутри диапазона. Значения обеих этих переменных нам известны благодаря статистике. При сканировании диапазона считывается лишь часть индекса, поэтому данная операция стоит меньше по сравнению с полным сканированием.
- Сканирование по уникальным значениям. Используется в тех случаях, когда вам нужно получить из индекса только какое-то одно значение.
- Обращение по ID строки.
Если БД использует индекс, то бόльшую часть времени она будет заниматься поиском связанных с ним строк. Например, мы делаем такой запрос:
SELECT LASTNAME, FIRSTNAME from PERSON WHERE AGE = 28
Если у нас есть индекс для колонки возраста, то оптимизатор воспользуется индексом для поиска всех 28-летних, а затем запросит ID соответствующих строк таблицы, поскольку индекс содержит информацию только о возрасте.Допустим, у нас другой запрос:
SELECT TYPE_PERSON.CATEGORY from PERSON, TYPE_PERSON WHERE PERSON.AGE = TYPE_PERSON.AGE
Для объединения с TYPE_PERSON будет использоваться индекс по колонке PERSON. Но поскольку мы не запрашивали информацию у таблицы PERSON, то и обращаться к ней по ID строк никто не будет.Данный подход хорош только при небольшом количестве обращений, поскольку он дорог с точки зрения ввода/вывода. Если вам нужно часто обращаться по ID, то лучше воспользоваться полным сканированием.
- Другие способы . О них можно почитать в документации Oracle . В разных БД могут использоваться разные названия, но принципы везде одни и те же.
Итак, мы знаем, как получить данные, пришла пора их объединить. Но сначала давайте определимся с новыми терминами: внутренние зависимости и внешние зависимости . Зависимостью может быть:
- таблица,
- индекс,
- промежуточный результат предыдущей операции (например, предыдущего объединения).
Чаще всего стоимость A JOIN B не равна стоимости B JOIN A.
Предположим, что внешняя зависимость содержит N элементов, а внутренняя - М. Как вы помните, оптимизатору известны эти значения благодаря статистике. N и M являются кардинальными числами зависимостей .
- Объединение с помощью вложенных циклов.
Это простейший способ объединения.
Работает он так: для каждой строки внешней зависимости ищутся совпадения по всем строкам внутренней зависимости.
Пример псеводокода:
Nested_loop_join(array outer, array inner) for each row a in outer for each row b in inner if (match_join_condition(a,b)) write_result_in_output(a,b) end if end for end for
Поскольку здесь двойная итерация, временнáя сложность определяется как О(N*M).Для каждой из N строк внешней зависимости нужно считать М строк внешней зависимости. То есть этот алгоритм требует N + N*M чтений с диска. Если внутренняя зависимость достаточно мала, то можно поместить её целиком в память, и тогда на долю дисковой подсистемы придётся только M + N чтений. Так что рекомендуется делать внутреннюю зависимость как можно компактнее, чтобы загнать в память.
С точки зрения временнόй сложности разницы никакой.
Также можно заменить внутреннюю зависимость индексом, это позволит сэкономить операции ввода/вывода.
Если внутренняя зависимость не влезает в память целиком, можно использовать другой алгоритм, более экономно использующий диск.- Вместо чтения обеих зависимостей построчно, они считываются группами строк (bunch), при этом в памяти сохраняется по одной группе из каждой зависимости.
- Строки из этих групп сравниваются между собой, а найденные совпадения сохраняются отдельно.
- Затем в память подгружаются новые группы и тоже сравниваются друг с другом.
Пример алгоритма:
// improved version to reduce the disk I/O. nested_loop_join_v2(file outer, file inner) for each bunch ba in outer // ba is now in memory for each bunch bb in inner // bb is now in memory for each row a in ba for each row b in bb if (match_join_condition(a,b)) write_result_in_output(a,b) end if end for end for end for end for
В данном случае временнáя сложность остаётся той же, зато снижается количество обращений к диску: (количество групп внешней + количество групп внешней * количество групп внутренней). С увеличением размера групп ещё больше уменьшается количество обращений к диску.Примечание: в этом алгоритме при каждом обращении считывается больший объём данных, но это не играет роли, поскольку обращения последовательные.
- Хэш-объединение.
Это более сложная операция, но во многих случаях её стоимость ниже.
Алгоритм следующий:
- Считываются все элементы из внутренней зависимости.
- В памяти создаётся хэш-таблица.
- Один за другим считываются все элементы из внешней зависимости.
- Для каждого элемента вычисляется хэш (с помощью соответствующей функции из хэш-таблицы), чтобы можно было найти соответствующий блок во внутренней зависимости.
- Элементы из блока сравниваются с элементами из внешней зависимости.
- Внутренняя зависимость содержит Х блоков.
- Хэш-функция распределяет хэши почти одинаково для обеих зависимостей. То есть все блоки имеют идентичный размер.
- Стоимость поиска соответствия между элементами внешней зависимости и всеми элементами внутри блока равна количеству элементов внутри блока.
(М / Х) * (N / X) + стоимость_создания_хэш-таблицы(М) + стоимость_хэш-функции * N
А если хэш-функция создаёт достаточное маленькие блоки, то временнáя сложность будет равна О(М + N).
Есть ещё один способ хэш-объединения, более экономно расходующий память и не требующий больше операций ввода/вывода:
- Вычисляются хэш-таблицы для обеих зависимостей.
- Кладутся на диск.
- А затем сравниваются поведёрно друг с другом (один блок загружается в память, а второй считывается построчно).
Операцию объединения можно разделить на два этапа:
- (Опционально) сначала осуществляется объединение сортировкой, когда оба набора входных данных сортируются по ключам объединения.
- Затем осуществляется слияние.
Алгоритм сортировки слиянием уже обсуждался выше, в данном случае он вполне себя оправдывает, если вам важно экономить память.
Но бывает, что наборы данных поступают уже отсортированными, например:
- Если таблица организована нативно.
- Если зависимость является индексом при наличии условия объединения.
- Если объединение происходит с промежуточным отсортированным результатом.
Эта операция очень похожа на операцию слияния при процедуре сортировки слиянием. Но вместо выбора всех элементов обеих зависимостей мы выбираем только равные элементы.
- Сравниваются два текущих элемента обеих зависимостей.
- Если они равны, то заносятся в результирующую таблицу, и далее сравниваются два следующих элемента, по одному из каждой зависимости.
- Если они не равны, то сравнение повторяется, но вместо наименьшего из двух элементов берётся следующий элемент из той же зависимости, поскольку вероятность совпадения в этом случае выше.
- Шаги 1-3 повторяются, пока на закончатся элементы одной из зависимостей.
Если обе зависимости ещё нужно отсортировать, то временнáя сложность равна O(N * Log(N) + M * Log(M)).
Этот алгоритм работает хорошо, потому что обе зависимости уже отсортированы, и нам не приходится перемещаться по ним туда-обратно. Однако здесь допущено некоторое упрощение: алгоритм не обрабатывает ситуации, когда одни и те же данные встречаются многократно, то есть когда происходят многократные совпадения. В реальности используется более сложная версия алгоритма. Например:
MergeJoin(relation a, relation b) relation output integer a_key:=0; integer b_key:=0; while (a!=null and b!=null) if (a < b) a_key++; else if (a > b) b_key++; else //Join predicate satisfied write_result_in_output(a,b) //We need to be careful when we increase the pointers integer a_key_temp:=a_key; integer b_key_temp:=b_key; if (a != b) b_key_temp:= b_key + 1; end if if (b != a) a_key_temp:= a_key + 1; end if if (b == a && b == a) a_key_temp:= a_key + 1; b_key_temp:= b_key + 1; end if a_key:= a_key_temp; b_key:= b_key_temp; end if end while
Если бы существовал самый лучший способ объединения, то не существовало бы всех этих разновидностей. Так что ответ на этот вопрос зависит от кучи факторов:
- Объём доступной памяти . Если её мало, забудьте о мощном хэш-объединении. По крайне мере, о его выполнении целиком в памяти.
- Размер двух наборов входных данных. Если у вас одна таблица большая, а вторая очень маленькая, то быстрее всего сработает объединение с помощью вложенных циклов, потому что хэш-объединение подразумевает дорогую процедуру создания хэшей. Если у вас две очень большие таблицы, то объединение с помощью вложенных циклов поглотит все ресурсы процессора.
- Наличие индексов. Если у вас два индекса В-деревьев, то лучше использовать объединение слиянием.
- Нужно ли сортировать результат. Возможно, вы захотите использовать дорогое объединение слиянием (с сортировкой), если работаете с несортированными наборами данных. Тогда на выходе вы получите сортированные данные, которые удобнее объединить с результатами другого объединения. Или потому что запрос косвенно или явно предполагает получение данных, отсортированных операторами ORDER BY/GROUP BY/DISTINCT.
- Отсортированы ли выходные зависимости . В данном случае лучше использовать объединение слиянием.
- Зависимости каких типов вы используете . Объединение по эквивалентности (таблицаА.колонка1 = таблицаБ.колонка2)? Внутренние зависимости, внешние, декартово произведение или самообъединение (self-join)? В разных ситуациях некоторые способы объединения не работают.
- Распределение данных . Если данные отклонены по условию объединения (например, вы объединяете людей по фамилиям, но часто встречаются однофамильцы), то ни в коем случае нельзя использовать хэш-объединение. Иначе хэш-функция будет создавать корзины с очень плохим внутренним распределением.
- Нужно ли выполнять объединение в несколько процессов/потоков.
4.4.4. Упрощённые примеры
Допустим, нам нужно объединить пять таблиц, чтобы получить полное представление о неких людях. Каждый человек может иметь:
- Несколько номеров мобильных телефонов.
- Несколько адресов электронной почты.
- Несколько физических адресов.
- Несколько номеров банковских счетов.
SELECT * from PERSON, MOBILES, MAILS,ADRESSES, BANK_ACCOUNTS
WHERE
PERSON.PERSON_ID = MOBILES.PERSON_ID
AND PERSON.PERSON_ID = MAILS.PERSON_ID
AND PERSON.PERSON_ID = ADRESSES.PERSON_ID
AND PERSON.PERSON_ID = BANK_ACCOUNTS.PERSON_ID
Оптимизатору нужно найти наилучший способ обработки данных. Но есть две проблемы:
- Какой способ объединения использовать? Есть три варианта (хэш-объединение, объединение слиянием, объединение с помощью вложенных циклов), с возможностью использования 0, 1 или 2 индексов. Не говоря уже о том, что индексы тоже могут быть разными.
- В каком порядке нужно производить объединение?
Исходя из описанного, какие есть варианты действий?
- Использовать брутфорс-подход. С помощью статистики подсчитать стоимость каждого из возможных планов исполнения запроса и выбрать самый дешёвый. Но вариантов довольно много. Для каждого порядка объединения можно использовать три разных способа объединения, итого 34=81 возможных планов исполнения. В случае с бинарным деревом задача выбора порядка объединения превращается в задачу о перестановках, и количество вариантов равно (2 * 4)! / (4 + 1)!.. В результате, в данном очень упрощённом примере общее количество возможных планов исполнения запроса составляет 34 * (2 * 4)! / (4 + 1)! = 27 216. Если добавить к этому варианты, когда при объединении слиянием используется 0, 1 или 2 индекса В-дерева, то количество возможных планов повышается до 210 000. Мы уже упоминали, что это ОЧЕНЬ ПРОСТОЙ запрос?
- Поплакать и уволиться. Очень соблазнительно, но непродуктивно, да и деньги нужны.
- Попробовать несколько планов и выбрать самый дешёвый. Раз обсчитать стоимость всех возможных вариантов не получается, можно взять произвольный тестовый набор данных и прогнать по нему все виды планов, чтобы оценить их стоимость и выбрать лучший.
- Применить «умные» правила для уменьшения количества возможных планов.
Есть два типа правил:- «Логические», с помощью которых можно исключить бесполезные варианты. Но они далеко не всегда применимы. Например, «при объединении с помощью вложенных циклов внутренняя зависимость должна являться наименьшим набором данных».
- Можно не искать наиболее выгодное решение и применить более жёсткие правила для уменьшения числа возможных планов. Скажем, «если зависимость мала, используем объединение с помощью вложенных циклов, но никогда - объединение слиянием или хэш-объединение».
Так как же БД делает выбор?
4.4.5. Динамическое программирование, «жадный» алгоритм и эвристика
Реляционная БД использует разные подходы, о которых было сказано выше. И задачей оптимизатора является поиск подходящего решения в течение ограниченного времени. В большинстве случаев оптимизатор ищет не наилучшее, а просто хорошее решение.
Брутфорс может подойти в случае с маленькими запросами. А благодаря способам исключения ненужных вычислений даже для запросов среднего размера можно использовать грубую мужскую силу. Это называется динамическим программированием.
Его суть заключается в том, что многие планы исполнения очень похожи.
На этой иллюстрации все четыре плана используют поддерево A JOIN B. Вместо вычисления его стоимости для каждого плана, мы можем посчитать его лишь раз и затем использовать эти данные столько, сколько нужно. Иными словами, с помощью мемоизации мы решаем проблему перекрытия, то есть избегаем лишних вычислений.
Благодаря такому подходу вместо временнόй сложности (2*N)!/(N+1)! мы получаем «всего лишь» 3 N . Применительно к предыдущему примеру с четырьмя объединениями это означает уменьшение количества вариантов с 336 до 81. Если взять запрос с 8 объединениями (небольшой запрос), то уменьшение сложности будет с 57 657 600 до 6 561.
Если вы уже знакомы с динамическим программированием или алгоритмизацией, можете поиграться с этим алгоритмом:
Procedure findbestplan(S)
if (bestplan[S].cost infinite)
return bestplan[S]
// else bestplan[S] has not been computed earlier, compute it now
if (S contains only 1 relation)
set bestplan[S].plan and bestplan[S].cost based on the best way
of accessing S /* Using selections on S and indices on S */
else for each non-empty subset S1 of S such that S1 != S
P1= findbestplan(S1)
P2= findbestplan(S - S1)
A = best algorithm for joining results of P1 and P2
cost = P1.cost + P2.cost + cost of A
if cost < bestplan[S].cost
bestplan[S].cost = cost
bestplan[S].plan = “execute P1.plan; execute P2.plan;
join results of P1 and P2 using A”
return bestplan[S]
Динамическое программирование можно использовать и для более крупных запросов, но придётся вводить дополнительные правила (эвристику), чтобы уменьшить число возможных планов:
Жадные алгоритмы
Но если запрос очень велик, или если нам нужно крайне быстро получить ответ, используется другой класс алгоритмов - жадные алгоритмы.
В данном случае план исполнения запроса строится пошагово с помощью некоего правила (эвристики). Благодаря ему жадный алгоритм ищет наилучшее решение для каждого этапа по отдельности. План начинается с оператор JOIN, а затем на каждом этапе добавляется новый JOIN в соответствии с правилом.
Рассмотрим простой пример. Возьмём запрос с 4 объединениями 5 таблиц (A, B, C, D и E). Несколько упростим задачу и представим, что единственным вариантом является объединение с помощью вложенных алгоритмов. Будем использовать правило «применять объединение с наименьшей стоимостью».
- Начинаем с одной из таблиц, например, А.
- Вычисляем стоимость каждого объединения с А (она будет как в роли внешней, так и внутренней зависимости).
- Находим, что дешевле всего нам обойдётся A JOIN B.
- Затем вычисляем стоимость каждого объединения с результатом A JOIN B (его тоже рассматриваем в двух ролях).
- Находим, что выгоднее всего будет (A JOIN B) JOIN C.
- Опять делаем оценку возможных вариантов.
- В конце получаем такой план исполнения запроса: (((A JOIN B) JOIN C) JOIN D) JOIN E)/
Данный алгоритм называется «алгоритм ближайшего соседа ».
Не будем углубляться в подробности, но при хорошем моделировании сложности сортировки N*log(N) данная проблема может быть . Временнáя сложность алгоритма равна О(N*log(N)) вместо О(3 N) для полной версии с динамическим программированием. Если у вас большой запрос с 20 объединениями, то это будет 26 против 3 486 784 401. Большая разница, верно?
Но есть нюанс. Мы предполагаем, что если найдём наилучший способ объединения двух таблиц, то получим самую низкую стоимость при объединении результатом предыдущих объединений со следующими таблицами. Однако даже если A JOIN B будет самым дешёвым вариантом, то (A JOIN C) JOIN B может иметь стоимость ниже, чем (A JOIN B) JOIN C.
Так что если вам позарез нужно найти самый дешёвый план всех времён и народов, то можно посоветовать многократно прогонять жадные алгоритмы с использованием разных правил.
Другие алгоритмы
Если вы уже сыты по горло всеми этими алгоритмами, то можете пропустить эту главу. Она не обязательна для усвоения всего остального материала.
Многие исследователи занимаются проблемой поиска наилучшего плана исполнения запроса. Зачастую пытаются найти решения для каких-то конкретных задач и шаблонов. Например, для звездообразных объединений, исполнения параллельных запросов и т.д.
Ищутся варианты замены динамического программирования для исполнения больших запросов. Те же жадные алгоритмы являются подмножеством эвристических алгоритмов. Они действуют сообразно правилу, запоминают результат одного этапа и используют его для поиска лучшего варианта для следующего этапа. И алгоритмы, которые не всегда используют решение, найденное для предыдущего этапа, называются эвристическими.
В качестве примера можно привести генетические алгоритмы:
- Каждое решение представляет собой план полного исполнения запроса.
- Вместо одного решения (плана) алгоритм на каждом этапе формирует Х решений.
- Сначала создаётся Х планов, делается это случайным образом.
- Из них сохраняются только те планы, чья стоимости удовлетворяет некоему критерию.
- Затем эти планы смешиваются, что бы создать Х новых планов.
- Некоторые из новых планов модифицируются случайным образом.
- Предыдущие три шага повторяются Y раз.
- Из планов последнего цикла мы получаем наилучший.
Кстати, генетические алгоритмы интегрированы в PostgreSQL .
В БД используются и такие эвристические алгоритмы, как симулированная нормализация (Simulated Annealing), итеративное улучшение (Iterative Improvement), двухфазная оптимизация (Two-Phase Optimization). Но не факт, что они применяются в корпоративных системах, возможно, их удел - исследовательские продукты.
4.4.6. Настоящие оптимизаторы
Тоже необязательная глава, можно и пропустить.
Давайте отойдём от теоретизирования и рассмотрим реальные примеры. Например, как работает оптимизатор SQLite . Это «лёгкая» БД, использующая простую оптимизацию на основе жадного алгоритма с дополнительными правилами:
- SQLite никогда не меняет порядок таблиц в операции CROSS JOIN.
- Используется объединение с помощью вложенных циклов.
- Внешние объединения всегда оцениваются в том порядке, в котором они осуществлялись.
- Вплоть до версии 3.8.0 для поиска наилучшего плана исполнения запроса используется жадный алгоритм «ближайшего соседа» (Nearest Neighor). А с версии 3.8.0 применяется «N ближайших соседей » (N3, N Nearest Neighbors).
- Жадные алгоритмы:
- 0 - минимальная оптимизация. Используется сканирование индекса, объединение с помощью вложенных циклов и исключение перезаписи некоторых запросов.
- 1 - низкая оптимизация
- 2 - полная оптимизация
- Динамическое программирование:
- 3 - средняя оптимизация и грубая аппроксимация
- 5 - полная оптимизация, используются все эвристические методики
- 7 - то же самое, но без эвристики
- 9 - максимальная оптимизация любой ценой, без оглядки на затрачиваемые усилия. Оцениваются все возможные способы объединения, включая декартовы произведения.
- Сбор всей возможной статистики, включая частотные распределения и квантили.
- Применение всех правил перезаписи запросов, включая составление табличного маршрута для материализованных запросов). Исключение составляют правила, требующие интенсивных вычислений, применяемые для очень ограниченного числа случаев.
- При переборе вариантов объединения с помощью динамического программирования:
- Ограниченно используется составная внутренняя зависимость.
- Для звездообразных схем с таблицами преобразования ограниченно используются декартовы произведения.
- Рассматривается широкий диапазон способов доступа, включая предварительную выборку списка (об этом ниже), специальную операцию с индексами AND и составление табличного маршрута для материализованных запросов.
Прочие условия (GROUP BY, DISTINCT и т.д.) обрабатываются простыми правилами.
4.4.7. Кэш плана запросов
Поскольку составление плана требует времени, большинство БД хранят план в кэше плана запросов. Это помогает избежать ненужных вычислений одних и тех же этапов. БД должна знать, когда именно ей нужно обновить устаревшие планы. Для этого устанавливается некий порог, и если изменения в статистике его превышают, то план, относящийся к данной таблице, удаляется из кэша.
Исполнитель запросов
На данном этапе наш план уже оптимизирован. Он перекомпилируется в исполняемый код и, если ресурсов достаточно, исполняется. Операторы, содержащиеся в плане (JOIN, SORT BY и т.д.) могут обрабатываться как последовательно, так и параллельно, решение принимает исполнитель. Для получения и записи данных он взаимодействует с диспетчером данных.5. Диспетчер данных
Диспетчер запросов исполняет запрос и нуждается в данных из таблиц и индексов. Он запрашивает их у диспетчера данных, но тут есть две трудности:
- Реляционные БД используют транзакционную модель. Нельзя в конкретный момент времени получить любые желаемые данные, потому что в это время они могут кем-то использоваться/модифицироваться.
- Извлечение данных - самая медленная операция в БД. Поэтому диспетчеру данных нужно уметь прогнозировать свою работу, чтобы своевременно заполнять буфер памяти.
5.1. Диспетчер кэша
Как уже не раз говорилось, самым узким местом в БД является дисковая подсистема. Поэтому для увеличения производительности используется диспетчер кэша.
Вместо того, чтобы получать данные напрямую от файловой системы, исполнитель запросов обращается за ними к диспетчеру кэша. Тот использует содержащийся в памяти буферный пул, что позволяет радикально увеличить производительность БД. В цифрах это трудно оценить, поскольку многое зависит от того, что вам нужно:
- Последовательный доступ (полное сканирование) или случайный (доступ по ID строки).
- Читать или записывать.
Однако тут мы сталкиваемся с другой проблемой. Диспетчеру кэша нужно положить данные в память ДО того, как они понадобятся исполнителю запросов. Иначе тому придётся ждать их получения с медленного диска.
5.1.1. Упреждение
Исполнитель запросов знает, какие данные ему понадобятся, поскольку ему известен весь план, то, какие данные содержатся на диске и статистика.
Когда исполнитель обрабатывает первую порцию данных, он просит диспетчер кэша заранее подгрузить следующую порцию. А когда переходит к её обработке, то просит ДК подгрузить третью и подтверждает, что первую порцию можно удалить из кэша.
Диспетчер кэша хранит эти данные в буферном пуле. Он также добавляет к ним сервисную информацию (триггер, latch), чтобы знать нужны ли они ещё в буфере.
Иногда исполнитель не знает, какие данные ему будут нужны, или некоторые БД не имеют подобного функционала. Тогда используется спекулятивное упреждение (speculative prefetching) (например, если исполнитель запрашивает данные 1, 3, 5, то наверняка запросит в будущем 7, 9, 11) или последовательное упреждение (sequential prefetching) (в данном случае ДК просто подгружает с диска следующую по порядку порцию данных.
Нельзя забывать, что буфер ограничен объёмом доступной памяти. То есть для загрузки одних данных нам приходится периодически удалять другие. Заполнение и очистка кэша потребляет часть ресурсов дисковой подсистемы и сети. Если у вас есть часто исполняемый запрос, то было бы контрпродуктивно каждый раз загружать и очищать используемые им данные. Для решения данной проблемы в современных БД используется стратегия замены буфера.
5.1.2. Стратегии замены буфера
Большинство БД (по крайне мере, SQL Server, MySQL, Oracle и DB2) используют для этого алгоритм LRU (Least Recently Used). Он предназначен для поддержания в кэше тех данных, которые недавно использовались, а значит велика вероятность, что они могут понадобиться снова.
Для облегчения понимания работы алгоритма примем, что данные в буфере не блокируются триггерами (latch), а значит могут быть удалены. В нашем примере буфер может хранить три порции данных:
- Диспетчер кэша используется данные 1 и кладёт их в пустой буфер.
- Затем он использует данные 4 и тоже отправляет их в буфер.
- То же самое делается и с данными 3.
- Далее берутся данные 9. Но буфер-то уже заполнен. Поэтому из него удаляются данные 1, так как они не использовались дольше всего. После этого в буфер помещаются данные 9.
- Диспетчер кэша снова использует данные 4. Они уже есть в буфере, поэтому помечаются как последние использованные.
- Снова становятся востребованы данные 1. Чтобы их поместить в буфер, из него удаляются данные 3, как не использовавшиеся дольше всего.
Улучшения алгоритма
Чтобы этого не произошло, в некоторых БД используются специальные правила. Согласно документации Oracle :
«Для очень больших таблиц обычно используется прямой доступ, то есть блоки данных считываются напрямую, чтобы избежать переполнения буфера кэша. Для таблиц среднего размера может использоваться как прямой доступ, так и чтение из кэша. Если система решит использовать кэш, то БД помещает блоки данных в конец списка LRU, чтобы предотвратить очистку буфера».
Также используется улучшенная версия LRU - LRU-K. В SQL Server применяется LRU-K при К = 2. Суть этого алгоритма в том, что при оценке ситуации он учитывает больше информации о прошлых операциях, а не только запоминает последние использованные данные. Буква К в названии означает, что алгоритм принимает во внимание, какие данные использовались последние К раз. Им присваивается определённый вес. Когда в кэш загружаются новые данные, то старые, но часто используемые не удаляются, потому что их вес выше. Конечно, если данные больше не используются, то они всё-таки будут удалены. И чем дольше данные остаются невостребованными, тем сильнее уменьшается со временем их вес.
Вычисление веса довольно накладно, поэтому в SQL Server используется LRU-K при К равном всего лишь 2. При некотором увеличении значения К эффективность алгоритма улучшается. Вы можете ближе познакомиться с ним благодаря .
Другие алгоритмы
Конечно, LRU-K не единственное решение. Существуют также 2Q и CLOCK (оба похожи на LRU-K), MRU (Most Recently Used, в котором используется логика LRU, но применяется другое правило, LRFU (Least Recently and Frequently Used) и т.д. В некоторых БД можно выбирать, какой алгоритм будет использоваться.
5.1.3. Буфер записи
Мы говорили только о буфере чтения, но БД используют и буферы записи, которые накапливают данные и сбрасывают на диск порциями, вместо последовательной записи. Это позволяет экономить операции ввода/вывода.
Помните, что буферы хранят страницы
(неделимые единицы данных), а не ряды из таблиц. Страница в буферном пуле называется «грязной», если она модифицирована, но не записана на диск. Есть много разных алгоритмов, с помощью которых выбирается время записи грязных страниц. Но это во многом связано с понятием транзакций.
5.2. Диспетчер транзакций
В его обязанности входит отслеживание, чтобы каждый запрос исполнялся с помощью собственной транзакции. Но прежде чем поговорить о диспетчере, давайте проясним концепцию ACID-транзакций.5.2.1. «Под кислотой» (игра слов, если кто не понял)
ACID-транзакция (Atomicity, Isolation, Durability, Consistency) - это элементарная операция, единица работы, которая удовлетворяет 4 условиям:
- Атомарность (Atomicity). Нет ничего «меньше» транзакции, никакой более мелкой операции. Даже если транзакция длится 10 часов. В случае неудачного выполнения транзакции система возвращается в состояние «до», то есть транзакция откатывается.
- Изолированность (Isolation) . Если в одно время выполняются две транзакции А и В, то их результат не должен зависеть от того, завершилась ли одна из них до, во время или после исполнения другой.
- Надёжность (Durability). Когда транзакция зафиксирована (commited), то есть успешно завершена, использовавшиеся ею данные остаются в БД вне зависимости от возможных происшествий (ошибки, падения).
- Консистентность (согласованность) (Consistency). В БД записываются только валидные данные (с точки зрения реляционных и функциональных связей). Консистентность зависит от атомарности и изолированности.
Во время выполнения какой-либо транзакции можно исполнять различные SQL-запросы на чтение, создание, обновление и удаление данных. Проблемы начинаются, когда две транзакции используют одни и те же данные. Классический пример - перевод денег со счёта А на счёт Б. Допустим, у нас есть две транзакции:
- Т1 берёт $100 со счёта А и отправляет их на счёт Б.
- Т2 берёт $50 со счёта А и тоже отправляет их на счёт Б.
- Атомарность позволяет быть уверенным, что какое бы событие не произошло в ходе Т1 (падение сервера, сбой сети), не может случиться так, что $100 будут списаны с А, но не придут на Б (в противном случае говорят о «несогласованном состоянии»).
- Изолированность говорит о том, что даже если Т1 и Т2 осуществляются одновременно, в результате с А будет списано $100 и та же сумма поступит на Б. Во всех остальных случаях опять говорят о несогласованном состоянии.
- Надёжность позволяет не беспокоиться о том, что Т1 исчезнет, если база упадёт сразу после коммита Т1.
- Консистентность предотвращает возможность создания денег или их уничтожения в системе.
Многие БД не обеспечивают полную изолированность по умолчанию, поскольку это приводит к огромным издержкам в производительности. В SQL используется 4 уровня изолированности:
- Сериализуемые транзакции (Serializable). Наивысший уровень изолированности. По умолчанию используется в SQLite. Каждая транзакция исполняется в собственной, полностью изолированной среде.
- Повторяемое чтение (Repeatable read).
По умолчанию используется в MySQL. Каждая транзакция имеет свою среду, за исключением одной ситуации: если транзакция добавляет новые данные
и успешно завершается, то они будут видимы для других, всё ещё выполняющихся транзакций. Но если транзакция модифицирует данные
и успешно завершается, то эти изменения будут не видны для всё ещё выполняющихся транзакций. То есть для новых данных принцип изолированности нарушается.
Например, транзакция А выполняет
SELECT count(1) from TABLE_X
Потом транзакция Б добавляет в таблицу Х и коммитит новые данные. И если после этого транзакция А снова выполняет count(1), то результат будет уже другим.Это называется фантомным чтением.
- Чтение зафиксированных данных (Read commited)
. По умолчанию используется в Oracle, PostgreSQL и SQL Server. Это то же самое, что и повторяемое чтение, но с дополнительным нарушением изолированности. Допустим, транзакция А читает данные; затем они модифицируются или удаляются транзакцией Б, которая коммитит эти действия. Если А снова считает эти данные, то она увидит изменения (или факт удаления), сделанные Б.
Это называется неповторяемым чтением (non-repeatable read).
- Чтение незафиксированных данных (Read uncommited).
Самый низкий уровень изолированности. К чтению зафиксированных данных добавляется новое нарушение изолированности. Допустим, транзакция А читает данные; затем они модифицируются транзакцией Б (изменения не коммитятся, Б всё ещё выполняется). Если А считает данные снова, то увидит сделанные изменения. Если же Б будет откачена назад, то при повторном чтении А не увидит изменений, словно ничего и не было.
Это называется грязным чтением.
Большинство БД добавляют собственные уровни изолированности (например, на основе снэпшотов, как в PostgreSQL, Oracle и SQL Server). Также во многих БД не реализованы все четыре вышеописанных уровня, особенно чтение незафиксированных данных.
Пользователь или разработчик может сразу же после установления соединения переопределить уровень изолированности по умолчанию. Для этого достаточно добавить очень простую строчку кода.
5.2.2. Управление параллелизмом
Главное, для чего нам нужны изолированность, согласованность и атомарность, это возможность осуществлять операции записи над одними и теми же данными (добавлять, обновлять и удалять).
Если все транзакции будут только читать данные, то смогут работать одновременно, не влияя на другие транзакции.
Если хотя бы одна транзакция изменяет данные, читаемые другими транзакциями, то БД нужно найти способ скрыть от них эти изменения. Также нужно удостовериться, что сделанные изменения не будут удалены другими транзакциями, которые не видят изменённых данных.
Это называется управлением параллелизмом.
Проще всего просто выполнять транзакции поочерёдно. Но такой подход обычно неэффективен (задействуется лишь одно ядро одного процессора), и к тому же теряется возможность масштабирования.
Идеальный способ решения проблемы выглядит так (при каждом создании или отмене транзакции):
- Мониторить все операции каждой транзакции.
- Если две и более транзакции конфликтуют из-за чтения/изменения одних и тех же данных, то менять очерёдность операций внутри участников конфликта, чтобы свести к минимуму количество причин.
- Выполнять конфликтующие части транзакций в определённом порядке. Неконфликтующие транзакции в это время выполняются параллельно.
- Иметь в виду, что транзакции могут быть отменены.
5.2.3. Диспетчер блокировок
Для решения вышеописанной проблемы во многих БД используются блокировки (locks) и/или версионность данных.
Если транзакции нужны какие-то данные, то она блокирует их. Если другой транзакции они тоже потребовались, то её придётся ждать, пока первая транзакция не снимет блокировку.
Это называется эксклюзивной блокировкой.
Но слишком расточительно использовать эксклюзивные блокировки в случаях, когда транзакциям нужно всего лишь считать данные. Зачем мешать чтению данных? В таких случаях используются совместные блокировки. Если транзакции нужно считать данные, они применяет к ним совместную блокировку и читает. Это не мешает другим транзакциям тоже применять совместные блокировки и читать данные. Если же какой-то из них нужно изменить данные, то ей придётся подождать, пока все совместные блокировки не будут сняты. Только после этого она сможет применить эксклюзивную блокировку. И тогда уже всем остальным транзакциям придётся ждать её снятия, чтобы считывать эти данные.
Диспетчер блокировок - это процесс, который применяет и снимает блокировки. Они хранятся в хэш-таблице (ключами являются блокируемые данные). Диспетчер знает для всех данных, какие транзакции применили блокировки или ждут их снятия.
Взаимная блокировка (deadlock)
Использование блокировок может привести к ситуации, когда две транзакции бесконечно ожидают снятия блокировок:
Здесь транзакция А эксклюзивно заблокировала данные 1 и ожидает освобождения данных 2. В то же время транзакция Б эксклюзивно заблокировала данные 2 и ожидает освобождения данных 1.
При взаимной блокировке диспетчер выбирает, какую транзакцию отменить (откатить назад). И решение принять не так просто:
- Будет ли лучше убить транзакцию, которая изменила последний набор данных (а значит, откат будет наименее болезненным)?
- Будет ли лучше убить самую молодую транзакцию, поскольку пользователи других транзакций прождали дольше?
- Будет ли лучше убить транзакцию, которой требуется меньше времени для завершения?
- На сколько других транзакций повлияет откат?
Представим хэш-таблицу в виде диаграммы, как на иллюстрации выше. Если на диаграмме присутствует циклическая связь, то взаимная блокировка подтверждена. Но поскольку проверять на наличие циклов достаточно дорого (ведь диаграмма, на которой отражены все блокировки, будет весьма большой), зачастую используется более простой подход: использование таймаутов. Если блокировка не снимается в течение определённого времени, значит транзакция вошла в состояние взаимной блокировки.
Перед наложением блокировки диспетчер также может проверить, не приведёт ли это к возникновению взаимной блокировки. Но чтобы однозначно на это ответить, тоже придётся потратиться на вычисления. Поэтому подобные предпроверки зачастую представлены в виде набора базовых правил.
Двухфазная блокировка
Проще всего полная изолированность обеспечивается, когда блокировка применяется в начале и снимается в конце транзакции. Это означает, что транзакции перед началом приходится дожидаться снятия всех блокировок, а применённые ею блокировки снимаются лишь по завершении. Такой подход можно применять, но тогда теряется куча времени на все эти ожидания снятия блокировок.
В DB2 и SQL Server применяется протокол двухфазной блокировки, при котором транзакция делится на две фазы:
- Фазу подъёма (growing phase) , когда транзакция может только применять блокировки, но не снимать их.
- Фазу спада (shrinking phase) , когда транзакция может только снимать блокировки (с данных, которые уже обработаны и не будут обрабатываться снова), но не применять новые.
До транзакции А X = 1 и Y = 1. Она обрабатывает данные Y = 1, которые были изменены транзакцией В уже после начала транзакции А. В связи с принципом изолированности транзакция А должна обрабатывать Y = 2.
Цели, решаемые с помощью этих двух простых правил:
- Снимать блокировки, которые больше не нужны, чтобы уменьшить время ожидания других транзакций.
- Предотвращать случаи, когда транзакция получают данные, модифицированные ранее запущенной транзакцией. Такие данные не совпадают с запрашиваемыми.
Конечно, реальные БД используют более сложные системы, больше видов блокировок и с большей гранулярностью (блокировки строк, страниц, партиций, таблиц, табличных пространств), но суть та же.
Версионность данных
Ещё один способ решения проблемы конфликта транзакций - использование версионности данных.
- Все транзакции могут модифицировать одни и те же данные в одно и то же время.
- Каждая транзакция работает с собственной копией (версией) данных.
- Если две транзакции изменяют одни и те же данные, то принимается только одна из модификаций, другая будет отклонена, а сделавшая её транзакция будет откачена (и, может быть, перезапущена).
- Читающие транзакции не блокируют записывающие, и наоборот.
- Неповоротливый диспетчер блокировок не оказывает влияния.
Оба подхода - блокировки и версионность - имеют плюсы и минусы, многое зависит от того, в какой ситуации они применяются (больше чтений или больше записей). Можете изучить очень хорошую презентацию , посвящённую реализации мультиверсионного управления параллелизмом в PostgreSQL.
В некоторых БД (DB2 до версии 9.7, SQL Server) используются только блокировки. Другие, вроде PostgreSQL, MySQL и Oracle, используются комбинированные подходы.
Примечание: версионность оказывает интересное влияние на индексы. Иногда в уникальном индексе появляются дубликаты, индекс может содержаться больше записей, чем строк в таблице и т.д.
Если часть данных считывается при одном уровне изолированности, а потом он увеличивается, то вырастает количество блокировок, а значит теряется больше времени на ожидания транзакций. Поэтому большинство БД не используют по умолчанию максимальный уровень изолированности.
Как обычно, за более подробной информацией обращайтесь к документации: MySQL , PostgreSQL , Oracle .
5.2.4. Диспетчер логов
Как мы уже знаем, ради увеличения производительности БД хранит часть данных в буферной памяти. Но если сервер падает во время коммита транзакции, то находящиеся в памяти данные будут потеряны. А это нарушает принцип надёжности транзакций.
Конечно, можно всё писать на диск, но при падении вы останетесь с недописанными данными, а это уже нарушение принципа атомарности.
Любые изменения, записанные транзакцией, должны быть отменены или завершены.
Это делается двумя способами:
- Теневые копии/страницы. Каждая транзакция создаёт собственную копию БД (или её часть), и работает с этой копией. В случае ошибки копия удаляется. Если всё прошло успешно, то БД мгновенно переключается на данные из копии с помощью одной уловки на уровне файловой системы, а потом удаляет «старые» данные.
- Лог транзакции. Это специальное хранилище. Перед каждой записью на диск БД пишет информацию в лог транзакции. Так что в случае сбоя БД будет знать, как удалить или завершить незавершённую транзакцию.
В больших БД с многочисленными транзакциями теневые копии/страницы занимают невероятно много места в дисковой подсистеме. Поэтому в современных БД используется лог транзакции. Он должен размещаться в защищённом от сбоев хранилище.
Большинство продуктов (в частности, Oracle, SQL Server , DB2 , PostgreSQL , MySQL и SQLite) работают с логом транзакции через протокол WAL (Write-Ahead Logging). Данные протокол содержит три правила:
- Каждая модификация в БД должна сопровождаться записью в лог, и она должна вноситься ДО того, как данные будут записаны на диск.
- Записи в логе должны располагаться в соответствии с очерёдностью соответствующих событий.
- Когда транзакция коммитится, запись об этом должна вноситься в лог ДО момента успешного завершения транзакции.
За выполнением этих правил следит диспетчер логов. Логически он расположен между диспетчером кэша и диспетчером доступа к данным. Диспетчер логов регистрирует каждую операцию, выполняемую транзакциями, до момента записи на диск. Вроде верно?
НЕВЕРНО! После всего, через что мы с вами прошли в этой статье, пора бы уже запомнить, что всё связанное с БД подвергается проклятью «эффекта базы данных». Если серьёзно, то проблема в том, что нужно найти способ писать в лог, при этом сохраняя хорошую производительность. Ведь если лог транзакций работает медленно, то он тормозит все остальные процессы.
ARIES
В 1992 год исследователи из IBM создали расширенную версию WAL, которую назвали ARIES. В том или ином виде ARIES используется большинством современных БД. Если вы захотите поглубже изучить этот протокол, можете проштудировать соответствующую работу .
Итак, ARIES расшифровывается как A lgorithms for R ecovery and I solation E xploiting S emantics. У этой технологии две задачи:
- Обеспечить хорошую производительность при записи логов.
- Обеспечить быстрое и надёжное восстановление.
- Пользователь отменил её.
- Ошибка сервера или сети.
- Транзакция нарушила целостность БД. Например, вы применили к колонке условие UNIQUE, а транзакция добавила дубликат.
- Наличие взаимных блокировок.
Как это возможно? Чтобы ответить на это, нужно сначала разобраться с тем, какая информация сохраняется в логе.
Логи
Каждая операция (добавления/удаления/изменения) во время выполнения транзакции ведёт к появлению записи в логе. Запись содержит:
- LSN (Log Sequence Number) . Это уникальный номер, значение которого определяется хронологическим порядком. То есть если операция А произошла до операции Б, LSN для А будет меньше LSN для Б. В реальности способ генерирования LSN сложнее, поскольку он связан и со способом хранения лога.
- TransID. Идентификатор транзакции, осуществившей операцию.
- PageID . Место на диске, где находятся изменённые данные.
- PrevLSN . Ссылка на предыдущую запись в логе, созданную той же транзакцией.
- UNDO
. Способ отката операции.
Например, если была проведена операция обновления, то в UNDO записывается предыдущее значение/состояние изменённого элемента (физический UNDO) или обратная операция, позволяющая вернуться в предыдущее состояние (логический UNDO). В ARIES используется только логический, с физическим работать очень тяжело.
- REDO . Способ повтора операции.
Насколько известно, UNDO не используется только в PostgreSQL. Вместо этого используется сборщик мусора, убирающий старые версии данных. Это связано с реализацией версионности данных в этой СУБД.
Чтобы вам было легче представить состав записи в логе, вот визуальный упрощённый пример, в котором выполняется запрос UPDATE FROM PERSON SET AGE = 18;. Пусть он исполняется в транзакции номер 18:
Каждый лог имеет уникальный LSN. Связанные логи относятся к одной и той же транзакции, причём линкуются они в хронологическом порядке (последний лог списка относится к последней операции).
Буфер логов
Чтобы запись в лог не превратилась в узкое место системы, используется буфер логов.
Когда исполнитель запросов запрашивает модифицированные данные:
- Диспетчер кэша хранит их в буфере.
- Диспетчер логов хранит в собственном буфере соответствующий лог.
- Исполнитель запросов определяет, завершена ли операция, и, соответственно, можно ли запрашивать изменённые данные.
- Диспетчер логов сохраняет нужную информацию в лог транзакции. Момент внесения этой записи задаётся алгоритмом.
- Диспетчер кэша записывает изменения на диск. Момент осуществления записи также задаётся алгоритмом.
Политики STEAL и FORCE
Для увеличения производительности шаг номер 5 нужно делать после коммита, поскольку в случае сбоя всё ещё возможно восстановить транзакцию с помощью REDO. Это называется «политика NO-FORCE».
Но БД может выбрать и политику FORCE ради уменьшения нагрузки во время восстановления. Тогда шаг номер 5 выполняется до коммита.
Также БД выбирает, записывать ли данные на диск пошагово (политика STEAL) или, если диспетчер буфера должен дождаться коммита, записать всё разом (NO-STEAL). Выбор зависит от того, что вам нужно: быструю запись с долгим восстановлением или быстрое восстановление?
Как упомянутые политики влияют процесс восстановления:
- Для STEAL/NO-FORCE нужны UNDO и REDO. Производительность высочайшая, но более сложная структура логов и процессов восстановления (вроде ARES). Эту комбинацию политик использует большинство БД.
- Для STEAL/FORCE нужен только UNDO.
- Для NO-STEAL/NO-FORCE - только REDO.
- Для NO-STEAL/FORCE вообще ничего не нужно. Производительность в данном случае самая низкая, и требуется огромное количество памяти.
Итак, как нам можно использовать наши замечательные логи? Предположим, что новый сотрудник порушил БД (правило №1: всегда виноват новичок!). Вы её перезапускаете и начинается процесс восстановления.
ARIES восстанавливает в три этапа:
- Анализ . Считывается весь лог транзакции, чтобы можно было восстановить хронологию событий, произошедших в процессе падения базы. Это помогает определить, какую транзакцию нужно откатить. Откатываются все транзакции без приказа о коммите. Также система решает, какие данные должны были записаться на диск во время сбоя.
- Повтор
. Для обновления БД до состояния перед падением используется REDO. Его логи обрабатываются в хронологическом порядке. Для каждого лога считывается LSN страницы на диске, содержащей данные, которые нужно изменить.
Если LSN(страницы_на_диске)>=LSN(записи_в_логе), то значит данные уже были записаны на диск перед сбоем. Но значение было перезаписано операцией, которая была выполнена после записи в лог и до сбоя. Так что ничего не сделано, на самом деле.
Если LSN(страницы_на_диске)
Повтор выполняется даже для транзакций, которые будут откачены, потому что это упрощает процесс восстановления. Но современные БД наверняка этого не делают.
- Отмена. На этом этапе откатываются все незавершённые на момент сбоя транзакции. Процесс начинается с последних логов каждой транзакции и обрабатывает UNDO в обратном хронологическом порядке с помощью PrevLSN.
Если транзакция отменена «вручную», или диспетчером блокировок, или из-за сбоя сети, то этап анализа не нужен. Ведь информация для REDO и UNDO содержится в двух таблицах, размещённых в памяти:
- В таблице транзакций (тут хранятся состояния всех текущих транзакций).
- В таблице грязных страниц (здесь содержится информация о том, какие данные нужно записать на диск).
Этап анализа нужен как раз для восстановления обеих таблиц с помощью информации из лога транзакций. Для ускорения этого этапа в ARIES используются контрольные точки. На диск время от времени записывается содержимое обеих таблиц, а также последний на момент записи LSN. Так что во время восстановления анализируются только логи, следующие после этого LSN.
6. Заключение
В качестве дополнительного обзорного чтива про базы данных можно порекомендовать статью Architecture of a Database System . Это хорошее введение в тему, написанное довольно понятным языком.Если вы внимательно прочитали весь вышеизложенный материал, то наверняка получили представление о том, насколько велики возможности баз данных. Однако в этой статье не затронуты другие важные проблемы:
- Как управлять кластеризованными БД и глобальными транзакциями.
- Как получить снэпшот, если база всё работает.
- Как эффективно хранить и сжимать данные.
- Как управлять памятью.
Итак, если вас кто-нибудь спросит, а как же работают базы данных, то вместо того, чтобы плюнуть и уйти, вы можете ответить:
Теги: Добавить метки