Базы данных nosql реферат

Обновлено: 25.06.2024

Базы данных NoSQL специально созданы для определенных моделей данных и обладают гибкими схемами, что позволяет разрабатывать современные приложения. Базы данных NoSQL получили широкое распространение в связи с простотой разработки, функциональностью и производительностью при любых масштабах. Ресурсы, представленные на этой странице, помогут разобраться с базами данных NoSQL и начать работу с ними.

Базы данных NoSQL используют разнообразные модели данных для доступа к данным и управления ими. Базы данных таких типов оптимизированы для приложений, которые работают с большим объемом данных, нуждаются в низкой задержке и гибких моделях данных. Все это достигается путем смягчения жестких требований к непротиворечивости данных, характерных для других типов БД.

Рассмотрим пример моделирования схемы для простой базы данных книг.

Базы данных NoSQL хорошо подходят для многих современных приложений, например мобильных, игровых, интернет‑приложений, когда требуются гибкие масштабируемые базы данных с высокой производительностью и широкими функциональными возможностями, способные обеспечивать максимальное удобство использования.

Гибкость. Как правило, базы данных NoSQL предлагают гибкие схемы, что позволяет осуществлять разработку быстрее и обеспечивает возможность поэтапной реализации. Благодаря использованию гибких моделей данных БД NoSQL хорошо подходят для частично структурированных и неструктурированных данных.
Масштабируемость. Базы данных NoSQL рассчитаны на масштабирование с использованием распределенных кластеров аппаратного обеспечения, а не путем добавления дорогих надежных серверов. Некоторые поставщики облачных услуг проводят эти операции в фоновом режиме, обеспечивая полностью управляемый сервис.
Высокая производительность. Базы данных NoSQL оптимизированы для конкретных моделей данных и шаблонов доступа, что позволяет достичь более высокой производительности по сравнению с реляционными базами данных.
Широкие функциональные возможности. Базы данных NoSQL предоставляют API и типы данных с широкой функциональностью, которые специально разработаны для соответствующих моделей данных.

Документ В коде приложения данные часто представлены как объект или документ в формате, подобном JSON, поскольку для разработчиков это эффективная и интуитивная модель данных. Документные базы данных позволяют разработчикам хранить и запрашивать данные в БД с помощью той же документной модели, которую они используют в коде приложения. Гибкий, полуструктурированный, иерархический характер документов и документных баз данных позволяет им развиваться в соответствии с потребностями приложений. Документная модель хорошо работает в каталогах, пользовательских профилях и системах управления контентом, где каждый документ уникален и изменяется со временем. Amazon DocumentDB (совместимая с MongoDB) и MongoDB — распространенные документные базы данных, которые предоставляют функциональные и интуитивно понятные API для гибкой разработки.

Графовые БД. Графовые базы данных упрощают разработку и запуск приложений, работающих с наборами сложносвязанных данных. Типичные примеры использования графовых баз данных – социальные сети, сервисы рекомендаций, системы выявления мошенничества и графы знаний. Amazon Neptune – это полностью управляемый сервис графовых баз данных. Neptune поддерживает модель Property Graph и Resource Description Framework (RDF), предоставляя на выбор два графовых API: TinkerPop и RDF / SPARQL. К числу распространенных графовых БД относятся Neo4j и Giraph.

БД в памяти. Часто в игровых и рекламных приложениях используются таблицы лидеров, хранение сессий и аналитика в реальном времени. Такие возможности требуют отклика в пределах нескольких микросекунд, при этом резкое возрастание трафика возможно в любой момент. Amazon MemoryDB для Redis – это совместимый с Redis надежный сервис базы данных в памяти, который уменьшает задержку чтения до миллисекунд и обеспечивает надежность в нескольких зонах доступности. MemoryDB специально создана для обеспечения сверхвысокой производительности и надежности, поэтому ее можно использовать как основную базу данных для современных приложений на базе микросервисов. Amazon ElastiCache – это полностью управляемый сервис кэширования в памяти, совместимый с Redis и Memcached для обслуживания рабочих нагрузок с низкой задержкой и высокой пропускной способностью. Такие клиенты, как Tinder, которым требуется, чтобы их приложения давали отклик в режиме реального времени, пользуются системами хранения данных в памяти, а не на диске. Еще одним примером специально разработанного хранилища данных является Amazon DynamoDB Accelerator (DAX). DAX позволяет DynamoDB считывать данные в несколько раз быстрее.

