В настоящее время ни один веб-сайт или серьёзное приложение не может обойтись без использования баз данных. Они используются для хранения, систематизации и группировки данных, благодаря чему обеспечивается простота доступа к данным и целостность информации. Для создания, управления, администрирования и использования баз данных используются специализированные программы или группы программ – системы управления базами данных (DBMS – Database Management System).
Развитие СУБД началось в середине 60-х годов XX века при разработке космических программ. Первой полноценной СУБД стала иерархическая система IMS (Information Management System).
Данная система в наши дни также используется в качестве основной иерархической СУБД на высокопроизводительных серверах. IMS является безопасным, надежным программным обеспечением с высокой пропускной способностью для обработки онлайн-транзакция и пакетной обработки.
1. Актуальность темы
С появлением технически более сложных программных комплексов прямо пропорционально возрастает потребность в хранении и обработке больших объемов информации. Это приводит к тому, что объемы хранимой информации в базах данных превосходят физические ограничения централизованных систем. Как следствие, снижается производительность, отказоустойчивость и подвергается риску целостность хранимой информации.
В современных подходах к разработке всё большую значимость приобретают процессы децентрализации. На протяжении последних десятилетий разработчики стремятся проектировать географически распределенные базы данных. Данный подход позволяет повысить производительность БД, улучшить защиту хранимой информации, обеспечить эффективные средства репликации данных. Однако, для достижения вышеуказанных преимуществ необходимо применять эффективные методы проектирования распределенных БД.
2. Цель и задачи исследования, планируемые результаты
Целью исследования является разработка методов проектирования распределенной базы данных, которые смогут децентрализовать базу данных, разбив ее на фрагменты. Полученные фрагменты будут размещены в узлах вычислительной сети. На основании полученных методов необходимо создать алгоритмы для программного комплекса, результатами работы которых будут повышение эффективности обработки запросов к распределенной базе данных, репликация данных, обеспечение защиты хранимых данных.
База данных ‘Учет решений по уголовным делам’
... системы «УЧЕТ РЕШЕНИЙ ПО УГОЛОВНЫМ ДЕЛАМ». Разработанный программный продукт должен частично или полностью заменить стандартные методы организации информации в работе следователей. Задачи программы: нормализация базы данных ... Создание базы данных и объектов базы данных Резервное копирование Цель данной работы - создать базу данных в СУБД Microsoft SQL Server 2008, объекты базы данных, распределить ...
Основные задачи исследования:
- Исследование характеристик распределенных систем обработки данных.
- Изучение основных задач, входящих в процесс проектирования распределенных баз данных.
- Исследование задач фрагментации БД, размещения фрагментов в узлах вычислительной сети.
- Формирование стратегии исполнения запросов.
- Выбор и обоснование критерия эффективности распределенной БД.
- Разработка алгоритмов, описывающих методы фрагментации и размещения фрагментов. Формирование архитектуры распределенной БД.
- Внедрение распределенной БД в программный комплекс.
Объект исследования : распределенная база данных.
Предмет исследования : модели и алгоритмы программного комплекса, предназначенные для описания методики децентрализации базы данных.
В рамках магистерской работы планируется получение актуальных научных результатов по следующим направлениям:
- Формирование задачи проектирования распределенной базы данных, учитывающей особенности фрагментации БД и размещения полученных фрагментов.
- Формирование стратегии исполнения запросов.
- Выбор и обоснование критерия эффективности распределенной БД, учитывающего влияние физических параметров системы на скорость обработки запросов и коэффициент готовности транзакции.
В качестве практических результатов планируется разработка высоконагруженной распределенной базы данных и ее внедрение в готовый программный комплекс по онлайн продаже билетов.
3. Обзор исследований и разработок
3.1 Обзор международных источников
[Электронный ресурс]//URL: https://urveda.ru/referat/personalnyie-bazyi-dannyih-problema-raskolotyih-baz/
Создание распределенной СУБД предполагает не только разработку функциональных модулей, как таковых, но и формальное математическое описание модели хранения данных и манипулирования с ними. При проектировании распределенных СУБД наиболее широко применяются алгебраические методы описания операций. Среди них можно выделить работы Е. Кодда по реляционной алгебре [1] и формальное описание БД как объектно-ориентированной системы, предложенное К. Бири. [2]
Следует отметить статьи Б. Талхайма [3] , посвященные проектированию СУБД средствами многосортной алгебры с использованием других алгебраических методов, таких как HERM-алгебра, основанная на машине абстрактных состояний Ю. Гуревича. Использование алгебраических подходов позволяет провести формальное описание логического плана выполнения запроса (уровень языка запроса), его трансляцию в физический план выполнения (уровень внутренней обработки запросов) и, как следствие, иметь возможность проведения анализа его оптимизации и выполнения по микрооперациям физического плана [4] .
Также широко применяется классификация М. Стоунбрейкера для многопроцессорных вычислительных комплексов (МВК) [5-6] .
Виды защиты, используемые в автоматизированных информационных системах
... алгоритмы, схемы и механизмы безопасного функционирования системы. субъектно-объектная модель Рис. 1. База данных АИС в моделях безопасности данных Определяются два основополагающих принципа безопасности функционирования информационных систем: персонализация разграничение полномочий субъектов монитором Рис. ...
3.2 Обзор национальных источников
[Электронный ресурс]//URL: https://urveda.ru/referat/personalnyie-bazyi-dannyih-problema-raskolotyih-baz/
В связи с постоянным увеличением объема данных в настоящее время остро стоит вопрос о необходимости модернизации устаревших систем. Шалтунович А.В. [9] в своей научной статье отражает проблему больших данных относительно систем управления базами данных и распределенных информационных систем, ставшую на сегодняшний день ключевой в ИТ-индустрии.
Одним из наиболее приоритетных требований, выдвигаемых при проектировании любых современных систем, является сохранность и целостность данных. Белоусов В.Е. [8] в своей работе описывается систематизацию подходов к выполнению репликации данных, предлагает алгоритм выполнения репликации по текущему состоянию.
Распределенные системы обработки данных имеют ряд особенностей. Наиболее емко данные особенности описаны в статье Цветкова В.Я., Алпатова А.Н [7] . Также в статье раскрываются понятия распределенной системы и распределенной информационной системы. Дается классификация распределенных систем. В частности, по типу предоставляемых ресурсов: распределенные вычислительные системы, распределенные информационные системы, семантический Грид.
3.3 Обзор локальных источников
[Электронный ресурс]//URL: https://urveda.ru/referat/personalnyie-bazyi-dannyih-problema-raskolotyih-baz/
В Донецкой национальном техническом университете разрабатывались научные статьи, посвященные оптимизации запросов к серверам распределенной базы данных, подходы к оптимизации распределения данных. В статье Барановой С.С. [10] приводится способ оптимизации работы распределенной базы данных путём оптимизации распределения данных по узлам компьютерной сети. Заславский В.А. [11] в своей статье применяет муравьиный алгоритм для решения задачи оптимизации запросов.
4. Фрагментация баз данных
Фрагментация базы данных, или шардинг – это шаблон архитектуры базы данных, связанный с горизонтальным секционированием (разделение строк одной таблицы на несколько различных таблиц, называемых разделами).
Каждый раздел имеет одинаковую схему и столбцы, но разные строки. Соответственно, данные, хранящиеся в каждом из них, уникальны и не зависят от данных, хранящихся в других разделах.
Принято сравнить горизонтальное секционирование с вертикальным. В таблице с вертикальным секционированием целые столбцы разделяются и помещаются в отдельные таблицы. Данные, содержащиеся в одном вертикальном разделе, не зависят от данных во всех остальных таких разделах, каждый из них содержит как отдельные строки, так и отдельные столбцы. На рисунке 1 продемонстрирован процесс горизонтального и вертикального секционирования таблицы.
Фрагментация включает в себя разбиение данных на две или несколько меньших частей, которые называются логическими сегментами. Затем они распределяются по отдельным узлам базы данных, – так называемым физическим сегментам, – которые могут содержать несколько логических сегментов. Данные, хранящиеся во всех сегментах, представляют собой целый набор логических данных.
Сегментированная базы данных – пример архитектуры без общего доступа. Это означает, что все сегменты автономны; они не используют одни и те же данные или вычислительные ресурсы. В некоторых случаях, однако, может иметь смысл копировать определенные таблицы в каждый сегмент, чтобы использовать их для справки. Например, есть база данных для приложения, которая зависит от фиксированных коэффициентов пересчета для измерений веса. Реплицируя таблицу, содержащую необходимые данные о коэффициенте конверсии, в каждый сегмент, возможно предоставить каждому сегменту все данные, необходимые для запросов.
Нормативно- правовая база в системе ЭК
... регулирования, рыночно ориентированный подход к ЭК, который мог бы способствовать появлению прозрачной и предсказуемой правовой ... государственной власти в указанной области деятельности. В области права и в ... реестра владельцев ценных бумаг, использующая электронную базу данных». Тем не менее, в ряде российских ... назвать такие, как споры по коммерческим операциям в Интернет, использованию доменных ...
Часто фрагментация реализуется на прикладном уровне, то есть приложение включает в себя код, который определяет, какой сегмент передавать на чтение и запись. Однако некоторые системы управления базами данных имеют встроенные возможности фрагментации, что позволяет реализовать ее непосредственно на уровне базы данных.
4.1 Преимущества фрагментации БД
Основное преимущество шардинга заключается в том, что он может упростить горизонтальное масштабирование (scaling out).
Горизонтальное масштабирование – это добавление новых машин к существующему стеку, что позволяет распределить нагрузку и быстрее обрабатывать больший объем трафика. Эта практика часто сравнивается с вертикальным масштабированием (scaling up), которое включает в себя обновление аппаратного обеспечения существующего сервера, обычно путем добавления большего объема ОЗУ или ЦП.
Поддерживать реляционную базу данных, работающую на одной машине, и масштабировать ее вертикально по мере необходимости, обновляя ее вычислительные ресурсы, относительно просто. Однако, в конечном счете любая несегментированная база данных будет ограничена с точки зрения хранения и вычислительной мощности, поэтому возможность горизонтального масштабирования делает вашу установку гораздо более гибкой.
Другой причиной, по которой некоторые выбирают архитектуру фрагментированной БД, является сокращение времени ответа на запрос. При отправке запроса к не фрагментированной базе данных поиск выполняется по каждой строке в таблице, прежде чем будет найден набор искомых результатов. В приложении с большой монолитной базой данных запросы могут обрабатываться очень медленно. В сегментированной таблице при поиске просматривается меньшее количество строк, а результаты возвращаются намного быстрее.
Фрагментация может также сделать приложение более надежным за счет смягчения последствий сбоев. Если ваше приложение или веб-сайт использует монолитную базу данных, сбой может привести к недоступности всего приложения. Однако при использовании фрагментированной базы данных отключение может повлиять только на один сегмент данных. Некоторые части приложения или веб-сайта могут стать недоступными, но общее воздействие все равно будет меньше, чем в случае сбоя всей базы данных.
4.2 Недостатки фрагментации БД
Хотя фрагментация базы данных может упростить масштабирование и повысить производительность, она также может накладывать определенные ограничения. В этом разделе мы обсудим некоторые из этих ограничений и ситуации, в которых лучше вообще не использовать шардинг.
Первая проблема, с которой люди сталкиваются при использовании фрагментации – это сложность правильной реализации такой архитектуры. Если фрагментировать данные неправильно, это может привести к потере данных или повреждению таблиц. Но даже если все сделано правильно, фрагментация может оказать существенное влияние на рабочие процессы вашей команды. Вместо того чтобы получать доступ к данным и управлять ими из одной точки, членам команды придется управлять данными в нескольких сегментах, что может помешать работе некоторых групп.
Нормативно-правовая база и методическая основа делопроизводства. ...
... Афанасьева. - Москва, 2016. – 483 с. 24. Борис, И.В. Современная нормативно-правовая база делопроизводства / И.В. Борис // Научно-практическая реализация творческого потенциала молодёжи: ... 503 с. 30. Гончаренко, А.Н. Возможности оптимизации документооборота компании с учетом нормативно-правового регулирования делопроизводства Российской Федерации / А.Н. Гончаренко // Вестник Института мировых ...
Проблема, с которой иногда сталкиваются после фрагментации базы данных, заключается в том, что сегменты в конечном итоге сильно разнятся в размерах. Предположим, у вас есть база данных с двумя отдельными сегментами: один для клиентов, чьи фамилии начинаются с букв от А до М, а второй – для тех, чьи фамилии начинаются с букв от Н до Я. Однако приложение обслуживает очень много пользователей, чьи фамилии начинаются с буквы Г. Соответственно, первый сегмент постепенно накапливает больше данных, чем второй. Это приводит к замедлению работы приложения при обслуживании значительной части ваших пользователей. В этом случае любые преимущества фрагментации базы данных сводятся на нет замедлениями и сбоями. Скорее всего, базу данных необходимо будет восстановить и перенастроить, чтобы обеспечить более равномерное распределение данных.
Другим существенным недостатком является то, что после фрагментации БД может быть очень трудно вернуть ее к предыдущей архитектуре. Резервные копии базы данных, сделанные до ее фрагментации, не содержат данных, записанных после фрагментации. Следовательно, для восстановления исходной архитектуры потребуется объединить новые сегментированные данные со старыми резервными копиями или, наоборот, преобразовать сегментированную БД обратно в единую БД, что потребует больших затрат и времени.
4.3 Виды фрагментированных архитектур
При выполнении запросов или распределении входящих данных в сегментированные таблицы или БД важно, чтобы они передавались в правильный сегмент. В противном случае это может привести к потере данных или крайне медленной обработке запросов. В этом разделе мы рассмотрим несколько распространенных архитектур фрагментации, каждая из которых использует немного другой процесс для распределения данных между сегментами.
4.3.1 Фрагментация по интервалам
Фрагментация по интервалам подразумевает сегментирование данных на основе диапазонов заданного значения. Предположим, у вас есть база данных, в которой хранится информация обо всех продуктах в каталоге. Вы можете создать несколько разных сегментов и отделить информацию о каждом продукте в зависимости от ценового диапазона, в который они попадают (рисунок 2).
Основное преимущество этой модели состоит в том, что она относительно проста в реализации. Каждый сегмент содержит различный набор данных, но все они имеют идентичную схему, а также исходную базу данных. Код приложения просто читает, в какой диапазон попадают данные, и записывает их в соответствующий фрагмент.
С другой стороны, сегментирование по интервалу не защищает данные от неравномерного распределения, что приводит к вышеупомянутым hotspots. Из рисунке 2 видно, что даже если каждый шард содержит одинаковое количество данных, существует вероятность того, что конкретным продуктам будет уделено больше внимания, чем другим. И соответствующие сегменты, в свою очередь, получат непропорциональное количество операций чтения.
4.3.2 Фрагментация по каталогам
Для реализации этой модели необходимо создать и поддерживать справочную таблицу, которая с помощью ключа сегмента отслеживает, какие данные содержатся в том или ином сегменте. В данном контексте, справочная таблица – это таблица, которая содержит статический набор информации о том, где можно найти конкретные данные. На рисунке 3 изображен упрощенный пример сегментирования по каталогам.
Программы по восстановлению данных
... по архивации и восстановлению данных. Решить следующие задачи: 1. выявить причины удаления данных; 2. провести анализ по программам восстановления данных; 3. сделать вывод на основе проведенного исследования. Структура курсовой работы ... 16 байт программа восстановления данных узнает, когда файл был создан и в последний раз подвергался изменениям. 4. Эта ссылка на каталог, в котором находится ...
Здесь столбец Delivery Zone определяется как ключ сегмента. Данные от ключа сегмента записываются в справочную таблицу вместе с тем сегментом, в который должна быть записана каждая соответствующая строка. Это похоже на сегментирование по интервалам, но вместо определения диапазона, в который попадают данные, каждый ключ привязывается к своему определенному сегменту. Сегментирование по каталогам лучше, чем сегментирование по интервалам в тех случаях, когда ключ сегмента имеет низкую мощность связи, хранить диапазон ключей для сегмента не имеет смысла. Обратите внимание, что эта модель также отличается от сегментирования по ключам, поскольку она не обрабатывает ключ сегмента с помощью хеш-функции; она просто проверяет ключ по таблице, чтобы увидеть, куда записать данные.
Основное преимущество фрагментации по каталогам – это гибкость. Архитектура сегментирования по интервалам ограничивает пользователей диапазонами значений, а архитектура по ключам – фиксированной хеш-функцией, которую, как упоминалось ранее, впоследствии может быть чрезвычайно трудно изменить. Сегментирование по каталогам позволяет использовать любую систему или алгоритм для ввода данных в сегменты, и с помощью этого подхода сравнительно легко динамически добавлять фрагменты.
Сегментирование по каталогам является наиболее гибким из рассмотренных здесь методов, но необходимость подключаться к таблице перед каждым запросом или записью может отрицательно повлиять на производительность приложения. Кроме того, справочная таблица может стать единой точкой отказа: если она повреждена или иным образом вышла из строя, это повлияет на способность записывать или извлекать данные.
Выводы
В рамках данной работы были рассмотрены основные способы сегментирования базы данных, были выявлены особенности каждого из способов. В дальнейшем планируется применение одного из описанных методов сегментирования БД в рамках действующего проекта по онлайн продаже билетов.
Магистерская работа посвящена актуальной научной задаче исследования методов создания производительных СУБД. В рамках проведенных исследований выполнено:
- Рассмотрены методы фрагментации баз данных.
- На основании анализа литературных источников выделена структура построения производительных СУБД.
- Сформированы и проанализированы требования к производительным СУБД.
- Формирование стратегии исполнения запросов.
- Выбор и обоснование критерия эффективности распределенной БД.
- Разработка алгоритмов, описывающих методы фрагментации и размещения фрагментов. Формирование архитектуры распределенной БД.
- Внедрение распределенной БД в программный комплекс.
Дальнейшие исследования направлены на следующие этапы:
- Проектирование и реализация распределенной базы данных, учитывающей особенности фрагментации БД.
- Формирование стратегии исполнения запросов.
- Обоснование выбранного критерия эффективности распределенной БД.
При написании данного реферата магистерская работа еще не завершена. Окончательное завершение: июнь 2020 года. Полный текст работы и материалы по теме могут быть получены у автора или его руководителя после указанной даты.
База данных: подсистема «ЗАГС»
... проектированием базы данных. Концептуальная модель данных не привязана к конкретной физической реализации баз данных и ... будет создание таблиц с помощью Database Desktop. Эта программа встроена в ... = Table1Lecture_hours->Value/15;} 2.1 Общий принцип работы программы При запуске программы появляется окно, ... типы сущностей (пример): Муж; Жена; ЗАГС; Эти сущности взаимодействуют по следующей схеме ...
Список источников
[Электронный ресурс]//URL: https://urveda.ru/referat/personalnyie-bazyi-dannyih-problema-raskolotyih-baz/
- Codd E.F. A Relational Model of Data for Large Shared Data Banks – Journal
Communications of the ACM
, Vol. 13, no. 6., 1970, pp. 377—387. - Berri C. A sophisticates introduction to database normalization theory – 4th Conf. of Very Large Databases, 1978, pp. 113-124.
- Thalheim B. The HERM Algebra – Book
Entity-Relationship Modeling: Foundations of Database Technology Reading
, Department of Computer Science Brandenburg University of Technology, Germany, 2013, pp. 223-244. - Gurevich Yu. Logic and the challenge of computer science – Current Trends in Theoretical Computer Science (Borger E).
Computer Science Press, 1988, pp. 1–57.
- Stonebraker M., Aoki P.M., Litwin W., Pfeffer A., Sah A., Sidell J., Staelin C., Yu A. Mariposa: A wide-area distributed database system – The VLDB Journal the International Journal on Very Large Data Bases, no. 5, 1996, pp. 48–63.
- Hellerstein J.M., Stonebraker M. Clustering of database systems – Readings in Database Systems, 4th edition, London, 2005, pp. 651-653.
- Цветков В.Я., Алпатов А.Н. Проблемы распределенных систем – Журнал
Перспективы науки и образования №6(12)
, Москва, 2014, стр. 31-35. - Белоусов В.Е. Алгоритмы репликации данных в распределенных системах обработки информации – Автореферат к рукописи, Пенза, 2005 // [Электронный ресурс]. — Режим доступа: https://static.freereferats.ru/…
- Шалтунович А.В. Нереляционные системы хранения в условиях проблемы больших данных и распределенных вычислений – Журнал
Вестник Нижневартовского государственного университета
, Нижневартовск, 2013, стр. 31-35. - Баранова С.С. Динамическая оптимизация распределения данных по узлам вычислительной сети // Тезисы доклада на конференции
Современные информационные технологии
, Донецк, 2007. - Заславский В.А., Савкова Е.О. Оптимизация выполнения распределённых запросов // Материалы II всеукраинской научно-технической конференции студентов, аспирантов и молодых учёных – Донецьк, ДонНТУ – 2011, с. 269-273.
