4. базы данных nosql
 Скачать 1.03 Mb.
|
|
Одноранговая репликация решает эту проблему, устраняя ведущий узел. Все реплики имеют одинаковый вес, все могут выполнять операции записи, и по- теря любой из них не приводит к потере доступа к хранилищу данных. Самая большая сложность, как и раньше, – согласованность. Когда выпол- няется запись в два разных места, есть риск, что два человека попробуют обно- вить одну и ту же запись в один и тот же момент времени. Таким образом возни- кает конфликт «запись-запись». Несогласованность чтения тоже приводит к про- блемам, но они являются преодолимыми. А вот, несогласованность записи имеет необратимый характер. Одним из глобальных отличий реляционной базы данных от базы данных NoSQL – это то как обеспечивается согласованность данных. Согласованность – это обеспечение внутренней непротиворечивости дан- ных. Различают строгую и итоговую согласованность. Строгая гарантирует, что данные вернутся полностью достоверными и не устареют. Итоговая согласован- ность не может гарантировать, что данные вернуться полностью достоверными, но в итоге данные обновятся на всех репликах. Согласованность проявляется в разных формах. Рассмотрим примеры. Представим процедуру обновления данных, при котором случайно два пользователя, назовем их User1 и User2 внесли обновления. Эта проблема назы- вается конфликтом «запись-запись». Она возникает, когда два пользователя БД обновляют одни и те же данные в один и тот же момент времени tw (рис. 4.7). Когда записи достигают сервера, тот их сериализирует – обрабатывает одну, а потом другую, например, в алфавитном порядке, и реализует сначала обновление первого пользователя User1, а затем обновление User2. Если контроля согласо- ванности нет, то обновление первого пользователя будет выполнено, а затем не- медленно перекрыто обновлением второго пользователя. В этом случае обновле- ние первого пользователя называется потерянным. Это явление можно считать нарушением согласованности обновления, потому что обновление второго пользователя использовало состояние до обновления первого, но применялось после него. Репликация повышает вероятность конфликтов «запись-запись». При обнов- лении реплик на разных узлах независимо друг от друга необходимы специаль- ные меры обеспечения согласованности данных. Решение, которое способствует снижению вероятности возникновения конфликта «запись-запись» заключается в том, чтобы все записи определенных данных хранить на одном узле. Это реше- ние использовалось во всех распределенных моделях, рассмотренных выше, кроме одноранговой репликации. t w Момент конфликта «запись-запись» t,с User1 User2 t,с Обновление от User1 t 1 t 2 Обновление от User2 Сериализация запросов на сервере Рис. 4.7. Конфликт обновления данных Представим процедуру чтения данных. Пусть оформляется заказ на опреде- ленные товары с определенными расходами на доставку. Расходы на доставку рассчитываются на основе товаров, указанных в заказе. Если добавляется новая позиция, то вычисления необходимо выполнить заново и обновить запись о рас- ходах на поставку. Опасность несогласованности заключается в том, что первый пользователь сначала добавляет позицию в свой заказ, а затем второй пользователь считывает эти позиции и расходы на доставку, а после этого первый пользователь обновляет запись о расходах на доставку. Этот вид ошибки называется несогласованным чтением или конфликтом «чтение-запись». На рис. 4.8 показана ситуация, в которой второй пользователь выполнил чте- ние в середине процедуры записи, выполняемой первым пользователем. Для ис- ключения такой ситуации используется метод логической согласованности. Она гарантирует, что разные элементы данных будут изменяться вместе. Например, для того чтобы избежать логической несогласованности при конфликте «чтение- запись», реляционные базы данных используют понятие транзакций. Обе записи первого пользователя упаковываются в одну транзакцию, и тем самым система гарантирует, что второй пользователь будет читать оба элемента данных либо до, либо после обновления. Агрегатная модель базы данных NoSQL позволяет избежать несогласован- ности сделав заказ, стоимость доставки и товарные позиции заказа частями од- ного и того же агрегата. t w1 t,с User1 User2 t w2 Рис. 4.8. Конфликт чтения данных Разумеется, не все данные можно записать в один и тот же агрегат, поэтому любые обновления, влияющие на несколько агрегатов, оставляют интервал вре- мени, в течение которого клиенты могут выполнить несогласованное чтение. Продолжительность этого интервала называется окном несогласованности. Си- стема NoSQL может иметь довольно узкое окно несогласованности. Например, в документации компании Amazon сказано, что окно несогласованности обычно не превышает секунды. С появлением репликации появился и новый вид несогласованности. На рис. 4.9 приведено пояснение этого вида несогласованности. t,с User1 User2 User3 Окно согласованности Сериализация запросов на сервере t,с t 1 t 2 t 3 Обновление от User1 Чтение от User2 Чтение от User3 Рис. 4.9. Нарушение согласованности репликаций Пользователь User1 вносит обновления, но наличие окна несогласованности означает, что разные пользователи БД увидят разные данные в одно и то же время. Поэтому User2 получит недостоверные данные (еще не обновленные), а пользователь User3 – уже обновленные. Таким образом, согласованность репликаций гарантирует, что при чтении с разных реплик один и тот же элемент данных имеет одно и то же значение. Разумеется, в конце концов, обновления будут полностью распределены по узлам, и User2 увидит обновленные данные. По этой причине такая ситуация называется итоговой согласованностью или согласованностью «в конечном счете». Это значит, что в любой момент времени узлы могут быть несогласован- ными, но, если нет новых обновлений, в конце концов все узлы будут обновлены и получат одно и то же значение. Согласованность – это важное свойство БД, но, к сожалению, иногда ею при- ходится жертвовать. Почти всегда можно разработать систему, предотвращаю- щую несогласованность, но практически невозможно сделать это без ущерба для остальных характеристик системы. В результате часто приходится жертвовать согласованностью в пользу чего-то другого. В NoSQL этот компромисс формулируется теоремой САР. САР – это акро- ним от трех свойств: Согласованность (Сonsistency) – непротиворечивость данных. Доступность (Availability) – предельное время отклика, которое допу- стимо. Устойчивость к разделению (Partition tolerance) означает, что кластер может восстанавливать обмен данными после обрыва связей в кластере, который разделен на многочисленные фрагменты, не способные взаимодействовать друг с другом Основное утверждение этой теоремы гласит, что из трех свойств – согласо- ванности данных, доступности и устойчивости к разделению – можно обеспечить не больше двух. На практике САР реализует следующее утверждение: в системе, которая подвержена разделению, следует искать компромисс между согласован- ностью и доступностью. Полученная в результате система не будет ни хорошо согласованной, ни идеально доступной, но она будет представлять собой разум- ное сочетание этих свойств. Чем больше узлов задействовано в запросе, тем выше вероятность возник- новения конфликта «запись-запись» и ниже вероятность конфликта «чтение-за- пись». Отсюда естественен вопрос: «Сколько узлов (реплик) должно быть вовле- чено в запрос, чтобы обеспечить строгую согласованность данных?» Введем следующие обозначения: R – коэффициент репликации; W – количество узлов, участвующих в записи; N – количество узлов, участвующих в чтении. Согласно теореме САР, не нужно, чтобы все узлы подтверждали запись для обеспечения строгой согласованности; нужно, чтобы это сделали большинство. Это явление называется кворумом записи и выражается неравенством W>N/2 (4.1) Аналогично существует кворум чтения, но это более сложное понятие. Кво- рум чтения зависит от того, сколько узлов должны подтвердить запись. Пусть R=3. Если все записи должны подтвердить два узла (W=2), то необходимо уста- новить контакт по крайней мере с двумя узлами, чтобы гарантировать получение последних данных. Если же записи подтверждаются только одним узлом (W=1), надо связаться со всеми тремя узлами, чтобы гарантировать получение послед- них обновлений. В последнем случае нет кворума записи, поэтому возникает кон- фликт обновлений, но, контактируя с достаточно большим количеством читате- лей, обнаружение конфликта гарантированно. Таким образом, можно получить строго согласованные результаты чтения, даже если нет строгой согласованности записей. Неравенство получения строгой согласованности: R+W>N (4.2) Неравенства (4.1) и (4.2) выведены для одноранговой модели распределения. В случае распределения «ведущий-ведомый», чтобы избежать конфликтов «запись-запись», достаточно записать данные на ведущий узел. Чтобы избежать конфликтов «чтение-запись», достаточно выполнять чтение только с ведущего узла. Уточним, что количество узлов в кластере и коэффициент репликации – это разные числа. Например, при фрагментации баз данных кластер можете иметь 100 узлов при коэффициенте репликации, равном 3. Обобщим информацию о правилах распределения и согласованности дан- ных в следующих выводах: 1. Конфликты «запись-запись» возникают, когда два клиента пытаются за- писать одни и те же данные в одно и то же время. 2. Конфликты «чтения-записи» в распределенных системах возникают, ко- гда некоторые узлы получают обновленные данные, а другие нет. 3. Итоговая согласованность означает, что определенная часть системы станет согласованной, как только все записи будут распространены по всем уз- лам. 4. Чтобы обеспечить хорошую согласованность данных в распределенных системах возникает необходимость компромисса между согласованностью и вре- менем реакции (теорема САР). 4.3. Базы данных «ключ – значение» Базы данных «ключ – значение»состоит из множества агрегатов, каждый из которых имеет ключ или идентификатор, который используется для доступа к данным. Агрегаты в такой базе данных являются непроницаемыми, то есть про- сматривать содержимое агрегата можно только с помощью его ключа. Внешне БД «ключ – значение» похожана реляционную БД с двумя столб- цами, например, ID и Имя (табл. 4.1), где столбец ID – первичный ключ, а столбец Имя содержит значение. При этом значение – это двоичный объект данных, ко- торый записан в хранилище без детализации eгo внутренней структуры в виде хэш-кода. Это позволяет с одной стороны избавиться от метаданных, то есть хра- нить прямое значение, а с другой стороны обеспечить целостность данных. Что именно хранится в этом объекте может определить только приложение. Табл. 4.1. БД «ключ – значение» ID Имя AAAAA 1001010100010001… AABAB 0100010110011101… DFA766 0000111101101101… FABCC4 1100110010101110… Из-за хранения данных в поле значение в виде хэш-кода говорят, что БД «ключ-значение» – это хэш-таблица. Выбор функции хэширования должен обес- печить равномерное распределение хэшированных ключей по хранилищу дан- ных. С точки зрения интерфейса прикладного программирования хранилище типа «ключ-значение» – самое простое из БД NoSQL. Управление данными в плане манипулирования ими сводится к тому, что клиент может либо получить значе- ние по ключу, либо записать значение по ключу, либо удалить ключ из храни- лища данных. Поскольку хранилища типа «ключ-значение» всегда используют доступ по первичному ключу, они обычно имеют высокую производительность и легко масштабируются. Приложение вычисляет ID и значение и сохраняет эту пару. Если ключ ID уже существует, то текущее значение замещается, в противном случае создается новая запись. Если есть необходимость хранить данные сеанса пользователя, информацию о его корзине товаров и предпочтениях, то можно записать их в один агрегат с одним ключом для всех перечисленных объектов (рис. 4.10). UserProfile SessionData ShoppingCart CartItem CartItem Рис. 4.10. Пример агрегата БД «ключ-значение» Недостатком хранения всех объектов в одном агрегате является тот факт, что агрегаты могут иметь разные типы, которые могут вызвать конфликты клю- чей. В качестве альтернативы к ключу можно было бы добавить имя объекта, чтобы при необходимости можно было извлечь отдельный объект по этому имени (вложение ключ-значение), как на рис. 4.11. Рис. 4.11. Альтернативный вариант агрегата Соответствие терминологии, принятой в реляционной модели БД и модели «ключ-значение» приведено в табл. 4.2. Табл. 4.2. Соответствие терминов Реляционная модель БД Модель «ключ-значе- ние» База данных Кластер Таблица Сегмент Строка Ключ-значение Идентификатор строки Значение При использовании хранилищ типа «ключ-значение» большое внимание уделяется выбору структуры ключа – алгоритмам генерации ключа, использова- нию меток времени, индивидуальных данных пользователя в этих алгоритмах. Благодаря своим характеристикам базы данных типа «ключ-значение» часто используют для хранения данных о пользовательских сессиях (при этом в каче- стве ключа используется идентификатор сессии), корзин покупателей, профилей пользователей и т.п. Рассмотрим примеры, в которых хранилища типа «ключ-значение» на прак- тике зарекомендовали себя с лучшей стороны: Хранение информации о сессии. Каждая веб-сессия является уникальной и имеет уникальный идентификатор SessionId. Приложение записывает идентификатор SessionID в БД и всю инфор- мацию о сессии одним запросом. Операции выполняются очень быстро, по- скольку вся информация о сессии хранится в одном объекте. Профили пользователей, предпочтения, товары. Почти каждый пользователь имеет уникальный атрибут UserID, UserName или какой-то другой идентификатор, а также предпочтения, например, язык, цвет, часовой пояс, выбранные товары и т.д. Все это можно поместить в один объект и получать предпочтения пользователя с помощью одной операции. Ана- логично можно хранить профили товаров. Корзины заказа. Коммерческие веб-сайты используют корзины заказа, связанные с пользова- телем. Если требуется, чтобы корзина заказа была доступна постоянно, незави- симо от браузеров, компьютеров и сессий, всю информацию о покупках можно поместить в объект Value с ключом UserId. Существуют ситуации, в которых хранилища типа «ключ-значение» не яв- ляются оптимальным выбором. Приведем примеры таких ситуаций: Запрос по данным. В базах данных типа «ключ-значение» отсутствие структурированности дан- ных не позволяет задать условия к конкретному внутреннему агрегату. Отношения между данными. Если между разными наборами данных необходимо установить отношения или поддерживать корреляцию между разными наборами ключей, то базы дан- ных типа «ключ-значение» не имеют такой возможности. Операции с множествами. Поскольку операции в каждый момент времени ограничены одним ключом, невозможно работать с несколькими ключами одновременно. Если требуется об- работать несколько ключей сразу, то это придется делать на клиентской стороне. Транзакции, состоящие из многих операций. Если при сохранении нескольких ключей при записи одного из них произо- шел сбой нет возможности вернуться в исходное положение или выполнить откат остальных операций. Изучение особенностей баз данных типа «ключ-значение» позволяет сделать следующие выводы: 1. База данных «ключ-значение» – это хеш-таблица. 2. Доступ к данным БД реализуется только по ключу. 3. Для извлечения информации об отдельном объекте необходимо создать его уникальный ключ. 4. Объекты можно объединять в агрегаты. 5. База данных типа «ключ-значение» может быть распределенной (кла- стеры). 6. Базы данных типа «ключ-значение» имеют узкую область применения. 7. Базы данных типа «ключ-значение» не годятся для задач (запросов), ти- пичных для реляционной модели БД. 4.4. Документные БД Документные базы данных концептуально похожи на БД типа «ключ-значе- ние», только в качестве значений хранятся документы. Таким образом, основной единицей манипулирования является документ, основная часть которого явля- ется неструктурированным текстом. Документы хранятся примерно одинаково, но сами они не обязательно должны быть одинаковыми, то есть это тексты, графические, звуковые, мульти- медийные документы. Документные БД предназначены для создания, хранения и выдачи по запро- сам документов, содержащих требуемую информацию. В ответе назапроск та- кой БД пользователь получает список документов, в определенной мере содер- жащих нужную ему информацию. Мера соответствия полученного результата построенному запросу оценива- ется релевантностью. Релевантность – это характеристика, которая выражает по- лезность информации, относительно запроса, отправляемого в информационную систему. Поисковые запросы к документным БД – это поиск смысловой(семантиче- ской) информации, например: выдать статьи, посвященные документным БД, то есть содержащие термин «документные БД». Таким образом, поиск в документной БД сводится к сравнению смыслового содержания запроса со смысловым содержанием хранящихся в БД документов. Семантическая природа документов определяет необходимость учитывать сино- нимию, полисемию, омонимию, контекстную обусловленность смысла отдель- ного слова и возможность выразить один смысл многими способами. База данных хранит и извлекает документы в форматах ХМL, JSON, jpeg, avi, wav и т.д. Записью документальной базы данных является документ, который задается как набор необязательных полей, для каждого из которых определены имя и тип (рис. 4.12). Необязательные поля документа (имя-тип) ID_Документа Аннотация Глава 1 Глава 2 Заключение Рис. 4.12. Вид записи документальной БД Для документных БД допустимы стандартные типы, задающие числовые, символьные и другие величины, но основной тип текстовый. Текстовые поля об- ладают переменной длиной и композиционной структурой, что не имеет прямых аналогов среди стандартных типов языков программирования. Текстовое поле состоит из параграфов, параграф – из предложений, предложение – из слов. С точки зрения хранения, в документных БД идентифицируемым элементом данных будет поле, а с точки зрения поиска – слово. Система управления документными базами данных присваивает каждому документу уникальный номер, а каждому ключевому слову документа ставится в соответствие указатель на списки экземпляров, являющихся перечнем докумен- тов, в которых встречается данное слово (то есть создается индекс). Каждый спи- сок экземпляров содержит заголовок, из которого можно узнать число экземпля- ров слова во всем файле документов, а также число документов, в которых это слово встречается. Документальная БД включает в себя как минимум три области хранения дан- ных, представляемые из-за своего большого размера, как правило, в виде файлов операционной системы (в действительности их всегда больше): файл словаря, устанавливающий соответствие между словом, встречаю- щимся в БД, и его кодом; инверсный (инвертированный, обратный) список, содержащий для каж- дого слова БД список документов, его содержащих, используется при тек- стовом поиске; текстовый файл, содержащий собственно документы, используется при выдаче (просмотре) документов. |