Поисковые БД. Многие приложения формируют журналы, чтобы разработчикам было проще выявлять и устранять неполадки. Amazon Elasticsearch Service (Amazon ES) – специально разработанный сервис для визуализации и аналитики автоматически генерируемых потоков данных в режиме, близком к реальному времени, путем индексирования, агрегации частично структурированных журналов и метрик и поиска по ним. Amazon ES – это также мощная высокопроизводительная поисковая система для полнотекстового поиска. Компания Expedia задействует более 150 доменов Amazon ES, 30 ТБ данных и 30 миллиардов документов для разнообразных особо важных примеров использования – от операционного мониторинга и устранения неисправностей до отслеживания стека распределенных приложений и оптимизации затрат.

Существует множество типов БД NoSQL с различными особенностями, но в таблице ниже приведены основные отличия баз данных NoSQL от SQL.

Подходящие рабочие нагрузки

Реляционная модель нормализует данные и преобразует их в таблицы, состоящие из строк и столбцов. Схема жестко задает таблицы, строки, столбцы, индексы, отношения между таблицами и прочие элементы базы данных. Такая БД обеспечивает целостность ссылочных данных в отношениях между таблицами.

Реляционные базы данных обеспечивают набор свойств ACID: атомарность, непротиворечивость, изолированность, надежность.

Атомарность требует, чтобы транзакция выполнялась полностью или не выполнялась вообще.
Непротиворечивость означает, что сразу по завершении транзакции данные должны соответствовать схеме базы данных.
Изолированность требует, чтобы параллельные транзакции выполнялись отдельно друг от друга.
Надежность подразумевает способность восстанавливаться до последнего сохраненного состояния после непредвиденного сбоя в системе или перебоя в подаче питания.

В следующей таблице приведено сравнение терминологии некоторых баз данных NoSQL с терминологией баз данных SQL.

Как известно, задача разработки СУБД в ИТ-индустрии изначально не стояла, но были актуальны прикладные задачи, требующие обработки массивов структурированной информации. Постепенно выяснилось, что во многих случаях алгоритмы накопления, поиска и анализа данных одинаковы, а следовательно, их можно сделать универсальными и выделить в виде отдельных инструментальных средств — систем управления базами данных. К прикладному ПО обработки больших объемов информации всегда предъявляются одни и те же требования — скорость работы и стоимость разработки, которые трансформируются в требования к используемой СУБД. Чем гибче и богаче возможности СУБД, тем проще разработчику прикладной системы приспосабливать их для своих нужд, а значит, тем меньше оказывается стоимость создаваемого ПО.

Таким образом, можно сформулировать наиболее общие требования к СУБД — гибкость и скорость работы. Другие часто предъявляемые и не менее важные требования, такие как поддержка широко распространенных языков запросов или возможность параллельной обработки данных, изначально не были ключевыми. Изменение требований к прикладному ПО влечет за собой изменение требований к СУБД, откуда следует, что развитие технологий СУБД определяется потребностями разработчиков прикладного ПО. Именно поэтому всевозможные экспериментальные СУБД часто остаются невостребованными даже в том случае, если превосходят свои аналоги по каким-либо характеристикам.

За многолетнюю историю развития СУБД было выработано несколько моделей представления структурированной информации: иерархическая, сетевая, реляционная, объектно-реляционная и т. д. Наибольшее распространение получила реляционная модель, предложенная Эдгаром Коддом в 1970 году, которая надолго стала стандартом представления структурированной информации. Причины этого вытекают из сформулированных требований к СУБД. Во-первых, реляционная модель оказалась достаточно простой, с точки зрения прикладного программиста. Во-вторых, она обладает достаточной гибкостью и позволяет представлять информацию из самых разных предметных областей. В-третьих, в рамках этой модели используется мощный и удобный подход к манипулированию данными (реляционная алгебра), впоследствии оформленный в виде языка SQL. В-четвертых, простота и естественность реляционной алгебры позволили создать высокопроизводительные и универсальные алгоритмы выполнения запросов, удовлетворяющие большую часть потребностей разработчиков прикладных систем. Наконец, к сегодняшнему дню создано множество инструментальных средств, ориентированных на обработку реляционных данных, что дает еще одно преимущество реляционных СУБД.

