4. базы данных nosql
 Скачать 1.03 Mb.
|
|
4. БАЗЫ ДАННЫХ NOSQL Базы данных NoSQL появились в ответ на необходимость обрабатывать «большие» данные на крупных аппаратных платформах, состоящих из вычисли- тельных кластеров. Таким образом, в настоящее время реляционные БД уже не являются единственной моделью отображения данных. У разработчиков инфор- мационных систем появился выбор модели хранения и управления данными. 1.1. Нереляционная модель данных За то время, пока реляционная модель была практически единственной при отображении физической модели хранения данных, накопилось ряд проблем, ко- торые реляционные БД решают неэффективно или даже неестественно. Вот некоторые из них. 1. Для реляционных баз данных характерна потеря соответствия. Проявля- ется она в том, что реляционные базы данных не позволяют хранить агрегаты. Агрегат – термин, пришедший из предметно-ориентированного проектирования, где агрегатом называют коллекцию связанных объектов, которая интерпретиру- ется как единое целое, что-то наподобие коробки, которую мы подписываем и складываем в нее предметы, которые должны находиться вместе. Например, чтобы отобразить всю информацию о покупателе и всех его по- купках необходимо собрать данные из многих таблиц: покупатель, заказ, пункт заказа, цена и др. и хранить их в виде соответствия. При значительном росте числа таблиц формирование агрегата покупателя существенно осложняется. 2. С увеличением объема хранимых данных возникает задача фрагментации таблиц базы данных по разным серверам, объединенных в кластер. При выпол- нении сложных запросов производительность системы существенно уменьша- ется в результате межмашинного обмена данными между серверами кластера. Возникает проблема обеспечения надежности кластера. 3. Схема базы данных состоит из подсхем, каждая из которых отражает пред- метную область какого-либо подразделения организации. Модификация под- схемы одного подразделения и реорганизация соответствующих таблиц приво- дит к вынужденной приостановке работы остальных подразделений. Поддержка целостности данных и оперативности такого взаимодействия является сложной задачей. Как попытка решить накопившиеся проблемы реляционных баз данных по- явились альтернативные средства хранения и обработки данных, получившие название «базы данных NoSQL». Пионерами в этой области выступили две ком- пании: Google и Amazon, Идея нереляционных баз данных очень проста: данные хранятся в виде за- писей <ключ, значение>, а схема базы данных отсутствует. При этом, в поле «зна- чение» может храниться агрегат, например, вся информация о покупателе и его покупках. Так решается первая проблема, присущая реляционным БД. Данные в виде агрегатов автоматически равномерно распределяются и реп- лицируются по серверам кластера. Таким образом решается вторая проблема, присущая реляционным БД. Отсутствие схемы базы данных позволяет включать или удалять атрибуты на уровне отдельной записи, не затрагивая работу остальной части системы, что решает третью проблему, свойственную реляционным БД. Термин «NoSQL» в настоящее время не имеет строгого определения. И не существует авторитетного органа, который бы предложил такое определение, по- этому можно говорить о некоторых общих свойствах БД, относящихся к катего- рии NoSQL. Первое свойство – очевидный факт: базы данных NoSQL не используют язык SQL. Некоторые из них имеют свой язык запросов, многие из которых по- хожи на SQL чтобы их легче было изучить. Однако до сих пор не реализован ни один язык, который достиг той же степени гибкости, что и стандартный язык SQL. Другое важное свойство этих баз данных заключается в том, что они пред- ставляют собой проекты с открытым исходным кодом. Несмотря на то что тер- мин «NoSQL» часто применяется к системам с закрытым исходным кодом, суще- ствует мнение, что NoSQL – это феномен с открытым исходным кодом. Большинство баз данных NoSQL создавались в ответ на необходимость ра- ботать на кластерах. Для обеспечения согласованности в реляционных БД ис- пользуют транзакции. Это изначально противоречит кластерной среде, поэтому базы данных NoSQL предлагают спектр вариантов для обеспечения согласован- ности и распределения данных. Базы данных NoSQL учитывают емкость веб-сайтов начала ХХI века, по- этому обычно только системы, разработанные примерно в это время, называются NoSQL, тем самым исключая базы данных, созданные в прошлом веке. Базы данных NoSQL работают без схемы, позволяя свободно добавлять поля в базу данных без предварительного изменения структуры. Это очень важно для БД с неоднородными данными Все свойства, указанные выше, являются общими для баз данных NoSQL. Ни одно из них нельзя считать определяющим. Таким образом сформулируем: базы данных NoSQL – это распределенные нереляционные базы данных с открытым исходным кодом. Из известных баз дан- ных NoSQL можно назвать Cassandra, Riak, DynamoDB, Hypertable, MongoDB и другие. Все БД NoSQL являются неструктурированными. Когда данные хранятся в реляционной базе, то сначала определяется схема БД. В базах данных NoSQL хранение данных происходит по-другому. Каждая БД, реализованная по технологии NoSQL использует свою собствен- ную модель. Эти модели разделяются на четыре категории: ключ-значение; документ; семейство столбцов; граф. БД типа «ключ-значение» позволяет хранить данные по ключу. Документная база данных по существу делает то же самое, поскольку не накладывает ограничений на структуру хранящихся документов. Семейство столбцов позволяет хранить любые данные в любом столбце. Графовые базы данных отображают объекты и связи между ними в виде графа. Путем добавления, удаления, изменения ребер и узлов графа происходит управление данными. Первые три модели объединяет свойство агрегатной ориентацией. Рассмот- рим, что понимают под агрегатами и как они влияют на модели данных. Реляционная модель хранимую информацию разделяет на кортежи (строки). Кортеж – это ограниченная структура данных. Он хранит набор значений, по- этому не может содержать запись, список значений или другой кортеж. Эта про- стота образует основу реляционной модели и позволяет интерпретировать все операции как операции над кортежами и возвращение кортежей. Агрегатная ориентация придерживается другого подхода. Она учитывает необходимость оперировать данными, имеющими более сложную структуру, чем набор кортежей. Агрегат можно сравнить со сложной записью, которая может содержать списки и другие структуры записей (рис. 4.1). Агрегат не имеет стро- гого шаблона и в зависимости от задачи может иметь структуру разной сложно- сти. Таким образом, агрегат представляет собой единицу для манипулирования данными и управления их согласованностью. Агрегат Список Значение Значение Значение Значение Рис. 4.1. Структура агрегата Модификация агрегатов происходит с помощью атомарных операций. Вза- имодействие с БД, как хранилищем данных выполняется посредством агрегатов. Агрегаты облегчают работу баз данных на кластерах, поскольку представ- ляет собой естественную единицу репликации и фрагментации. Кроме того, аг- регаты упрощают разработку прикладных программ, которые часто манипули- руют данными с помощью агрегированных структур. Продемонстрируем сказанное на примере. Предположим, что разрабатыва- ется веб-сайт для электронной торговли и планируется продавать товары непо- средственно клиентами через web, что требует хранения информации о пользо- вателях, каталогах товаров, заказы, адреса поставки и даты платежей. Этот сце- нарий используем для моделирования данных с помощью реляционной модели, а также с помощью технологии NoSQL, что позволит проанализировать их пре- имущества и недостатки. Разработку реляционной базы данных можно начать с модели данных, пред- ставленной на рис. 4.2. В ней выполнены все правила реляционной модели и про- ведена нормализация отношений. ID_Заказчик_ID_ЗаказаID_ЗаказчикаID_АдресаЗаказ_ID_АдресаID_ЗаказчикаАдреса_заказчиков'>Заказчика Имя Заказчик ID_Заказа ID_Заказчика ID_Адреса Заказ ID_Адреса ID_Заказчика Адреса заказчиков ID_Адреса Улица Город Страна Индекс Адрес ID_Оплаты ID_Заказа ID_Адреса карты ID_Транзакции Оплата ID_Заказа ID_Товара Цена Стоимость заказа ID_Товара Наименование Товар 1 M 1 M 1 M 1 M 1 M M 1 1 M 1 1 Рис. 4.2. Модель данных Реляционная БД, соответствующая модели на рис. 4.2 включает 7 отноше- ний. На рис. 4.3 приведены фрагменты некоторых из них. Заказ Заказчик ID_Заказчика ID_Заказа ID_Адреса Адреса заказчиков ID_Товара Товар Имя 1 Яковлев С.А. ID_Заказчика ID_Адреса 99 77 1 ID_Заказчика 77 1 Наименование 27 «NoSQL» Рис. 4.3. Фрагменты таблиц, являющихся частью реляционной БД Посмотрим, как будет выглядеть эта модель, если применить агрегатно-ори- ентированный подход. Модель изобразим средствами UML-диаграммы (рис. 4.4). В UML-диаграмме ромб обозначает агрегацию. Данные будем представлять в формате JSON 1 , который является основным способом представления данных в технологии NoSQL. В модели есть два основ- ных агрегата: Заказчик и Заказ. Агрегат «Заказчик» содержит список адресов заказчиков. Агрегат «Заказ» содержит список заказанных товаров, адреса поставки и данные о платежах. Запись о платеже сама содержит адрес заказчика, выполняю- щего данный платеж. Отдельная логическая запись, содержащая адрес, в этом примере появляется три раза, но вместо использования идентификатора она интерпретируется как значение и каждый раз копируется. При использовании агрегатов можно копиро- вать всю адресную структуру в агрегат. Название товара показано в качестве части заказа, – этот вид денормализа- ции напоминает компромисс, принятый в реляционных базах данных, но по от- ношению к агрегатам он носит более общий характер, потому что есть необходи- мость минимизировать количество агрегатов, к которым будет осуществляться доступ при работе с данными 1 JSON – текстовый формат обмена данными, основанный на JavaScript. Как и многие другие текстовые форматы, JSON легко читается людьми Связь между заказчиком и заказом не хранится в агрегатах. Аналогично связь, идущая от заказа, может идти к отдельной агрегированной структуре для товаров, но она не хранится в этой структуре. ID_Заказчика Имя Заказчик ID_Заказа ID_Заказчика ID_Адреса Заказ ID_Адреса Улица Город Страна Индекс Адрес ID_Оплаты ID_Заказа ID_Адреса карты ID_Транзакции Оплата ID_Заказа ID_Товара Цена Стоимость заказа ID_Товара Наименование Товар 1 M 1 M 1 M M 1 1 Адрес заказчика M Адрес поставки Рис. 4.4. Агрегатная модель данных // Заказчик { «ID_Заказчика":1, "Имя":"Яковлев С.А.", "Адрес": [ {"ID_Адрес":" 55", "Улица":" Б. Морская", "Город": "Санкт-Петербург", "Страна":"Россия", "Индекс": "190000" } ], } //Заказ {"ID_Заказа":99, " ID_Заказчика":1, "Стоимость заказа": [ { "ID_Товара":27, "Цена": 320, "Наименование": "NoSQL" } ] , "ID_Адрес": [ { "ID_Адреса": "55"}], "Оплата": [ { "№карты":"1000-1000-1000-1000", "ID_транзакции":"abelif879rft", "ID_Адреса": {"ID_Адреса": "55"} } ], } В данном примере важен не столько конкретный способ изображения гра- ницы агрегата, сколько тот факт, что необходимо думать о доступе к данным при разработке модели данных для приложения. Действительно, можно иначе изобразить границы агрегатов, поместив все заказы отдельного заказчика в агрегат «Заказчик», как на рис. 4.5. ID_Заказчика Имя Заказчик ID_Заказа ID_Заказчика ID_Адреса Заказ ID_Адреса Улица Город Страна Индекс Адрес ID_Адреса карты ID_Транзакции Оплата ID_Товара Цена Стоимость заказа Наименование Товар M M 1 M M 1 1 Адрес заказчика M Адрес поставки Адрес заказчика Рис. 4.5. Агрегатная модель, в которой все объекты объединены в один аг- регат «Заказчик» //Заказчик {«ID_Заказчика":1, "Имя":"Яковлев С.А.", "Адрес": [ {"ID_Адрес":" 55“, "Улица":" Б. Морская", "Страна":"Россия", "Индекс": "190000" } ], "Заказ": [ {"ID_Заказа":" 99", "Стоимость заказа":[ {“ID_Товара":27, "Цена": "300 “ } ] } ], "Оплата":[ {"№карты":"1000-1000-1000-1000", "ID_транзакции":"abelif879rft", "ID_Адреса": {"ID_Адреса": "55"} } ] } Универсального способа для изображения границ агрегатов не существует. Это целиком зависит от целей манипулирования данными. Например, чтобы отобразить всю информацию о заказчике и всех его заказах, программист должен собрать в оперативной памяти данные из многих таблиц: заказчик, заказ, адрес заказа, цена и др. При значительном росте числа таблиц разработчик часто просто забывает назначение той или иной таблицы, осложняется связывание таблиц при выполнении запроса, то есть существенно осложняется формирование агрегата. Поэтому, если необходимо получать доступ к записи о заказчике и ко всем его заказам одновременно, то, вероятно, предпочтительнее один агрегат. Однако, если необходимо в каждый момент времени получать доступ к отдельному за- казу, то лучше предусмотреть отдельный агрегат для каждого заказа. Есте- ственно, это сильно зависит от данных; даже в рамках одной системы разные при- ложения могут иметь разные предпочтения. Большинство баз данных NoSQL не поддерживают механизм транзакций. Известно, что транзакции – это механизм, который обеспечивают согласован- ность данных. Но в БД NoSQL поддерживаются другие механизмы манипуляции с отдельными агрегатами по очереди из кода приложения. Итак, обобщая информацию об агрегатной (нереляционной) модели данных можно сделать следующие выводы: 1. В агрегатной (нереляционной) модели данных существует неявная схема, подразумеваемая программистом БД. 2. Границы агрегатов выбираются программистом БД и во многом зависят от целей манипулирования данными. 3. Агрегаты объединяют в одно целое данные, доступ к которым осу- ществляется одновременно. 4. Агрегаты указывают, какие части данных должны храниться на одном и том же узле. 5. Если реляционные базы данных позволяют манипулировать любой комбинацией строк из любой таблицы в рамках одной транзакции, то в нереля- ционных БД аналогичная задача решается разделением данных по агрегатам. 4.2. Распределение и согласованность Основным свойством технологии NoSQL является возможность функциони- рования баз данных на большом кластере, то есть размещение базы данных на кластере серверов. Этот процесс также называется горизонтальным масштабиро- ванием базы данных. Агрегатно-ориентированный подход хорошо согласуется с горизонтальным масштабированием, поскольку агрегат является естественной единицей распре- деления. В зависимости от выбранной модели распределения можно создать хра- нилище данных, предоставляющее возможность обрабатывать больший объем данных, обрабатывать более интенсивный трафик чтения или записи, а также из- бегать перегрузки и торможения компьютерной сети. С другой стороны, работа на кластерах повышает сложность базы, поэтому при выборе модели распределения взвешиваются все аргументы за и против. Существуют два способа распределения данных: репликация и фрагмента- ция (рис. 4.6). Модели рапределения Репликация Фрагментация Ведуший-ведомый Одноранговая Рис. 4.6. Классификация способов распределения данных Репликация подразумевает копирование одних и тех же данных на несколь- ких узлах (реплик). Количество реплик называется коэффициентом репликации. Репликация бывает двух видов: ведущий-ведомый и одноранговая. Фрагментация подразумевает, что разные части БД размещаются на множе- ство серверов. Если механизм фрагментации не применять, то пользователи бу- дут обращаться к одному большому серверу. При наличии механизма фрагмен- тации пользователи будут обращаться к разным узлам и благодаря этому полу- чать быстрые ответы. Например, если БД распределена в кластере из 10 серверов, то каждый из них будет загружен только на 10%. Разумеется, идеальный случай крайне редок. Для того чтобы приблизиться к идеалу, необходимо, чтобы данные, которые запрашиваются одновременно, размещались вместе на одном и том же узле для ускорения доступа к ним. Поэтому актуальность вопроса заключается в том, как сгруппировать данные так, чтобы один пользователь в основном получал данные с одного сервера. Это тот случай, когда помогает агрегатная ориентация, т.к. главное свойство агрегата заключается в том, что он объединяет данные, ко- торые, как правило, запрашиваются одновременно. Таким образом, агрегаты яв- ляются естественной единицей распределения. Репликация и фрагментация являются ортогональными методами: можно использовать любую из двух или обе вместе. Рассмотрим эти методы подробнее. При распределении по схеме «ведущий-ведомый» происходит репликация данных по многим узлам. Один узел назначается ведущим (master), или главным. Этот ведущий узел является доверенным источником данных и обычно несет от- ветственность за выполнение всех модификаций этих данных. Остальные узлы являются ведомыми (slaves), или вторичными. Процесс репликации синхронизи- рует ведомые узлы с ведущим. Репликация «ведущий-ведомый» – это решение для тех баз данных, к кото- рым интенсивно выполняется операция чтения. То есть, чтобы выполнить больше запросов на чтение, необходимо добавить больше ведомых узлов и направлять на них все запросы на чтение. Однако если обновлять данные на ве- дущем узле, есть опасность, что чем больше ведомых узлов, тем выше вероят- ность, что пользователи будут получать несогласованные данные. То есть это не- удачное решение для баз данных с интенсивным трафиком записи. Второе преимущество репликации «ведущий-ведомый» – это отказоустой- чивость чтения, то есть, если на ведущем узле произойдет отказ, ведомые узлы смогут по-прежнему обрабатывать запросы на чтение. Сбой ведущего узла сде- лает запись невозможной, пока его работа не будет восстановлена или не будет подключен новый ведущий узел. Как раз наличие реплик ведущего узла на ведо- мых узлах ускоряет процесс его восстановления после сбоя. Таким образом, репликация имеет не только привлекательные свойства, но и неизбежный недостаток – несогласованность. Существует опасность, что раз- ные клиенты, читающие данные с ведомых узлов, получат разные значения из-за того, что обновления не успеют распространиться по всем ведомым узлам. По существу, ведущий узел остается узким местом и единственной точкой отказа в модели «ведущий-ведомый». |