Диссертация (Модели процессов согласования реплик в базах данных NoSQL), страница 3

Более трети опрошенных компаний России (37%) приступили к работе стехнологиями Big Data. Причём многие из них используют базы данных NoSQL[1]: Сбербанк России, Яндекс, Mail.ru, Вымпелком, Мегафон, Тинькофф Банк,Имхонет, Kaspersky и др.111.2. Реляционные базы данных и хранилища NoSQL1.2.1. Преимущества и недостатки реляционных баз данныхИдея реляционной модели была предложена Коддом в 1970 в его статье [2].Этамодельприложенийхорошоиподходитоказаласьдляпрограммированияпреобладающейклиент-серверныхтехнологиейдляхраненияструктурированных данных, включая базы данных в сети Интернет.МожновыделитьследующиепреимуществареляционныхБД,проявляющиеся в наличии:1) теоретической основы реляционных баз данных (РБД);2) мощного и сравнительно простого для изучения языка описания иманипулирования данными (языка SQL), который стал стандартом;3) оптимизатора запросов, который выполняет декомпозицию запроса наболее мелкие задания, что обеспечивает параллельное выполнение этих работ намногопроцессорных или многомашинных комплексах;4) механизма обеспечения правильной работы системы: ведение ACIDтранзакций [3] (атомарность, согласованность, изолированность, долговечность) иблокировок записей;5) большого числа общесистемных ресурсов (СУБД, машин баз данных,CASE-средств и др.).Упрощенная схема обработки запросов в реляционных СУБД показана нарисунке 1.1.SQL-запрос 1СУБД (оптимизациязапроса)SQL-запрос nБДПриложениеРисунок 1.1 – Упрощенная схема обработки запросов в реляционных СУБД.Но с ростом сложности решаемых задач и объемом обрабатываемых данныхвсе более ощутимо стали проявляться недостатки реляционных БД:121.

Для реляционных баз данных характерна проблема потери соответствия[4]. Проявляется она в том, что реляционные БД не позволяют хранить агрегаты вявном виде. Например, чтобы отобразить всю информацию о клиенте и всех егозаказах (агрегат), программист должен собрать в оперативной памяти данные измногих связанных между собой таблиц: клиенты, заказы, элементы заказа др.(рисунок 1.2) При значительном росте числа таблиц разработчик часто простозабывает назначение той или иной таблицы, осложняется связывание таблиц привыполнении запроса, т.е. существенно осложняется формирование агрегата.Появление множества библиотек для объектно-реляционного отображения, такихкак Hibernate и iBATIS, не устранило проблему [4].ЗаказыИдентификатор: 1Покупатель: ПетрКлиентыПродавец: АлексейТовары:123123123125Москва4564564562100Казань789789789275ТулаПродавцыЭлементы заказаДанные об оплате:Владелец: ЕвгенийНомер карты: 0000111122223333Срок действия: 01.01.2020Банковские картыРисунок 1.2 – Агрегирование данных в приложении.2.

Для хранения больших объемов информации необходимо покупатьдорогие специализированные аппаратно-программные комплексы параллельныхсистем баз данных (Teradata, Sun Oracle Database Machine и др.). Параллельныесистемы демонстрируют невысокую масштабируемость, в частности дляподдержания требуемой отказоустойчивости [5]. При выполнении сложныхзапросов производительность системы существенно уменьшается в результатемежмашинного обмена данными между серверами кластера [6].133.

Схема базы данных состоит из подсхем, каждая из которых отражаетпредметную область какого-либо подразделения организации (предприятия).Модификацияподсхемыодногоподразделенияиреорганизациясоответствующих таблиц приводит к вынужденной приостановке работыостальных подразделений. Сейчас в качестве альтернативы централизованнойбазы данных широко используются так называемые «базы данных приложений»[4], т.е. подразделений. Обеспечение взаимодействия этих баз данных возлагаетсяна web-сервисы.

Но поддержка целостности данных и оперативности такоговзаимодействия является непростой задачей для программиста.4. Возникло противоречие между необходимостью хранения большихобъемовнеструктурированныхданныхинеобходимостьюихкак-тоструктурировать посредством разработки схемы базы данных.5. Согласно [7] репликация в распределенных реляционных базах данныхизначально выполнялась с использованием протокола «read-one-write-all»:операции чтения требуют локальных блокировок и выполняются на одном узле, вто время как для операций записи требуются распределенные блокировки длявсех копий записи.

