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

Ключ
Агрегат
Значение
1
{Покупатель: "Петр", Продавец: "Алексей", Товары:[{Код: 123123123, Количество: 1, 
Цена: 25, Город: "Москва"},{Код: 456456456, … },...]...}
2
...
...
...
Идентификатор: 1
Покупатель: Петр
Продавец: Алексей
Товары:
123123123
456456456
789789789
1
2
2
25
100
75
Москва
Казань
Тула
Данные об оплате:
Владелец: Евгений
Номер карты: 0000111122223333
Срок действия: 01.01.2020
Рисунок 1.3 – Хранение агрегата в записи БД. 
Многие системы NoSQL (CouchDB, HBase, Riak и др. [14]) поддерживают 
стандарт REST-передачи репрезентативного состояния, т.е. стиль построения 
архитектуры распределенного приложения [15]. Получение или обновления 
записи выполняется через запрос, внешне напоминающий HTTP (рисунок 1.4).
(Ключ, значение)
Автоматическое обновление 
реплик на N серверах
Приложение
NoSQL (доступ через URL)
REST (GET)
REST (PUT)
Реплика 2.1
Реплика 2.2
Реплика 1.1
Реплика 1.2
Рисунок 1.4 – Доступ к базе данных NoSQL по протоколу REST. 

---

16 
Стандарт REST был описан в 2000 году одним из создателей протокола 
HTTP, Роем Филдингом [16]. Данные в REST должны передаваться в виде 
небольшого количества стандартных форматов (например, HTML, XML, JSON). 
Антиподом REST является подход, основанный на вызове удаленных процедур 
(Remote Procedure Call — RPC). Подход RPC, используемый в архитектуре 
«сервер приложений» [17], позволяет использовать небольшое количество 
сетевых ресурсов с большим количеством методов и сложным протоколом. При 
подходе REST количество методов и сложность протокола строго ограничены, из-
за чего количество отдельных потребляемых ресурсов может быть большим [14].
Для достижения высокой горизонтальной масштабируемости и повышения 
производительности в NoSQL пришлось отказаться от ограничений ACID [3]. Это 
привело к появлению ряда существенных недостатков: 
1. NoSQL невозможно использовать в приложениях, где ACID-транзакции 
необходимы: в банковских и других финансовых системах [18]. 
2. Базы данных NoSQL обеспечивают согласованность копий записей 
(реплик) на разных серверах, но с некоторой задержкой, связанной с 
распространением обновлений по нескольким репликам (согласованность в 
конечном счете, Asynchronous Replication). Поэтому возможно чтение устаревших 
данных. Строгая согласованность записи/чтения обеспечивается только при 
наличии кворума реплик. Но это приводит к увеличению времени выполнения 
операций записи/чтения. 
3. В NoSQL для доступа к данным необходимо использовать процедурный 
язык (в отличие от SQL, который является непроцедурным языком 
программирования). При этом сложность программирования возрастает. 
Например, чтобы выполнить соединение (join) нескольких таблиц, в SQL 
достаточно закодировать один оператор. Для реализации этого запроса в NoSQL 
программист должен представить его в виде нескольких заданий (job), для 
каждого из них написать программы Map и Reduce и запустить их в среде 
MapReduce. 

---

17 
Отказ от поддержки ACID-транзакций оказывает сильное влияние на 
производительность баз данных NoSQL. Но отказ от свойств ACID не является 
полным. Например, в СУБД Riak [19] можно указывать процедуры, выполняемые 
до и после фиксации данных – это некоторая аналогия триггеров [20]. В [4] 
отмечается, что свойство атомарности реализуется за счет агрегации всех 
изменяемых данных в одной записи БД. Конечно, если клиенту необходимо 
обновить несколько взаимосвязанных агрегатов, атомарность не будет 
гарантироваться. Отказ в NoSQL от блокировки обновляемых записей БД 
привело к отказу от требования изолированности, поддерживаемого ACID-
транзакциями. 
Итак, и реляционные базы данных (РБД), и базы данных NoSQL имеют 
преимущества и недостатки. Стоунбрейкер, в частности, отмечает [21]: «Сейчас у 
каждого из вертикальных рынков имеются свои проблемы, для решения которых 
требуются наиболее удобные средства, и нет нужды ограничиваться 
унаследованными из прошлого реляционными системами». Каждый тип СУБД 
(РБД, NoSQL и др.) имеет свою нишу, и они еще долго будут сосуществовать 
вместе.