Итак, при разработке прикладного ПО из исходных требований следует выбор модели представления информации, а уже из нее следует выбор конкретной СУБД. Эта схема может показаться абстрактной в силу того, что на текущий момент доминирующей является реляционная модель, а выбор СУБД производится из достаточно ограниченного списка, который заранее продиктован другими факторами, такими как интеграция, простота поддержки, стоимость и т. д.

Оба отступления от базовых принципов реляционной модели (введение неатомарных типов данных и тонкое управление алгоритмами обработки) напрямую следуют из особенностей самой модели, провозглашающей универсальность способов хранения информации и алгоритмов ее обработки. За этой универсальностью скрывается невозможность учета специфики данных, позволяющей существенно оптимизировать работу алгоритмов.

Допустим, требуется организовать хранение большого множества чисел и быстро выполнять операции поиска, добавления и удаления числа. Для этого в реляционной базе создается таблица с одним числовым полем, а по этому полю формируется поисковый индекс на основе B-дерева. Такое решение работает быстро, но предполагает дублирование информации (числа хранятся и в самой таблице, и в поисковом индексе). Более эффективным было бы использование только B-дерева, но реляционные СУБД не всегда способны это определить.

Данный пример может показаться слишком простым, но похожая ситуация реализована в Triple Storages (хранение графов семантических сетей в семантическом Web), отвечающих за хранение и обработку графов семантических связей. Каждая дуга графа представляет собой три числа (два кода вершин и один код окраски). Множество всех дуг можно было бы хранить в виде реляционной таблицы с необходимыми поисковыми индексами, но вместо этого хранят только поисковые индексы, поскольку каждый из них содержит всю информацию о каждой дуге.

Третий пример — полнотекстовые поисковые системы Интернета. Их база данных должна содержать поисковые слова и коды документов, в которых эти слова являются ключевыми. Это несложно сделать с помощью реляционной таблицы, состоящей из двух полей — поисковое слово и код документа. Если слово встречается в нескольких документах или документ имеет несколько ключевых слов, то таблица содержит несколько записей.

Возможна существенная оптимизация рассмотренного примера: скажем, вместо текстового представления слова можно хранить его целочисленный код, а вместо кода документа хранить BLOB, где будут содержаться коды всех документов, имеющих отношение к данному слову. Дальнейшая оптимизация в рамках реляционного подхода невозможна, но ее можно провести посредством так называемого инвертированного индекса. Коды документов сортируются по возрастанию, и в полученном списке вычисляются разницы между кодами соседних документов. Получается последовательность, состоящая из кода первого документа и множества чисел небольшой величины. Она хорошо сжимается алгоритмами энтропийной компрессии (например, алгоритмом Лемпеля — Зива-Велча), в результате чего значительно сокращается объем ввода/вывода, ускоряется загрузка информации с диска и в конечном счете растет скорость полнотекстового поиска.

Задача не для реляционной СУБД

Имеется набор из 10 тыс. датчиков, один раз в секунду отправляющих показатели (вещественные числа). Показатели датчиков стабильны и изменяются плавно. Необходимо в интерактивном режиме анализировать месячные данные и определять, приводит ли резкое изменение одного показателя больше чем на фиксированную пороговую величину к изменению другого показателя больше чем на другую пороговую величину. Желательно использовать обычный ПК, не привлекая специальные решения (RAID-массивы и т. п.).

Если матрицу показаний разворачивать по вертикали, то записи реляционных таблиц будут соответствовать номерам датчиков, а поля — моментам времени. В общей сложности получится совокупность из 2 592 000 полей, разбитых по таблицам. Очевидно, что работать с такой базой очень сложно.

Таким образом, классический реляционный подход не дает эффективного решения задачи.

В рассмотренных примерах информация хотя и представима в терминах реляционной модели, но обладает спецификой, которую можно эффективно использовать для оптимизации работы реляционной СУБД. Однако по мере роста объемов базы рано или поздно наступает предел таких оптимизаций.

Основные концепции NoSQL