Атомарность из набора ACID гарантируется использованиемдвухфазной фиксации (2-Phase-Commit (2PC)) [8] в конце каждой транзакции.Авторы работы [9] отмечают, что подобный подход основан на том, что каждаяоперация координируется отдельно. В результате при увеличении числа репликвремя реакции системы, вероятность возникновения конфликтов и тупиковыхситуаций увеличиваются по экспоненте.Рассматривая современные тенденции в области обработки данных,Стоунбрейкер подчеркнул эти особенности в своей статье "Конец архитектурнойэпохи "[10]:1.

Реляционные СУБД были разработаны более 25 лет назад, когдахарактеристики оборудования, требования пользователей и рынки баз данныхотличались от сегодняшних. Хотя и были расширения, но ни одна система небыла перепроектирована с самого начала.142. Новые рынки и варианты использования развивались с 1970-х годов,когда была только обработка бизнес-данных. Пользовательские интерфейсы имодель использования также изменились за последние несколько десятилетий оттерминалов, когда "операторы вводили запросы", до «толстых клиентов» и вебприложений, когда интерактивные транзакции и прямые SQL-интерфейсы редки.Как попытка решить накопившиеся проблемы реляционных баз данныхпоявились альтернативные средства хранения и обработки данных, получившиеназвание «базы данных NoSQL» (как синоним также используется термин«хранилище NoSQL»).1.2.2. Преимущества и недостатки баз данных NoSQLВ последнее время термин NoSQL (что означает «не только SQL»)применяется, чтобы описать большой класс баз данных, которые не имеютсвойств традиционных реляционных базы данных и которые, как правило, имеютязык запросов, отличный от SQL (язык структурированных запросов).

Этоттермин возрожден крупными компаниями Google и Amazon, которые используюттехнологию NoSQL для реализации собственных хранилищ данных с цельюхранения и обработки больших объемов данных [11, 12]. За ними последовали идругие компании: Facebook, Twitter, eBay, веб-сайт Digg и др.Можно выделить следующие преимущества баз данных NoSQL:1.

В настоящее время объем данных растет с огромной скоростью, и базыданных NoSQL очень хорошо поддерживают горизонтальную масштабируемость(тысячи узлов) – разделение данных и их дублирование (репликацию) по многимсерверам. Это позволяет поддерживать большое количество простых операцийчтения/записи в единицу времени и обеспечивает высокую отказоустойчивостьсистемы.2. Нет необходимости разрабатывать схему базы данных, как это принято вреляционных БД. Здесь схема более гибкая. Данные хранятся в виде записей<ключ, значение>. Разные записи могут иметь разные схемы, т.е.

наборы полей вполе «значение» могут отличаться.153. В поле «значение» можно сохранить агрегат, например, всю информациюо клиенте и его заказах (рисунок 1.3). Т.е. нет необходимости читать данные изразных таблиц. Агрегат может иметь сложную структуру (например, Jsonдокумент).4. Почти все базы данных NoSQL являются бесплатными и функционируютпод управлением разных операционных систем. Процедура их инсталляции вкластере достаточно проста (по сравнению с развертыванием реляционнойпараллельной системы баз данных).

Кластер может быть реализован на большомчисле маломощных узлов, и его можно поместить в облако.5. Многие базы данныхNoSQL имеют в своем составе средства,поддерживающие параллельные вычисления (технология MapReduce [13]).Идентификатор: 1Покупатель: ПетрПродавец: АлексейТовары:123123123125Москва4564564562100Казань789789789275ТулаАгрегатКлюч Значение{Покупатель: "Петр", Продавец: "Алексей", Товары:[{Код: 123123123, Количество: 1,1Цена: 25, Город: "Москва"},{Код: 456456456, … },...]...}2 ......

...Данные об оплате:Владелец: ЕвгенийНомер карты: 0000111122223333Срок действия: 01.01.2020Рисунок 1.3 – Хранение агрегата в записи БД.Многие системы NoSQL (CouchDB, HBase, Riak и др. [14]) поддерживаютстандарт REST-передачи репрезентативного состояния, т.е. стиль построенияархитектуры распределенного приложения [15]. Получение или обновлениязаписи выполняется через запрос, внешне напоминающий HTTP (рисунок 1.4).NoSQL (доступ через URL)Реплика 1.1Реплика 1.2(Ключ, значение)REST (GET)ПриложениеREST (PUT)Реплика 2.1Реплика 2.2Автоматическое обновлениереплик на N серверахРисунок 1.4 – Доступ к базе данных NoSQL по протоколу REST.16Стандарт REST был описан в 2000 году одним из создателей протоколаHTTP, Роем Филдингом [16]. Данные в REST должны передаваться в виденебольшого количества стандартных форматов (например, HTML, XML, JSON).Антиподом REST является подход, основанный на вызове удаленных процедур(Remote Procedure Call — RPC).