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»).
Do'stlaringiz bilan baham: 