Нестрогое доказательство теоремы CAP основано на простых рассуждениях. Пусть распределенная система состоит из N серверов, каждый из которых обрабатывает запросы некоторого числа клиентских приложений (рис. 1). При обработке запроса сервер должен гарантировать актуальность информации, содержащейся в отсылаемом ответе на запрос, для чего предварительно нужно выполнить синхронизацию содержимого его собственной базы с другими серверами. Таким образом, серверу необходимо ждать полной синхронизации либо генерировать ответ на основе не синхронизированных данных. Возможен и третий вариант, когда по каким-либо причинам синхронизация производится только с частью серверов системы. В первом случае оказывается не выполненным требование по доступности, во втором — по согласованности, в третьем — по устойчивости к разделению.

Хранилища XML-документов (BaseX, eXist) представляют собой средства для работы с большим количеством XML-документов или с документами большого размера. Информация содержится не в текстовом виде, а в некотором внутреннем формате, позволяющем быстро выполнять операции поиска (запросы XPath и XQuery) и изменения документов (XSLT, eXtensible Stylesheet Language Transformations). При загрузке документа проводится его синтаксический анализ, результаты которого помещаются в базу, а при извлечении документа его текст восстанавливается на основе содержимого внутренних структур базы.

Формат XML — не единственный способ текстового представления структурированной информации: по аналогии с XML-хранилищами существуют СУБД (Apache Couch DB и MongoDB) для работы с данными, представленными в виде JSON (Java Script Object Notation ) или BSON (Binary JSON).

Системы для работы с часто изменяющимися данными всю информацию содержат только в оперативной памяти и вообще не используют ввода/вывода. Такой подход популярен при реализации механизмов кэширования, но принципиально не подходит при построении основного хранилища, поскольку любая авария питания приведет к потере данных. Наконец, системы с редко изменяющимися данными являются некоторым промежуточным звеном, обеспечивая возможность корректировки базы, достаточно высокую скорость поиска и сохранение информации на диске.

В общем случае системы рассматривают ключ и значение как массив байтов, причем длина ключа может достигать нескольких килобайтов, а значения — нескольких мегабайтов. Однако часто некоторые СУБД предоставляют дополнительные возможности для структурирования ключей и значений. Так, Apache Cassandra позволяет разбивать значения на несколько колонок и работать с каждой из них отдельно, а BigTable, напротив, использует трехкомпонентные ключи (ключ столбца, ключ строки и временная метка), но значения рассматривает как массив байтов. Такое устройство ключа позволяет использовать BigTable как средство работы с двумерными таблицами большого размера. Примерно по такой же схеме работают хранилища кортежей произвольной длины.

Системы хранения графов и Triple Storages ориентированы на работы с семантическими данными, представленными в виде узлов и дуг. Отличительной чертой Triple Storages является то, что они ориентированы на поддержку стандартов SemanticWeb.

Все эти классы систем NoSQL очень разнородны, и пока отсутствует единый стандарт требований к ним, однако такая стандартизация станет необходима по мере создания новых высоконагруженных систем и повышения требований к скорости обработки и стоимости разработки. Наличие единых стандартов облегчит использование нескольких NoSQL СУБД в одном проекте, упростит интеграцию СУБД между собой, ускорит миграцию на новые СУБД, сделает возможным создание универсальных инструментальных средств NoSQL, позволит заранее осуществлять подготовку специалистов по NoSQL и т. д.

В 2011 году был сделан первый шаг в направлении стандартизации — анонсирован язык запросов UnQL (Unstructured Query Language) для работы с неструктурированной информацией. Для удобства прикладных разработчиков синтаксис и семантика языка во многом схожи с SQL, что вполне естественно — благодаря поддержке UnQL каждая NoSQL-СУБД может стать гибким, удобным и легко используемым инструментом, и она по-прежнему будет основываться на собственных технических решениях, дающих преимущество в каких-либо условиях эксплуатации.

Реляционные СУБД не спешат мириться со своими недостатками и поддерживают все новые типы данных, используемые в системах NoSQL. Простейшие примеры такого развития (поддержка типов BLOB и полнотекстового поиска) уже упоминались, а более сложный пример — поддержка XML-документов и XPath-запросов. Эта функциональность ключевая для специализированных СУБД (BaseX, eXist), ориентированных на работу с XML, но она же почти полностью присутствует в некоторых реляционных СУБД (например, в Oracle).

Решение заключается в корректировке самой концепции СУБД, подразумевающей, что такие системы должны представлять собой не монолитный сервер с комплектом инструментальных средств, а набор хорошо интегрируемых блоков, каждый из которых решает конкретную задачу обработки данных (например, кэширование, распределение нагрузки, компрессия данных, передача по сети и т. д.), не является самодостаточным и требует надстройки высокоуровневых модулей. Это позволит максимально учитывать специфику хранимых данных и обрабатываемых запросов.

