Документоориентированная база данных или хранилище документов — это компьютерная программа и система хранения данных, предназначенная для хранения, извлечения и управления документоориентированной информацией, также известной как полуструктурированные данные . [1]
Документо-ориентированные базы данных являются одной из основных категорий баз данных NoSQL , и популярность термина «документно-ориентированная база данных» выросла [2] с появлением самого термина NoSQL. Базы данных XML — это подкласс документо-ориентированных баз данных, оптимизированных для работы с документами XML . Базы данных графов аналогичны, но в них добавлен еще один уровень — отношения , который позволяет им связывать документы для быстрого обхода.
Документо-ориентированные базы данных по своей сути являются подклассом хранилища «ключ-значение» , еще одной концепции базы данных NoSQL. Разница [ противоречивая ] заключается в способе обработки данных; в хранилище «ключ-значение» данные считаются по своей сути непрозрачными для базы данных, тогда как документо-ориентированная система полагается на внутреннюю структуру документа для извлечения метаданных , которые ядро базы данных использует для дальнейшей оптимизации. Хотя разница часто незначительна из-за инструментов в системах, [a] концептуально хранилище документов спроектировано так, чтобы предложить более богатый опыт работы с современными методами программирования.
Базы данных документов [b] сильно контрастируют с традиционными реляционными базами данных (RDB). Реляционные базы данных обычно хранят данные в отдельных таблицах , определяемых программистом, и один объект может быть распределен по нескольким таблицам. Базы данных документов хранят всю информацию для данного объекта в одном экземпляре базы данных, и каждый хранимый объект может отличаться от другого. Это устраняет необходимость объектно-реляционного сопоставления при загрузке данных в базу данных.
Центральным понятием документоориентированной базы данных является понятие документа . Хотя каждая реализация документо-ориентированной базы данных отличается деталями этого определения, в целом все они предполагают, что документы инкапсулируют и кодируют данные (или информацию) в каком-то стандартном формате или кодировке. Используемые кодировки включают XML , YAML , JSON , а также двоичные формы, такие как BSON .
Документы в хранилище документов примерно эквивалентны концепции программирования объекта. Они не обязаны придерживаться стандартной схемы и не будут иметь одинаковые секции, слоты, детали или ключи. Обычно программы, использующие объекты, имеют множество различных типов объектов, и эти объекты часто имеют множество необязательных полей. Каждый объект, даже принадлежащий одному классу, может выглядеть по-разному. Хранилища документов похожи тем, что позволяют хранить в одном хранилище документы разных типов, позволяют полям внутри них быть необязательными и часто позволяют кодировать их с использованием разных систем кодирования. Например, ниже представлен документ, закодированный в формате JSON:
{ «Имя» : «Боб» , «Адрес» : «Оук-стрит, 5». , «Хобби» : «парусный спорт» } Второй документ может быть закодирован в XML как:
<contact> <firstname> Боб </firstname> <lastname> Смит </lastname> <phone type= "Cell" > (123) 555-0178 </phone> <phone type= "Work" > (890) 555- 0133 </phone> <адрес> <type> Дом </type> <street1> 123 Back St. </street1> <city> Boys </city> <state> AR </state> <zip> 32225 </zip > <country> США </country> </address> </contact> Эти два документа имеют некоторые общие структурные элементы, но каждый из них также имеет уникальные элементы. Структура, текст и другие данные внутри документа обычно называются содержимым документа , и на них можно ссылаться с помощью методов поиска или редактирования (см. Ниже). В отличие от реляционной базы данных, где каждая запись содержит одни и те же поля, а неиспользуемые поля остаются пустыми; в приведенном выше примере ни в одном документе (записи) нет пустых «полей». Этот подход позволяет добавлять новую информацию к некоторым записям, не требуя, чтобы все остальные записи в базе данных имели одинаковую структуру.
Базы данных документов обычно предоставляют дополнительные метаданные , которые можно связать и хранить вместе с содержимым документа. Эти метаданные могут быть связаны со средствами, которые хранилище данных предоставляет для организации документов, обеспечения безопасности или других функций, специфичных для реализации.
Основные операции, которые документо-ориентированная база данных поддерживает для документов, аналогичны операциям в других базах данных, и хотя терминология не полностью стандартизирована, большинство практиков признают их как CRUD :
Документы обращаются в базе данных с помощью уникального ключа , который представляет этот документ. Этот ключ представляет собой простой идентификатор (или ID), обычно строку , URI или путь . Ключ можно использовать для получения документа из базы данных. Обычно база данных сохраняет индекс ключа для ускорения поиска документа, а в некоторых случаях ключ необходим для создания или вставки документа в базу данных.
Еще одной определяющей характеристикой документо-ориентированной базы данных является то, что помимо простого поиска по ключу к документу, который можно использовать для извлечения документа, база данных предлагает API или язык запросов, который позволяет пользователю извлекать документы на основе содержания (или метаданные). Например, вам может понадобиться запрос, который извлекает все документы с определенным полем, для которого установлено определенное значение. Набор доступных API-интерфейсов запросов или функций языка запросов, а также ожидаемая производительность запросов значительно варьируются от одной реализации к другой. Аналогичным образом, конкретный набор доступных параметров индексирования и конфигурации сильно различаются в зависимости от реализации.
Именно здесь хранилище документов больше всего отличается от хранилища «ключ-значение». Теоретически значения в хранилище «ключ-значение» непрозрачны для хранилища и, по сути, представляют собой черные ящики. Они могут предлагать поисковые системы, аналогичные системам хранилища документов, но могут иметь меньшее представление об организации контента. Хранилища документов используют метаданные документа для классификации содержимого, что позволяет им, например, понять, что одна серия цифр — это номер телефона, а другая — почтовый индекс. Это позволяет им выполнять поиск по этим типам данных, например, по всем телефонным номерам, содержащим 555, при этом почтовый индекс 55555 будет игнорироваться.
Базы данных документов обычно предоставляют некоторый механизм обновления или редактирования содержимого (или метаданных) документа, позволяя заменять либо весь документ, либо отдельные структурные части документа.
Реализации базы данных документов предлагают различные способы организации документов, включая понятия
Иногда эти организационные понятия различаются по степени их логического и физического (например, на диске или в памяти) представлений.
Документно-ориентированная база данных — это специализированное хранилище значений ключей , которое само по себе является еще одной категорией баз данных NoSQL. В простом хранилище «ключ-значение» содержимое документа непрозрачно. Документно-ориентированная база данных предоставляет API или язык запросов/обновлений, который предоставляет возможность запрашивать или обновлять данные на основе внутренней структуры документа . Эта разница может быть незначительной для пользователей, которым не нужны более широкие API-интерфейсы запросов, извлечения или редактирования, которые обычно предоставляются базами данных документов. Современные хранилища «ключ-значение» часто включают функции для работы с метаданными, стирая границы между хранилищами документов.
Некоторые системы поиска (так называемые системы поиска информации ), такие как Apache Solr и Elasticsearch, обеспечивают достаточное количество основных операций с документами, чтобы соответствовать определению документо-ориентированной базы данных.
В реляционной базе данных данные сначала классифицируются по ряду предопределенных типов, и создаются таблицы для хранения отдельных записей или записей каждого типа. Таблицы определяют данные в полях каждой записи . Это означает, что каждая запись в таблице имеет одинаковую общую форму. Администратор также определяет связи между таблицами, выбирает определенные поля, которые, по его мнению, будут наиболее часто использоваться для поиска, и определяет для них индексы . Ключевая концепция реляционного дизайна заключается в том, что любые данные, которые могут повторяться, обычно помещаются в отдельную таблицу, и если эти экземпляры связаны друг с другом, для их группировки выбирается столбец — внешний ключ . Этот подход известен как нормализация базы данных . [3]
Например, приложению адресной книги обычно необходимо хранить имя контакта, дополнительное изображение, один или несколько номеров телефонов, один или несколько почтовых адресов и один или несколько адресов электронной почты. В канонической реляционной базе данных для каждой из этих строк будут созданы таблицы с предопределенными полями для каждого бита данных: таблица CONTACT может включать столбцы FIRST_NAME, LAST_NAME и IMAGE, а таблица PHONE_NUMBER может включать COUNTRY_CODE, AREA_CODE, PHONE_NUMBER и TYPE ( дом, работа и т. д.). Таблица PHONE_NUMBER также содержит столбец внешнего ключа «CONTACT_ID», который содержит уникальный идентификационный номер, присвоенный контакту при его создании. Чтобы воссоздать исходный контакт, ядро базы данных использует внешние ключи для поиска связанных элементов в группе таблиц и восстановления исходных данных.
Напротив, в базе данных, ориентированной на документы, может отсутствовать внутренняя структура, которая напрямую отображалась бы на концепцию таблицы, а поля и отношения обычно не существуют как предопределенные концепции. Вместо этого все данные объекта помещаются в один документ и сохраняются в базе данных как одна запись. В примере с адресной книгой документ будет содержать имя контакта, изображение и любую информацию о контакте — все в одной записи. Доступ к этой записи осуществляется через ее ключ, который позволяет базе данных извлекать и возвращать документ приложению. Для получения связанных данных не требуется никакой дополнительной работы; все это возвращается в одном объекте.
Ключевое различие между документо-ориентированной и реляционной моделями заключается в том, что форматы данных не определены заранее в случае документа. В большинстве случаев любой вид документа может храниться в любой базе данных, и эти документы могут изменяться по типу и форме в любое время. Если вы хотите добавить COUNTRY_FLAG к CONTACT, это поле можно добавить в новые документы по мере их вставки, это не окажет никакого влияния на базу данных или уже сохраненные существующие документы. Чтобы облегчить поиск информации из базы данных, документо-ориентированные системы обычно позволяют администратору предоставлять базе данных подсказки для поиска определенных типов информации. Они работают аналогично индексам в реляционном случае. Большинство из них также предлагают возможность добавлять дополнительные метаданные помимо содержимого самого документа, например, помечать записи как часть адресной книги, что позволяет программисту извлекать связанные типы информации, например «все записи адресной книги». . Это обеспечивает функциональность, аналогичную таблице, но отделяет концепцию (категории данных) от ее физической реализации (таблиц).
В классической нормализованной реляционной модели объекты в базе данных представлены как отдельные строки данных без какой-либо внутренней структуры, кроме той, которая задается им при извлечении. Это приводит к проблемам при попытке перевода программных объектов в связанные с ними строки базы данных и обратно — проблема, известная как объектно-реляционное несоответствие импеданса . [4] Хранилища документов более тесно, а в некоторых случаях напрямую, отображают объекты программирования в хранилище. Они часто продаются под термином NoSQL .
Большинство баз данных XML являются документо-ориентированными базами данных.
Документо-ориентированные базы данных или хранилища документов — это базы данных NoSQL, в которых данные хранятся в виде документов. Хранилища документов — это тип хранилища «ключ-значение»: каждый документ имеет уникальный идентификатор — его ключ — и сам документ служит значением.