Модели процессов согласования реплик в базах данных Nosql



Download 2,9 Mb.
Pdf ko'rish
bet7/67
Sana31.05.2022
Hajmi2,9 Mb.
#621123
TuriАнализ
1   2   3   4   5   6   7   8   9   10   ...   67
Bog'liq
193-Диссертация

1.2.
 
Реляционные базы данных и хранилища NoSQL
1.2.1.
 
Преимущества и недостатки реляционных баз данных 
Идея реляционной модели была предложена Коддом в 1970 в его статье [2]. 
Эта модель хорошо подходит для программирования клиент-серверных 
приложений и оказалась преобладающей технологией для хранения 
структурированных данных, включая базы данных в сети Интернет. 
Можно
 
выделить 
следующие 
преимущества 
реляционных 
БД, 
проявляющиеся в наличии:
1) теоретической основы реляционных баз данных (РБД);
2) мощного и сравнительно простого для изучения языка описания и 
манипулирования данными (языка SQL), который стал стандартом;
3) оптимизатора запросов, который выполняет декомпозицию запроса на 
более мелкие задания, что обеспечивает параллельное выполнение этих работ на 
многопроцессорных или многомашинных комплексах; 
4) механизма обеспечения правильной работы системы: ведение ACID-
транзакций [3] (атомарность, согласованность, изолированность, долговечность) и 
блокировок записей; 
5) большого числа общесистемных ресурсов (СУБД, машин баз данных, 
CASE-средств и др.). 
Упрощенная схема обработки запросов в реляционных СУБД показана на 
рисунке 1.1. 
 
SQL-запрос 1
БД
СУБД (оптимизация 
запроса)
Приложение
SQL-запрос n
Рисунок 1.1 – Упрощенная схема обработки запросов в реляционных СУБД. 
Но с ростом сложности решаемых задач и объемом обрабатываемых данных 
все более ощутимо стали проявляться недостатки реляционных БД: 


12 
1. Для реляционных баз данных характерна проблема потери соответствия 
[4]. Проявляется она в том, что реляционные БД не позволяют хранить агрегаты в 
явном виде. Например, чтобы отобразить всю информацию о клиенте и всех его 
заказах (агрегат), программист должен собрать в оперативной памяти данные из 
многих связанных между собой таблиц: клиенты, заказы, элементы заказа др. 
(рисунок 1.2) При значительном росте числа таблиц разработчик часто просто 
забывает назначение той или иной таблицы, осложняется связывание таблиц при 
выполнении запроса, т.е. существенно осложняется формирование агрегата. 
Появление множества библиотек для объектно-реляционного отображения, таких 
как Hibernate и iBATIS, не устранило проблему [4].
Идентификатор: 1
Покупатель: Петр
Продавец: Алексей
Товары:
123123123
456456456
789789789
1
2
2
25
100
75
Москва
Казань
Тула
Данные об оплате:
Владелец: Евгений
Номер карты: 0000111122223333
Срок действия: 01.01.2020
Заказы
Клиенты
Продавцы
Элементы заказа
Банковские карты
Рисунок 1.2 – Агрегирование данных в приложении. 
2. Для хранения больших объемов информации необходимо покупать 
дорогие специализированные аппаратно-программные комплексы параллельных 
систем баз данных (Teradata, Sun Oracle Database Machine и др.). Параллельные 
системы демонстрируют невысокую масштабируемость, в частности для 
поддержания требуемой отказоустойчивости [5]. При выполнении сложных 
запросов производительность системы существенно уменьшается в результате 
межмашинного обмена данными между серверами кластера [6].


13 
3. Схема базы данных состоит из подсхем, каждая из которых отражает 
предметную область какого-либо подразделения организации (предприятия). 
Модификация 
подсхемы 
одного 
подразделения 
и 
реорганизация 
соответствующих таблиц приводит к вынужденной приостановке работы 
остальных подразделений. Сейчас в качестве альтернативы централизованной 
базы данных широко используются так называемые «базы данных приложений» 
[4], т.е. подразделений. Обеспечение взаимодействия этих баз данных возлагается 
на web-сервисы. Но поддержка целостности данных и оперативности такого 
взаимодействия является непростой задачей для программиста. 
4. Возникло противоречие между необходимостью хранения больших 
объемов неструктурированных данных и необходимостью их как-то 
структурировать посредством разработки схемы базы данных. 
5. Согласно [7] репликация в распределенных реляционных базах данных 
изначально выполнялась с использованием протокола «read-one-write-all»: 
операции чтения требуют локальных блокировок и выполняются на одном узле, в 
то время как для операций записи требуются распределенные блокировки для 
всех копий записи. Атомарность из набора ACID гарантируется использованием 
двухфазной фиксации (2-Phase-Commit (2PC)) [8] в конце каждой транзакции. 
Авторы работы [9] отмечают, что подобный подход основан на том, что каждая 
операция координируется отдельно. В результате при увеличении числа реплик 
время реакции системы, вероятность возникновения конфликтов и тупиковых 
ситуаций увеличиваются по экспоненте.
Рассматривая современные тенденции в области обработки данных, 
Стоунбрейкер подчеркнул эти особенности в своей статье "Конец архитектурной 
эпохи "[10]: 
1. Реляционные СУБД были разработаны более 25 лет назад, когда 
характеристики оборудования, требования пользователей и рынки баз данных 
отличались от сегодняшних. Хотя и были расширения, но ни одна система не 
была перепроектирована с самого начала. 


14 
2. Новые рынки и варианты использования развивались с 1970-х годов, 
когда была только обработка бизнес-данных. Пользовательские интерфейсы и 
модель использования также изменились за последние несколько десятилетий от 
терминалов, когда "операторы вводили запросы", до «толстых клиентов» и веб-
приложений, когда интерактивные транзакции и прямые SQL-интерфейсы редки. 
Как попытка решить накопившиеся проблемы реляционных баз данных 
появились альтернативные средства хранения и обработки данных, получившие 
название «базы данных NoSQL» (как синоним также используется термин 
«хранилище NoSQL»). 

Download 2,9 Mb.

Do'stlaringiz bilan baham:
1   2   3   4   5   6   7   8   9   10   ...   67




Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©hozir.org 2024
ma'muriyatiga murojaat qiling

kiriting | ro'yxatdan o'tish
    Bosh sahifa
юртда тантана
Боғда битган
Бугун юртда
Эшитганлар жилманглар
Эшитмадим деманглар
битган бодомлар
Yangiariq tumani
qitish marakazi
Raqamli texnologiyalar
ilishida muhokamadan
tasdiqqa tavsiya
tavsiya etilgan
iqtisodiyot kafedrasi
steiermarkischen landesregierung
asarlaringizni yuboring
o'zingizning asarlaringizni
Iltimos faqat
faqat o'zingizning
steierm rkischen
landesregierung fachabteilung
rkischen landesregierung
hamshira loyihasi
loyihasi mavsum
faolyatining oqibatlari
asosiy adabiyotlar
fakulteti ahborot
ahborot havfsizligi
havfsizligi kafedrasi
fanidan bo’yicha
fakulteti iqtisodiyot
boshqaruv fakulteti
chiqarishda boshqaruv
ishlab chiqarishda
iqtisodiyot fakultet
multiservis tarmoqlari
fanidan asosiy
Uzbek fanidan
mavzulari potok
asosidagi multiservis
'aliyyil a'ziym
billahil 'aliyyil
illaa billahil
quvvata illaa
falah' deganida
Kompyuter savodxonligi
bo’yicha mustaqil
'alal falah'
Hayya 'alal
'alas soloh
Hayya 'alas
mavsum boyicha


yuklab olish