Все датчики из задачи предыдущей врезки дают показания раз в секунду, поэтому можно сделать следующее. Во-первых, вместо показаний времени использовать номер секунды, прошедшей с начала месяца. Во-вторых, использовать его не как ключ ассоциативного массива, а как индекс одномерного массива показаний датчика за месяц.

Каждый датчик изменяет свое значение плавно, и последовательность его показаний имеет смысл хранить по аналогии с инвертированными индексами в поисковых системах. Так, история показаний разбивается на дни, а для каждого дня хранится начальное показание датчика и последовательность дельт. В итоге за один день будет накапливаться 24 x 60 x 60 = 86 400 чисел, но 86 399 из них окажутся близки к нулю (так как датчик меняет значения плавно) и будут очень хорошо сжиматься. Если сжатие будет 10-кратным, то для хранения показаний одного датчика за один день понадобится 24 x 60 x 60 = 86 400 чисел, что потребует примерно 350 Мбайт без сжатия и 35 Мбайт со сжатием. Соответственно, вся база будет занимать около 10 Гбайт, при этом ее можно разбить на файлы, содержащие показания набора датчиков за некоторый промежуток времени. Это позволяет подобрать оптимальные параметры разбиения базы на файлы и добиться чтения информации в интерактивном режиме.

Для ускорения скорости анализа нужно хранить дополнительную битовую матрицу, строки которой соответствуют датчикам, а столбцы — моментам времени. Элемент матрицы равен 1, если в данный момент времени данный датчик меняет свое значение больше чем на указанную фиксированную пороговую величину. Суммарно вся матрица будет состоять из 2 592 000 x 10 000 ячеек, что потребует 3 Гбайт памяти, но поскольку датчики меняют свое значение плавно и редко, то матрица будет сильно разреженной и при сжатии займет не более 300 Мбайт.

С точки зрения реализации будет рациональным разделить битовые матрицы на блоки (один блок соответствует набору датчиков и некоторому промежутку времени), хранить их в памяти и не производить операции ввода/вывода. Тогда скорость работы данной целевой СУБД будет зависеть только от быстродействия процессора. Поскольку нужные для этого алгоритмы хорошо распараллеливаются, то возможно добиться работы системы в интерактивном режиме.

Вместе с тем данный пример наглядно демонстрирует, что указанную задачу пока неспособны эффективно решить и существующие NoSQL СУБД —эта технология находится еще на этапе становления, и ей еще предстоит проделать долгий путь до того, как стать промышленным стандартом, подходящим для решения широкого круга практических задач. Однако концепция целевых СУБД хотя и покрывает рассмотренное решение, но находится в еще более зачаточном состоянии.

Логическим завершением подхода построения целевых СУБД вместо использования классических серверных архитектур является движение в сторону RAD (Rapid Application Development), при котором программист формально описывает качественные и количественные требования к создаваемой СУБД, получает предварительное решение, а затем оптимизирует его отдельные элементы вплоть до самостоятельной реализации отдельных блоков. Созданная таким образом целевая СУБД может быть впоследствии развернута на любой инфраструктуре, включая и облака.

По принципу создания и применения целевые СУБД чем-то напоминают инструменты ETL для загрузки данных в информационные хранилища. Сейчас эти инструменты не готовы для вызова из программ, но позволяют создать, отладить, оптимизировать и многократно использовать саму процедуру ETL. Примерно по той же схеме работают генераторы запросов, и примерно по той же схеме могут работать СУБД типа SQL+NoSQL.

Автор Анна Вичугова

NoSQL – это подход к реализации масштабируемого хранилища (базы) информации с гибкой моделью данных, отличающийся от классических реляционных СУБД. В нереляционных базах проблемы масштабируемости (scalability) и доступности (availability), важные для Big Data, решаются за счёт атомарности (atomicity) и согласованности данных (consistency) [1].

Зачем нужны нереляционные базы данных в Big Data: история появления и развития

Какие бывают NoSQL-СУБД: основные типы нереляционных баз данных

Все NoSQL решения принято делить на 4 типа:

Чем хороши и плохи нереляционные базы данных: главные достоинства и недостатки

