4. базы данных nosql
 Скачать 1.03 Mb.
|
|
Файл словаря Код слова Список номеров документов, содержащих слово Инверсный список Номер документа Поля документов, предназначенные для вывода Текстовый файл Рис. 4.12. Принципиальная схема организации поиска документов Рассмотрим пример упрощенной реализации документальной БД в среде ре- ляционной СУБД. С логической точки зрения она имеет «стандартную» струк- туру и включает две компоненты: регистрационные карты (РК) и полные тексты (ПТ). Регистрационные карты представляют собой форматированные записи, со- держащие относительно стандартный набор библиографических данных, а также ссылку на соответствующий полный текст (рис. справа). Полные тексты документов состоят из страниц двух типов: логических, то есть структурных единиц текста – пунктов, параграфов, статьей; физических – фрагментов одинаковой длины, принудительно разбиваю- щих длинный неструктурированный текст. Организация физической структура документальной БД предполагает нали- чие следующих элементов: Таблица ПТ – одна или несколько таблиц, в которых содержатся полные тек- сты документов. На логическом уровне образует представленную на рис.2 иерар- хическую структуру: БД, документ, страница. Словарь ПТ – таблица представляет собой список ключевых слов и стан- дартных словосочетаний, извлеченных из текста, сопровождаемых частотами по- явления. Инверсная таблица ПТ (или инверсный список ПТ) – таблица, содержащая список ключевых слов и словосочетаний, сопровождаемых номерами страниц. Словарь и инверсная таблицы используются для сквозного полнотекстового поиска. Таблица РК – таблица регистрационных карт, каждая запись которой содер- жит заглавие, дату регистрации, номер, вид документа, ссылки на страницы пол- ного текста (ПТ) и другие поля. Словарь РК – это таблица, содержащая значения полей регистрационных карт совместно с частотой появления и ссылками на записи таблицы РК. Инверсная таблица РК (или инверсный список РК) содержит слова и слово- сочетания и ссылки на записи таблицы РК. Словарная и инверсная таблицы используются для поиска записей РК, с по- следующим доступом к страницам полного текста. Наряду со словарем РК иногда может использоваться словарь синонимов, служащий для обеспечения двуязычного поиска в словарных таблицах. Благодаря такой организации физической структуры документной БД можно выполнять поиск двух видов: поиск по регистрационным картам и поиск по полным текстам. Первый вид поиска соответствует случаю, когда пользователь что-то знает о документе, например, название, автора, дату выпуска и т.д. Самый простой слу- чай, когда пользователь знает все. Тогда просто анализируется таблица РК, из нее отбирается нужная регистрационная карта, из которой отбирается указатели на страницы полного текста документа. Далее эти страницы выбираются из таблицы ПТ. Несколько сложнее поиск в случае, когда пользователь знает только часть атрибутов регистрационной карты, например, только одно название или только словосочетание из названия. В этом случае предварительно анализируется сло- варь и инверсная таблица РК, после чего отыскивается сама РК. Полнотекстовый поиск соответствует ситуации, когда пользователь ничего не знает о документе и может указать только ключевые слова для него. В этом случае прежде всего используется инверсная таблица ПТ, из которой отыскива- ется список страниц, содержащих эти слова. Если такой список оказывается очень велик, может быть использован словарь ПТ, позволяющий сократить его в соответствии с частотой появления слов. Соответствие терминологии, принятой в реляционной модели БД и доку- ментной модели БД приведено в табл. 4.3. Табл. 4.3. Соответствие терминов Реляционная модель БД Документная модель БД Схема данных База данных Таблица Коллекция документов Строка Документ Идентификатор строки ID документа Документные базы данных обеспечивают разнообразные функциональные возможности запросов. Одним из преимуществ документных баз данных по сравнению с хранили- щами типа «ключ-значение» является то, что можно послать запрос к содержа- нию документа, не извлекая весь документ по его ключу, чтобы просмотреть его. Это свойство делает такие базы данных похожими на модель запроса реляцион- ных БД. Рассмотрим некоторые запросы к базе данных MongoDB, в которой можно хранить документы. Допустим, мы хотим вернуть все документы из коллекции заказов (все строки из таблицы заказов). На языке SQL этот запрос выглядит так: SELECT * FROM Заказы; Эквивалентный запрос в оболочке базы Mongo выглядит следующим обра- зом: db. Заказы. find () Выбор заказов для конкретного идентификатора, равного 88Зс2с5Ь4е5Ь, можно записать так: SELECT * FROM Заказы WHERE ID_покупателя = "883с2с5Ь4е5Ь"; Эквивалентный запрос в базе Mongo на получение всех заказов для конкрет- ного идентификатора выглядит следующим образом: db.order.find({" ID_покупателя":"883c2c5b4e5b"}) Аналогично выбрать записи orderld и orderDate для заданного клиента на языке SQL можно записать так: SELECT orderId,orderDate FROM order WHERE customerId = "883с2с5Ь4е5Ь" Эквивалент этого запроса в базе Mongo можно записать следующим обра- зом: db.Заказы.find({ID_покупателя:"883c2c5b4e5b"}, {ID_заказа:1, Дата_за- каза:1}) Аналогично можно формировать запросы для подсчета, суммирования и вы- полнения других операций. Преимущества документных БД в сравнении реляционными БД: 1. В сравнении с реляционными базами данных лучшая производитель- ность при индексировании больших объемов данных и большим количестве за- просов на чтение. 2. Легче масштабируются в сравнении с SQL решениями. 3. Децентрализированы – работа на скластере. 4. Легко менять «схему» данных: не нужно выполнять никаких операций обновления для добавления новых полей. 5. Хранение неструктурированных данных. 6. Единое место хранения всей информации об объекте, что требует меньше операций вида «join». 7. Простой интерфейс общения с БД (ключ → значение, нет SQL). Недостатки документных БД: 1. Отсутствие транзакционной логики и контроля целостности в большин- стве реализаций: необходимо реализовывать ее в логике приложения. 2. Для обработки данных необходимо использование дополнительного языка программирования. Рассмотрим примеры, где документные БД подходят лучше всего: Регистрация событий. Приложения по-разному регистрируют события; на предприятиях суще- ствует множество разных приложений, желающих регистрировать события. До- кументные базы данных могут хранить все эти типы событий и действовать как центральное хранилище событий. Это особенно важно в ситуациях, когда тип данных, собираемых событиями, постоянно изменяется. Системы управления информационным наполнением, блог-платформы. Поскольку документные базы данных не имеют предопределенной схемы и обычно понимают JSОN-документы, они хорошо работают в системах управле- ния информационным наполнением или в приложениях по публикации веб-сай- тов, управляющих комментариями пользователей, их регистрацией, профилями, а также представлением документов в веб. Веб-аналитика и аналитика в реальном времени. Документные базы данных могут хранить данные, необходимые для анализа в реальном времени; поскольку части документов можно обновлять, можно очень легко хранить представления страниц или информацию об отдельных посетите- лях, а также добавлять новые показатели эффективности без изменения схемы. Приложения для электронной коммерции. Приложения для электронной коммерции часто должны иметь гибкую схему товаров и заказов, а также возможность изменять свои модели данных без доро- гостоящего перепроектирования кода базы данных или обновления структуры базы. Документные БД не рекомендуется использовать в следующих задачах. Сложные транзакции, охватывающие разные операции. Если есть необходимость выполнять атомарные операции с несколькими до- кументами, то документные базы данных для этого, как правило, не подходят. Запросы к изменяющейся агрегатной структуре. Гибкая схема означает, что база данных не накладывает на схему никаких ограничений. Данные сохраняются в виде сущностей приложения. Если возни- кает необходимость в специальном запросе к этим сущностям, то запросы можно изменять. Поскольку данные сохраняются как агрегат, то при постоянном изме- нении структуры агрегата необходимо сохранять его с наименьшим уровнем де- тализации, т.е. фактически нормализовать данные. В таком сценарии документ- ная база данных может оказаться неработоспособной. Изучение особенностей документных баз данных позволяет сделать следу- ющие выводы: 1. Единицей хранения в документных БД является документ, основная часть которого – неструктурированный текст. 2. Документальная БД включает в себя как минимум три области хранения данных: файл словаря, инверсный список, текстовый файл. 3. Поиск в документных БД может быть реализован по метаданным (реги- страционным картам) или ключевым словам непосредственно в контенте доку- мента. 4. Схема данных отсутствует. Не нужно выполнять никаких операций об- новления для добавления новых полей. 5. В системе управления документными БД отсутствует транзакционная логика и контроль целостности. 6. Для обработки данных необходимо использование дополнительного языка программирования. 4.5. Базы данных «семейство столбцов» Семейство столбцов (столбчатая БД) – это коллекция строк, содержащая множество столбцов, ассоциированных с ключом строки. Семейства столбцов группируют взаимосвязанные данные, доступ к которым обеспечивается как к единому целому. Основной единицей хранения в базе данных является столбец, состоящий из пары «имя-значение», в которой имя играет роль ключа. Каждая из пар «ключ- значение» может храниться с меткого времени, которая используется для того, чтобы задавать срок действия данных, разрешать конфликты записи, обрабаты- вать устаревшие данные и выполнять другие функции. Модель семейства столбцов можно представить, как двухуровневую агре- гатную структуру. Как и в хранилищах типа «ключ-значение», главный ключ – это идентификатор строки, отмечая нужный в данный момент агрегат. Отличительной особенностью «семейства столбцов» является то, что строка-агрегат сама состоит из ассоциативного массива более детализированных значений. Эти значения второго уровня называются столбцами (рис. 4.13). Помимо доступа к строкам как к единому целому, операции также допус- кают извлечение конкретного столбца, так что, для того чтобы получить имя кли- ента в БД на рис. 4.13 можно написать команду наподобие get ( '1234', 'name'). Столбцы организуются в семейства. Каждый столбец является частью од- ного семейства столбцов и единица доступа. Данные в конкретном семействе столбцов обычно доступны одновременно. Итак, данные в столбчатой базе данных структурированы следующим обра- зом: Ориентация по строкам: каждая строка – это агрегат (например, клиент с идентификатором 1234), а семейства столбцов содержат фрагменты данных (про- филь, история заказов) в этом агрегате. Ориентация по столбцам: каждое семейство столбцов определяет тип за- писи (например, профили клиентов), причем каждой записи соответствуют строки. В таком случае строку можно интерпретировать как объединение записей из всех семейств столбцов. Последний аспект отражает «столбцовую» природу баз данных типа «семей- ство столбцов». Базы данных этого типа имеют двумерный характер. 1234 Имя Яковлев С.А. Ключ строки Адрес Данные Оплата Данные 0 DR1001 Данные 0RD1002 Данные 0RD1003 Данные 0RD1004 Данные П роф иль За ка зы Ключ столбца Значение столбца Семейство столбцов Рис. 4.13. Столбчатая БД Представлять семейства столбцов в виде таблиц неправильно, т.к. в этой БД можно добавлять любой столбец в любую строку, а строки могут иметь самые разные ключи. Новые столбцы добавляются в строки при обычном доступе к базе данных. Определение нового семейства столбцов происходит намного реже и может вызвать остановку работы базы данных. Поскольку столбцы можно добавлять свободно, список элементов можно легко моделировать, сделав каждый элемент отдельным столбцом. Строка семейства столбцов – это агрегат. Строки бывают широкими и «ху- дыми». «Худые» строки содержат несколько столбцов, причем одни и те же столбцы используются в разных строках. В данном случае семейство столбцов определяет тип записи, каждая строка является записью, а каждый столбец – полем. Широкая строка содержит много разных столбцов (возможно, тысячи). Ши- рокое семейство столбцов моделирует список, в котором каждый столбец пред- ставляет собой элемент в этом списке. Широкие семейства столбцов могут опре- делять определенный порядок следования своих столбцов. Каждая из пар «ключ-значение» всегда хранится с меткого времени, которая используется для того, чтобы задавать срок действия данных, разрешать кон- фликты записи, обрабатывать устаревшие данные и выполнять другие функции. Если данные столбца больше не используются, то это место можно восстановить позднее на этапе уплотнения. Рассмотрим пример: { Имя: "Полное имя", Значение: "Яковлев Сергей", Метка: 12345667890 } Здесь столбец «Имя» содержит ключ строки «Полное имя» и значение «Яко- влев Сергей», а также связанную с ними метку времени «12345667890». Строка – это коллекция столбцов, ассоциированных с ключом; коллекция таких строк образует семейство столбцов. Если семейство столбцов состоит из обычных столбцов, оно называется стандартным. Каждое семейство столбцов можно сравнить с контейнером строк в таблице реляционной БД, в которой ключ идентифицирует строку, а строка состоит из множества столбцов. Отличие заключается в том, что разные строки не обязаны содержать одинаковые столбцы, причем столбцы могут добавляться в любую строку в любое время и добавлять их в остальные строки не обязательно, напри- мер: //Семейство столбцов {//row "Яковлев Сергей": { Имя: "Сергей", Фамилия: "Яковлев", Последний визит: "2019/05/12" } //Строка "Татарникова Татьяна": { Имя: "Татьяна", Фамилия: "Татарникова", Город: "Санкт-Петербург" } } В этом примере строки «Яковлев Сергей» и «Татарникова Татьяна» имеют разные столбцы; обе эти строки являются частью семейства столбцов. Соответствие терминологии, принятой в реляционной модели БД и доку- ментной модели БД приведено в табл. 4.4. Табл. 4.4. Соответствие терминов Реляционная модель БД Столбчатая БД Атрибут Столбец Строка Коллекция столбцов Идентификатор строки Ключ строки Таблица Агрегат (семейство столбцов) Рассмотрим примеры, где БД типа «семейство столбцов» подходят лучше всего: Регистрация событий. Семейства столбцов, способные хранить любые структуры данных, приспо- соблены для хранения информации о событиях, например, состояние приложе- ния или ошибки, обнаруженные приложением. Системы управления информационным: наполнением, блог-платформы. С помощью семейств столбцов можно хранить записи блогов с ключевыми словами, категориями, ссылками и обратными ссылками в разных столбцах. Ком- ментарии можно хранить либо в той же строке, либо переместить в другое про- странство ключей; аналогично пользователей блога и актуальные блоги можно поместить в разные семейства столбцов. Счетчики. В веб-приложениях часто возникает необходимость подсчета и классифика- ции посетителей, чтобы вычислить аналитические показатели веб-страницы. По- сле создания семейства столбцов каждому пользователю веб-приложения можно выделить произвольное количество столбцов для посещенных им веб-страниц. Срок действия. Иногда возникает необходимость создать демоверсии для пользователей или в определенное время размещать на веб-сайте рекламные объявления. Для этого можно использовать столбцы с ограниченным сроком действия: то есть создавать столбцы, которые автоматически удаляются по истечении определенного пери- ода времени. Это время называется ТТL (Time То Live – время существования) и задается в секундах. По истечении периода ТТL столбец удаляется; если столбец больше не существует, запрос можно отменить, а рекламное объявление снять. Существуют проблемы, которые семейство столбцов решает неэффективно. Например, это относится к системам, использующим для выполнения операций чтения и записи транзакции. Если необходимо, чтобы база данных агрегировала данные с помощью запросов (например, SUM или AVG), это следует делать на клиентской стороне с помощью данных, извлеченных из всех строк. Столбчатые БД не стоит использовать для создания ранних прототипов или первичных промышленных систем: на ранних стадиях еще не известно, как изме- нится шаблон запросов, а изменяя шаблоны запросов, мы вынуждены изменять проект семейства столбцов. Изучение особенностей баз данных типа «семейство столбцов» позволяет сделать следующие выводы: 1. Коллекция столбцов – это строка (агрегат). 2. Коллекция строк образует семейство столбцов. 3. Единицей хранения является столбец. 4. Столбцы могут добавляться в любую строку в любое время. 5. БД типа «семейство столбцов» в основном используются для регистра- ции событий и счета. 6. В столбчатых БД отсутствуют средства реализации итоговых функций и транзакций. 4.6. Графовые БД Основу графовой модели БД образуют маленькие записи со сложными свя- зями. В такой БД граф – это не диаграмма, а структура данных с узлами, соеди- ненными ребрами. На рис. 4.14 показана веб-информация с очень маленькими узлами и много- численными связями между ними. Работая с этой структурой, мы можем задавать вопросы вроде «найти книгу в категории «Базы данных», написанную кем-то, чей друг мне нравится. Друг Категория Автор Друг Иван Яковлев С.А. Анна Управление данными Нравится Нравится Коллега Татарникова Т.М. Базы данных Категория ОАО «Аналитика» Работает Работает Автор Максим Работает Друг Илья Руслан Друг Екатерина Банки и базы данных Друг Друг Ученик Нравится Нравится |