По сравнению с классическими SQL-базами, нереляционные СУБД обладают следующими преимуществами:

Обратной стороной вышеуказанных достоинств являются следующие недостатки:

ограниченная емкость встроенного языка запросов [5]. Например, HBase предоставляет всего 4 функции работы с данными (Put, Get, Scan, Delete), в Cassandra отсутствуют операции Insert и Join, несмотря на наличие SQL-подобного языка запросов. Для решения этой проблемы используются сторонние средства трансляции классических SQL-выражений в исполнительный код для конкретной нереляционной базы. Например, Apache Phoenix для HBase или универсальный Drill.
сложности в поддержке всехACID-требований к транзакциям (атомарность, консистентность, изоляция, долговечность) из-за того, что NoSQL-СУБД вместо CAP-модели (согласованность, доступность, устойчивость к разделению) скорее соответствуют модели BASE (базовая доступность, гибкое состояние и итоговая согласованность) [1]. Впрочем, некоторые нереляционные СУБД пытаются обойти это ограничение с помощью настраиваемых уровней согласованности, о чем мы рассказывали на примере Cassandra. Аналогичным образом Riak позволяет настраивать требуемые характеристики доступности-согласованности даже для отдельных запросов за счет задания количества узлов, необходимых для подтверждения успешного завершения транзакции [1]. Подробнее о CAP-и BASE-моделях мы расскажем в отдельной статье.
сильная привязка приложения к конкретной СУБД из-за специфики внутреннего языка запросов и гибкой модели данных, ориентированной на конкретный случай [5];
недостаток специалистов поNoSQL-базам по сравнению с реляционными аналогами [5].

Введение
База данных (БД) - это набор данных или записей. Система управления базами данных (СУБД) - это программная система, которая использует стандартные методы для хранения, организации данных, манипулирования данными и их управлением. Данные могут быть добавлены, обновлены, удалены или просмотрены с использованием различных стандартных алгоритмов и запросов.
Как уже было сказано ранее, база данных (БД) - это хранилище данных, а совокупность программных систем, которые используется для управления базами данных, называется системой управления базами данных (СУБД).

Типология баз данных.

Базы данных можно классифицировать по разным признакам:

по организации информации (реляционные, объектно-ориентированные)
по способу хранения информации (централизованные, распределенные)
по способу доступа к хранимым данным (настольные, серверные)
по характеру хранимой информации (фактографические, документальные)

Рассмотрим подробнее типологию баз данных по принципу организации информации, другими словами, классификация, основанная на модели данных. Существует несколько типов систем управления базами данных, таких как:

Иерархические базы данных.
В модели иерархической системы управления базами данных (иерархических СУБД) данные хранятся в узле отношения родитель-потомок. Кроме того, помимо фактических данных, записи также содержат информацию об их группах родительских или дочерних отношений.

В иерархической модели базы данных данные организованы в древовидную структуру. Данные хранятся в виде набора полей, где каждое поле содержит только одно значение. Записи связаны друг с другом через ссылки в родительско-дочерних отношениях. В иерархической модели базы данных каждая дочерняя запись имеет только одного родителя. Родитель может иметь несколько детей.

Чтобы получить данные поля, необходимо пройти через каждое дерево, пока не будет найдена запись.

Другой значимый недостаток - при добавлении нового поля или записи требуется переопределение всей базы данных.
К преимуществам иерархических БД относится быстрый доступ и обновление.
Структура иерархической системы баз данных была разработана IBM в начале 1960-х годов. Иерархические базы данных широко используются для создания приложений высокой производительности и доступности, обычно в банковской и телекоммуникационной отраслях. Например, известные базы данных IBM Information Management System (IMS) и реестр Windows относятся к иерархическим БД.

Сетевые базы данных.

Системы управления сетевыми базами данных (сетевые СУБД) используют сетевую структуру для создания отношений между объектами. Сетевые БД в основном используются на больших цифровых компьютерах. Сетевые БД похожи на иерархические базами данных, но в отличие от иерархических баз данных, где один узел может иметь только одного родителя, сетевой узел может иметь связь с несколькими объектами. Сетевая база данных больше похожа на паутину или взаимосвязанную сеть записей.

Структура базы данных сети была изобретена Чарльзом Бахманом. Некоторые из популярных сетевых баз данных: интегрированное хранилище данных (IDS), IDMS (интегрированная система управления базами данных), менеджер баз данных Raima, TurboIMAGE и Univac DMS-1100.
Реляционные базы данных.

Реляционная БД впервые была предложена исследователем из IBM Эдгаром Фрэнком Коддом в 1969 году.

В системах управления реляционными базами данных данные представлены в виде отношений, двумерных таблиц. Хранение данных обусловлено столбцами и строками таблицы. Каждый столбец представляет атрибут. Множество значений столбца определены доменом. Каждая строка в таблице представляет запись, кортеж.

Язык структурированных запросов (SQL) - это язык, используемый для запросов к СУБД, включая вставку, обновление, удаление и поиск записей. Реляционные базы данных работают с каждой таблицей, в которой есть ключевое поле, однозначно указывающее на каждую строку. Эти ключевые поля можно использовать для соединения одной таблицы данных с другой.
Реляционные базы данных являются наиболее популярными и широко используемыми базами данных. Некоторые из популярных DDBMS - это Oracle, SQL Server, MySQL, SQLite и IBM DB2.

Реляционные базы данных легки в освоении.
Записи базы данных могут быть изменены без указания всего тела таблицы.

Реляционные базы данных удовлетворяют следующим свойствам:

Атрибуты являются атомарными
Каждая строка уникальна.
Поля не упорядочены.
Последовательность строк незначительна.
Каждое поле имеет уникальное имя.

Графовые базы данных.

Графовые базы данных являются базами данных NoSQL и используют структуру графов для семантических запросов. Данные хранятся в виде узлов, ребер и свойств. В графической базе данных узел представляет собой объект или экземпляр, такой как клиент, человек или автомобиль. Узел эквивалентен записи в системе реляционной базы данных. Ребро в базе данных графа представляет отношение, которое соединяет узлы, то есть определяет связи между узлами. Свойства – атрибуты, которые представляются в виде пары ключ-значение, и предназначены для хранения дополнительной информации, которая может быть ассоциирована как с узлами, так и со связями.
Язык запросов, СУБД для графовых баз, оптимизация производительности нацелены на оптимальный, в терминах скорости, способ обхода узлов по связям. Например, поиск в ширину, нахождение подграфов.

К самым популярным графовым базам данных относятся Neo4j, DEX, Azure Cosmos DB, SAP HANA. Структура базы данных графов также поддерживается некоторыми реляционными СУБД, включая Oracle и SQL Server 2017 и более поздние версии.

Базы данных NoSQL.

Базы данных NoSQL - это базы данных, которые не используют SQL в качестве основного языка доступа к данным. Графические, сетевые, объектно-ориентированные БД и базы данных документов относятся к NoSQL БД.

База данных NoSQL не имеет предопределенных схем, что делает базы данных NoSQL подходящими для быстро меняющихся сред разработки. NoSQL позволяет разработчикам вносить изменения на лету, не затрагивая приложения.

К популярным NoSQL базам данных относятся Космос БД, ArangoDB, CouchDB, Amazon DocumentDB, MongoDB, SAP HANA.

Сущности представляются как объекты
Объекты имеют свойства (атрибуты) и методы
Объекты хранятся в памяти
Механизмы наследования и полиморфизма

Жизненный цикл каждого объекта включает в себя создание объекта, использование объекта и удаление объекта. При создании каждому объекту присваивается генерируемый системой уникальный идентификатор, связанный с эти объектом на протяжении всего его жизненного цикла, в том числе и при изменении состояния объекта.

В ООБД данные можно представить в виде любой структуры, которую можно описать с помощью выбранного для разработки языка программирования. Также можно создавать произвольное сложные отношения между объектами.

Сущности представляются как объекты, которые хранятся в оперативной памяти. ООБД управляет кэш-буфером объектов, перемещая объекты между буфером и дисковым хранилищем по мере необходимости. Дополнительный интерфейсный уровень абстракции обеспечивает перехват запросов, обращающихся к тем частям базы данных, которые находятся в постоянном хранилище на диске. Изменения, вносимые в объекты, оптимальным образом переносятся из памяти на диск. [4]

Любой объект описывается состоянием и поведением. Состояние объекта – набор значений его свойств (атрибутов). Значение атрибута объекта также может являться объектом. Тогда как поведение объектов задается его методами, реализованными в программах.
Атрибуты объекта могут быть заданы элементарными значениями (числовой и строковый типы) или неэлементарными объектами, которые в свою очередь также состоят из набора свойств. То есть одни объекты могут быть рекурсивно определены через другие объекты.
Объекты, имеющие один набор атрибутов, объединяются в классы. Каждый объект может принадлежать только одному классу (не учитывая механизм наследования).
Объектные базы данных обычно используются в приложениях, которые требуют высокой производительности, сложных расчетов и быстрых результатов, а также для описания модели данных со сложной структурой. К приложениям, которые используют объектные базы данных, относятся системы реального времени, архитектура и инженерия для трехмерного моделирования, телекоммуникации и научные продукты, молекулярная наука и астрономия.
Преимущества объектно-ориентированных баз данных

Преимущества объектно-ориентированных баз данных (ООБД) неоспоримы.

Во-первых, существует возможность повторного использования объектов. СУБД обеспечивают постоянное хранение объектов. После создания объектов в программе и сохранения их в базе данных, объекты могут считываться из базы данных.

Во-вторых, объектно-ориентированные базы данных описывают сложные объекты логически более понятно по сравнению с реляционными БД.
Еще одним важным преимуществом объектно-ориентированных БД является возможность приложениям интерпретировать данные в контексте того языка программирования, на котором они написаны. Следовательно код для разработки приложений упрощается. Например, в реляционных БД значения всех полей возвращаются в тестовом формате, и после приводятся к необходимым локальным типам данных. Тогда как в ООБД данный этап опускается. Другими словами, пропадает необходимость приводить данные к типам поддерживаемых в СУБД и обратно.

В реляционных СУБД (РСУБД) размерность значений типа целых чисел составляет 11 цифр, а в используемом для разработки языке – 15. Разработчикам необходимо отслеживать подобные ситуации в РСУБД.

Недостатки объектно-ориентированных баз данных.

Не существует математического аппарата, на который могла бы опираться объектная модель. Следовательно объектные базы данных не имеют стандарта, общей базовой модели
Объектно-ориентированные СУБД не так популярны, как, например реляционные СУБД. Сложно найти разработчиков объектно-ориентированных БД. Следовательно разработка ООСУБД требует больших затрат.
Не многие языки программирования поддерживают объектные базы данных.
Большинство СУБД используют SQL в качестве стандартного языка запросов.
Объектные базы данных трудны в освоении для обычных пользователей, которые не знакомы с объектно-ориентированным подходом

Объектно-ориентированные системы управления базами данных.
Ниже представлены популярные объектно-ориентированные баз данных и их возможности.

InterSystems Caché

InterSystems Caché - это высокопроизводительная объектная база данных. Ядро базы данных Caché - это набор сервисов, включающий хранение данных, управление параллелизмом, транзакции и управление процессами.

Caché также является полнофункциональной реляционной базой данных. Все данные в базе данных Caché доступны в виде настоящих реляционных таблиц и могут быть запрошены и изменены с использованием стандартного SQL через ODBC, JDBC или объектные методы. Caché - одна из самых быстрых, надежных и масштабируемых реляционных баз данных.

Caché предоставляет следующие возможности и функции:

ConceptBase.

ConceptBase.cc - это многопользовательская система баз данных с объектно-ориентированным подходом, который делает ее мощным инструментом для метамоделирования и разработки пользовательских языков моделирования. Система сопровождается настраиваемым графическим интерфейсом пользователя, который основан на логических возможностях сервера ConceptBase.cc.

ConceptBase.cc разработан командой ConceptBase из Университета Скёвде (HIS) и Университета Аахена (RWTH). ConceptBase.cc доступен для Linux, Windows и Mac OS-X. Существует также предварительно настроенное виртуальное устройство, которое содержит исполняемую систему, а также ее источники и инструменты для их компиляции. Система распространяется под лицензией в стиле FreeBSD.

ObjectDB Object Database.

ObjectDB - это мощная объектно-ориентированная система управления базами данных (ODBMS). ObjectDB предоставляет все стандартные сервисы управления базами данных (хранение и извлечение, транзакции, управление блокировками, обработка запросов). Но таким образом, чтобы упростить разработку и ускорить работу приложений.

(текст реферата разделен на две части, так как в данном сервисе возможно проверять процент оригинальности текста, состоящего менее чем из 10000 символов)

Читайте также: