Что такое СУБД
Система управления базами данных (СУБД) – это комплекс программно-языковых средств, позволяющих создать базы данных и управлять данными. Иными словами, СУБД — это набор программ, позволяющий организовывать, контролировать и администрировать базы данных. Большинство сайтов не могут функционировать без базы данных, поэтому СУБД используется практически повсеместно.
- Подробнее о СУБД
- SQL и реляционные БД: почему в них важно разбираться
- Наиболее популярные СУБД
Подробнее о СУБД
Основные функции СУБД:
- управление данными во внешней памяти (на дисках);
- управление данными в оперативной памяти с использованием дискового кэша;
- журнализация изменений (сохранение истории), резервное копирование и восстановление базы данных после сбоев;
- поддержка языков БД (язык определения данных, язык манипулирования данными).
Каждая СУБД основывается на какой-либо модели данных, это является одним из признаков классификации. По модели данных СУБД бывают:
- Иерархические. В этой модели данных используется представление БД в виде древовидной структуры, состоящей из данных разных уровней.
- Сетевые. Данная модель является расширением иерархического подхода. Иерархическая модель подразумевает, что запись-потомок может иметь строго одного предка, в то время как в сетевой структуре потомок может иметь любое количество предков.
- Реляционные. СУБД, ориентированные на организацию данных как набор связанных записей и атрибутов в двумерной таблице.
- Объектно-ориентированные. Для управления БД, основанными на объектной модели данных. Как правило основываются на объектно-ориентированных языках программирования.
- Объектно-реляционные. Объединяет в себе концепции реляционной модели с дополнительными объектно-ориентированными возможностями.
SQL и реляционные БД: почему в них важно разбираться
Сегодня по-прежнему наиболее популярными при создании веб-приложений и сервисов остаются реляционные базы данных. Для управления реляционными базами данных используется язык SQL (Structured Query Language — структурированный язык запросов). Изначально SQL был инструментом работы пользователя с базой данных, однако со временем язык усложнился и стал скорее инструментом разработчика, чем конечного пользователя.
Наиболее популярные СУБД
Различные рейтинги самых популярных СУБД возглавляют Oracle, MySQL , Microsoft SQL Server, PostgreSQL.
MySQL
Считается одной из самых распространенных СУБД. MySQL — реляционная СУБД с открытым исходным кодом, главными плюсами которой являются ее скорость и гибкость, которая обеспечена поддержкой большого количества различных типов таблиц.
Кроме того, это надежная бесплатная система с простым интерфейсом и возможностью синхронизации с другими базами данных. В совокупности эти факторы позволяют использовать MySQL как крупным корпорациям, так и небольшим компаниям.
Microsoft SQL Server
Как следует из названия, фирменная СУБД, разработанная Microsoft. Оптимальная для использования в операционных системах семейства Windows, однако может работать и с Linux.
Система позволяет синхронизироваться с другими программными продуктами компании Microsoft, а также обеспечивает надежную защиту данных и простой интерфейс, однако отличается высокой стоимостью лицензии и повышенным потреблением ресурсов.
В целом, однако, сохраняет свою популярность, в немалой степени из-за того, что продукты корпорации Microsoft используются многими компаниями.
PostgreSQL
СУБД PostgreSQL — еще одна популярная и бесплатная система. Наибольшее применение нашла для управления БД веб-сайтов и различных сервисов. Она универсальна, то есть подойдет для работы с большинством популярных платформ.
При этом PostgreSQL — объектно-реляционная СУБД, что дает ей некоторые преимущества над другими бесплатными СУБД, в большинстве являющимися реляционными.
Oracle
Первая версия этой объектно-реляционной СУБД появилась в конце 70-х, и с тех пор зарекомендовала себя как надежная, функциональная и практичная. СУБД Oracle постоянно развивается и дорабатывается, упрощая установку и первоначальную настройку и расширяя функционал.
Однако существенным минусом данной СУБД является высокая стоимость лицензии, поэтому она используется в основном крупными компаниями и корпорациями, работающими с огромными объемами данных.
Виды баз данных
В этой статье мы рассмотрим основные виды баз данных. На конкретных примерах выявим преимущества и недостатки каждой модели, изучим сценарии их применения.
В этой статье мы рассмотрим основные виды баз данных. На конкретных примерах выявим преимущества и недостатки каждой модели, изучим сценарии их применения.
Что такое база данных
База данных — это набор сведений об объектах, структурированный определенным образом. Обычно базы данных управляются специальным ПО, или системами управления базами данных (СУБД).
В зависимости от вида логическая структура базы данных может иметь различное описание. Это различие влияет на то, какая именно БД используется в разработке конкретного продукта или технологии.
Простейшие типы баз данных
К таким базам данных относятся БД, где хранятся данные с простой структурой: например, список разрешенных IP-адресов для доступа к сети, настройки окружения проекта, список подписчиков на рассылку компании и прочее. Они все еще широко распространены.
Текстовые файлы
Информация об объектах собирается в простых по структуре файлах различных форматов – txt, csv и др. Для разделения полей применяются пробелы, табуляция, запятые, точка с запятой и двоеточие.
Примеры: etc/passwd и etc/fstab в Unix-подобных системах, csv-файлы, ini-файлы и др.
Особенности:
- Просто использовать. Для работы с файлами достаточно примитивного текстового редактора.
- Удобно работать с конфигурационными данными приложений (учетные данные, настройки подключения к удаленным серверам и устройствам, порты и пр.).
Ограничения:
- Сложно установить связи между компонентами данных.
- Не для всех типов информации.
Иерархические базы данных
В отличие от текстовых файлов здесь между хранимыми объектами устанавливаются связи. Объекты делятся на родителей (основные классы или категории объектов) и потомков (экземпляры этих классов или категорий). При этом у каждого потомка может быть не более одного родителя.
Графическим представлением такой базы данных является древовидная структура.
Примеры: Организация файловых систем; DNS и LDAP-соединения.
Особенности:
- Отношения между объектами реализованы в виде физических указателей. Например, в файловой системе путь к папке или файлу строится из имен корневых и вложенных каталогов;
- Моделирование отношений вложенности и подчиненности.
Ограничения: Технология иерархической организации не предполагает связи «многие-ко-многим», а значит, система хранения данных довольно ограничена.
Сетевые базы данных
Эта технология развивает иерархический подход за счет моделирования сложных отношений между объектами. Здесь потомки могут иметь более одного родителя, однако ограничения иерархического подхода сохраняются.
Пример: IDMS — специализированная СУБД для мейнфреймов.
Реляционные базы данных
Данный тип БД является старейшим: теоретические основы подхода заложены британским ученым Эдгаром Коддом в 1970 году. Здесь данные формируются в таблицы из строк и столбцов. В строках приводятся сведения об объектах (значения свойств), а в столбцах — сами свойства объектов (поля).
Нормализация
Сложные взаимоотношения объектов в реляционных БД моделируются с помощью внешних ключей – ссылок на другие таблицы. Это позволяет подходить к вопросу проектирования базы данных с позиций нормализации – минимизации избыточности при описании свойств объектов.
Например, если речь идет о меню ресторана, то у каждого блюда есть вес, цена, наименование, калорийность и категория, к которой оно относится — горячие закуски, холодные закуски, первые блюда, десерты, салаты и так далее. Связь между блюдами и категорией выполняется посредством ссылочного поля индекса категории в таблице блюд.
Такой подход позволяет:
- Минимизировать объем базы данных: не нужно каждому блюду прописывать название категории.
- Повысить целостность системы: в указанном примере все блюда привязаны к категориям меню. Добавление блюда без категории невозможно, равно как и указание в качестве ссылки индекса несуществующей категории.
- Упростить масштабирование: новые блюда могут быть добавлены в существующие категории. Также не исключается добавление новых категорий, привязка новых блюд к ним и перераспределение блюд по категориям.
- Повысить отказоустойчивость: за счет оптимальной организации схемы таблиц запросы на выборку и агрегацию будут работать с меньшим объемом данных, а значит, быстрее, чем без нормализации. При увеличении числа записей в таблицах со временем это позволит поддерживать положительный пользовательский опыт.
Наглядный пример моделирования сложных взаимоотношений в реляционных БД приведен на рисунке выше. Здесь мы видим модель базы данных учебного заведения, где есть следующие объекты: ученик, курс, преподаватель, отдел, направление обучения.
Связь преподавателя с отделом организована через секцию и курс (внешние ключи id курса и id преподавателя в таблице Секция, а также Отдел в таблице Курс). Связь ученика с направлением обучения реализована через таблицу Направление обучения студента (внешние ключи id студента и id направления обучения).
Таким образом, чтобы посчитать, например, количество студентов на курсе и детализировать статистику по преподавателям, необходимо написать запрос с присоединением учеников к направлению, курсу и преподавателям, сделав соответствующую группировку по преподавателям.
Язык запросов SQL
Запросы в реляционных базах данных формируют с помощью структурированного языка SQL. Его предложения позволяют:
- делать выборки,
- проводить агрегации и группировки,
- изменять и удалять данные,
- модифицировать структуру БД (создавать таблицы, поля),
- управлять доступом пользователей к тем или иным операциям и пр.
Денормализация
Помимо нормализации, в реляционных БД существует и обратный процесс — денормализация. Он направлен на перенос наиболее часто используемых полей из внешних таблиц во внутренние. Рассмотрим это на примере мессенджера.
Пользователь (user) оставляет сообщения (messages) в чатах (chat). Структура данных такова, что сообщения связаны с пользователем и чатом через внешние ключи (user_from и user_to, а также chat_id в таблице сообщений; user_id и chat_id в таблице user_chat_link). Поскольку схема нормализована, то различные запросы на выборку, подсчет и агрегацию статистики по чатам, пользователям и сообщениям необходимо выполнять с помощью присоединения внешних таблиц.
На относительно небольших объемах данных эти запросы будут отрабатывать быстро, а с увеличением размера базы – замедляться. Причина кроется в механизме присоединения. Он основан на построчном сравнении двух и более таблиц по условию соединения — например, равенство chat_id в messages и id в chat. А это дает нагрузку на сервер базы данных, которая с ростом ее размера только увеличивается. Для оптимизации такого рода запросов и существует механизм денормализации.
В таблицу связи пользователя и чата user_chat_link добавлены дублирующие поля имени чата (chat_name) и аватара (chat_logo). Также туда выводятся последнее сообщение (last_msg) и количество непрочитанных сообщений (unread_msg_count).
Теперь для получения указанных выше полей и проведения аналитики по ним можно использовать таблицу user_chat_link без необходимости соединения с таблицей сообщений. Тем не менее, такой подход имеет ограничения.
За счет дополнительных полей оптимизируются запросы на чтение и агрегацию данных, однако ценой этого является вынужденная избыточность и усложнение бизнес-логики приложения. В частности, усложняется написание запросов изменения данных (update и delete), а также модификации структуры базы (create).
Использование денормализации должно быть тщательно осмыслено. Нужно быть уверенным в том, что нормализованная структура, оптимизированные запросы и правильно настроенные индексы более не способны удовлетворять критерию быстродействия.
Преимущества реляционного подхода:
- определение сложных отношений между объектами,
- нормализация и денормализация данных,
- структурированный язык запросов,
- богатая история развития и широкое распространение (основной инструмент при разработке различных приложений и сервисов).
Недостатки подхода: жесткая структура сведений об объектах.
Примеры: MySQL, MariaDB, PostgreSQL, SQLite и др.
NoSQL и нереляционные базы данных
Все преимущества и недостатки реляционных БД основаны на жесткой структуризации и типизации сведений об объектах. С одной стороны, можно оптимизировать хранение и индексирование данных за счет нормализации или же денормализации. С другой — сложно организовать хранение и обработку плохо структурированных (например, объекты кэша) или вовсе не структурированных данных (например, данные из нескольких источников).
Для борьбы с этими ограничениями было разработано семейство нереляционных БД. Рассмотрим их подробнее.
Базы данных «Ключ-значение»
Это простейшая разновидность нереляционных БД. Данные хранятся в виде словаря, где указателем выступает ключ.
Особенности:
- Хранение и обработка разных по типу и содержанию данных: в одном хранилище под разными ключами могут находиться файлы, строки, текст, числа, JSON-объекты и другие типы данных.
- Высокая скорость доступа к данным за счет адресного хранения.
- Легкое масштабирование. Можно создать правила шардирования по определенным ключам – например, сессии пользователей разных сайтов хранятся в различных сегментах БД.
Ограничения: Поскольку подход не предполагает жесткой типизации и структуризации данных, то контроль их валидности, а также нейминг ключей отдаются на откуп разработчику.
Примеры: Amazon, DynamoDB, Redis, Riak, LevelDB, различные хранилища кэша – например, Memcached и пр.
Документоориентированные БД
В отличие от баз типа «Ключ-значение» данные здесь хранятся в структурированных форматах – XML, JSON, BSON. Тем не менее, сохраняется адресный доступ к данным по ключу. При этом содержимое документа может иметь различный набор свойств.
Например, каталог профилей пользователей: один в качестве предпочтений указал любимое блюдо, а другой – видеоигру. Поскольку эти сведения нельзя хранить в одном поле ввиду логической и структурной разобщенности, они записываются в отдельные свойства отдельных документов. При необходимости можно добавить в документы новые свойства, не нарушив при этом общей целостности данных.
Особенности:
- хорошо подходят для быстрой разработки систем и сервисов, работающих с по-разному структурированными данными,
- легко масштабируются и меняют структуру при необходимости.
Примеры: MongoDB, RethinkDB, CouchDB, DocumentDB.
Графовые базы данных
Это семейство баз предназначено для моделирования сложных отношений с помощью теории графов, где связями выступают ребра графа, а сами объекты – это узлы или вершины.
Такой подход может пригодиться при анализе профилей пользователей социальных сетей. Один пользователь подписан на обновления второго, другой пользователь подписан на определенное сообщество и так далее. Также технология может использоваться при анализе экономической активности контрагентов для выявления различных схем мошенничества. Например, можно отследить использование определенных счетов, карт или реквизитов контрагентов в различных операциях.
Особенности: высокая производительность, поскольку обход ребер и вершин значительно быстрее анализа множества внешних и внутренних таблиц и их соединения по условию отбора в реляционных БД.
Примеры: Neo4J, JanusGraph, Dgraph, OrientDB.
Колоночные базы данных
Как можно понять из названия, записи в таких базах хранятся не по строкам, а по столбцам (колонкам). Вместо таблиц здесь используются колоночные семейства. Они содержат ключи, указывающие на формат строки записи информации об объекте. Каждая строка имеет свой набор свойств, что позволяет хранить в рамках одного семейства разно структурированные данные.
Технология активно используется при построении аналитических систем и сервисов, работающих с большими объемами данных.
На рисунке приведен пример колоночного хранения информации о фруктах. Известно три типа фруктов: яблоки, виноград, бананы. Все они объединены в семейство фруктов.
У каждого фрукта индивидуальный набор свойств. Для яблок это цвет, цена и наличие. У винограда это цвет, цена, число ягод в связке и происхождение (импортный или нет). У бананов же это цвет, цена, число в связке и зрелость.
Чтобы получить детальную сводку по одному типу фруктов, достаточно в запросе указать его идентификатор. При этом можно построить аналитический запрос по общим для всего семейства признакам – например, посчитать число фруктов с группировкой по цвету, вычислить среднюю цену на все фрукты в магазине и т.д.
Особенности:
- С группировкой свойств по колонкам при запросе индексируется меньший объем данных, что обеспечивает высокую скорость его выполнения.
- Широкие возможности масштабирования и модификации структуры — так, при добавлении новых колонок не придется их жестко формализовывать, как в случае с реляционными базами.
Примеры: Cassandra, HBase, ClickHouse.
Базы данных временных рядов
Данный тип БД можно использовать при необходимости отслеживания исторической динамики по ряду показателей. Здесь данные группируются по временным меткам. Базы временных рядом чаще ориентированы на запись, чем на построение сложных аналитических запросов.
На рисунке выше приведен пример использования такой БД для отслеживания состояния ПК во времени по ряду показателей – температуре процессора, загрузке системы и потреблению оперативной памяти.
Особенности: Можно обрабатывать постоянный поток входных данных.
Ограничения: Производительность зависит от объема поступающей информации, количества отслеживаемых метрик, а также временного лага между записью новых данных и запросами на чтение
Примеры БД: OpenTSDB, Prometheus, InfluxDB, TimescaleDB
Комбинированные базы
Эта разновидность баз совмещает в себе SQL- и NoSQL-подходы к организации хранения и обработки данных. Этот класс баз включает в себя NewSQL и многомодельные решения. Рассмотрим их подробнее.
Базы данных NewSQL
Данный тип решений для хранения информации стремится обеспечить компромисс между масштабируемостью и согласованностью при сохранении реляционного подхода.
Термин предложил в 2011 году аналитик компании 451 Group Мэтью Аслет. Он отмечал высокую потребность в таких системах для сфер, работающих с критическими данными, — здравоохранение, FinTech и пр. Характерными признаками этих решений являются: использование алгоритмов обеспечения консенсуса (алгоритм Paxos, Raft и др.), шардирование и заточка под горизонтальное масштабирование.
Особенности:
- широкие возможности масштабирования,
- высокая производительность и доступность данных.
Ограничения: Высокие требования к аппаратным ресурсам разработчиков. Но если разрабатываемый продукт является высоконагруженной системой, то применение такой БД имеет смысл.
Примеры баз такого типа: MemSQL, VoltDB, Spanner и др.
Многомодельные базы
Такие БД сочетают в себе несколько подходов к организации данных одновременно. Это обеспечивает функциональное разнообразие при разработке систем с их использованием.
Особенности:
- возможность в одном запросе работать с данными, хранящимися в разных типах баз, не нарушая при этом согласованности;
- обширные возможности масштабирования за счет легкой интеграции новых моделей баз данных в существующую инфраструктуру проекта.
Пример решения данного типа: ArangoDB.
Базы данных в Selectel
В Selectel вы можете запустить готовые облачные базы данных — поддерживаем такие СУБД, как PostgreSQL (в том числе для 1С:Предприятие), MySQL, Redis, TimescaleDB.
Облачные базы данных позволяют исключить работу с инфраструктурой: поднять нужное количество нод можно за несколько минут в панели управления компании. Решение отказоустойчивое и легко масштабируется. На экстренный случай создаются резервные копии для отката состояния базы на срок до семи дней.
Большинство рутинных операций по системному администрированию (настройка, конфигурация, обслуживание и обеспечение безопасности) выполняются специалистами Selectel.
Запустите свою базу данных в облаке
Быстрое развертывание самых популярных реляционных и NoSQl-баз данных.
Заключение
В данной статье мы рассмотрели 11 видов баз данных. Каждый имеет свои особенности и ограничения. Решение о выборе того или иного вида необходимо принимать с учетом:
- сложности хранимых данных и взаимосвязей между ними,
- производительности операций чтения/записи и модификации структуры БД на планируемом объеме данных,
- опыта команды разработки,
- стадии жизненного цикла разрабатываемого продукта (производите ли вы доработку действующего решения либо создаете что-то принципиально новое, каковы ваши текущие и перспективные ресурсные возможности).
Автор: Роман Андреев.
Виды баз данных. Большой обзор типов СУБД
Часто, в обзорах видов баз данных упоминают реляционные и “другие”, “NoSQL” и т.д., либо приводят самые основные типы СУБД (базы данных), забывая о редких. В данной статье я постараюсь описать максимально полно виды баз данных и привести примеры конкретных реализаций. Разумеется, статья не претендует на всеохватность и классифицировать базы данных можно по разному, в том числе по типам оптимальной нагрузки и т.д., и все виды баз данных будут рассмотрены очень кратко. Но надеюсь, статья даст базовое представление о видах СУБД и принципах их работы.
В статье мы рассмотрим следующие типы баз данных:
- Реляционные
- Ключ-значение
- Документо-ориентированные
- Базы данных временных рядов
- Графовые базы данных
- Поисковые базы данных (Search Engines)
- Объектно-ориентированные базы данных
- RDF (Resource Description Framework)
- Wide Column Stores
- Мультимодальные СУБД
- Native XML СУБД
- GEO/GIS (пространственные) и специализированные СУБД
- Event СУБД (баз данных переходов состояний)
- Контентные СУБД
- Навигационные (Navigational) СУБД
- Векторные базы данных
Начнем с самого распространенного типа — реляционных СУБД.
Реляционные базы данных
Наиболее известными реляционными базами данных являются Open Source проекты PostgreSQL, MySQL и SQLite, а также проприетарные решения Oracle, Microsoft SQL Server и IBM Db2Relational.
Суть реляционных баз в хранении данных в связанных таблицах.
Стоит заметить, что реляционные базы бывают с хранением данных по строкам (PostgreSQL) и по столбцам/колонкам (ClickHouse, Vertica). Колоночные/столбцовые базы лучше подходят для аналитики, в то время как ориентация на строки лучше подходит для транзакционных нагрузок.
Реляционные СУБД — самый распространенный тип баз данных. В подкате таблица из более чем 150 вариантов. Источником данного списка является данный сайт-агрегатор информации по базам данных.
Список реляционных баз данных (и инструментов, содержащих функционал, присущий базам данных, таких как SQL-движки и т.д.) и поддерживаемый тип данных.
Полный список из 166 реляционных СУБД
- Oracle — реляционная, мультимодальная
- MySQL — реляционная, мультимодальная
- Microsoft SQL Server -реляционная, мультимодальная
- PostgreSQL — реляционная, мультимодальная
- IBM Db2Relational — мультимодальная
- Microsoft Access — реляционная
- SQLite — реляционная
- Snowflake — реляционная
- MariaDB — реляционная, мультимодальная
- Microsoft Azure SQL Database — реляционная, мультимодальная
- Hive — реляционная
- Databricks — мультимодальная
- Teradata — реляционная, мультимодальная
- Google BigQuery — реляционная
- FileMaker — реляционная
- SAP HANA — реляционная, мультимодальная
- SAP Adaptive Server — реляционная
- Microsoft Azure Synapse Analytics — реляционная
- Firebird — реляционная
- Informix — реляционная, мультимодальная
- Amazon Redshift — реляционная
- Impala — реляционная, мультимодальная
- Spark SQL — реляционная
- ClickHouse — реляционная, мультимодальная
- Netezza — реляционная
- Vertica — реляционная
- Presto — реляционная
- dBASE — реляционная
- Apache Flink — реляционная
- Greenplum — реляционная, мультимодальная
- Amazon Aurora — реляционная, мультимодальная
- H2 — реляционная, мультимодальная
- Oracle Essbase — реляционная
- Microsoft Azure Data Explorer — реляционная, мультимодальная
- Microsoft Azure Data Explorer — реляционная, мультимодальная
- CockroachDB — реляционная
- Derby — реляционная
- Interbase — реляционная
- Trino — реляционная, мультимодальная
- SingleStore — реляционная, мультимодальная
- SAP SQL Anywhere — реляционная
- Ingres — реляционная
- HyperSQL — реляционная
- Ignite — мультимодальная
- SAP IQ — реляционная
- Virtuoso — мультимодальная
- OpenEdge — реляционная
- Oracle NoSQL — мультимодальная
- Google Cloud Spanner — реляционная
- YugabyteDB — реляционная, мультимодальная
- MaxDB — реляционная
- TiDB — реляционная, мультимодальная
- Apache Druid — мультимодальная
- InterSystems Caché — мультимодальная
- InterSystems IRIS — мультимодальная
- DuckDB — реляционная
- SAP Advantage Database Server — реляционная
- HEAVY.AI — реляционная, мультимодальная
- 4D — реляционная
- Percona Server for MySQL — реляционная
- EDB Postgres — реляционная
- Apache Drill — мультимодальная
- EXASOL — реляционная
- Apache Phoenix — реляционная
- Citus — реляционная, мультимодальная
- Datomic — реляционная
- Empress — реляционная
- GridGain — мультимодальная
- OceanBase — реляционная, мультимодальная
- MonetDB — реляционная, мультимодальная
- VoltDB — реляционная
- Tibero — реляционная
- TimesTen — реляционная
- IBM Db2 warehouse — реляционная
- SQLBase — реляционная
- Firebolt — реляционная
- Fauna — мультимодальная
- mSQL — реляционная
- MatrixOne — реляционная
- DataEase — реляционная
- Oracle Rdb — реляционная
- Altibase — реляционная
- PlanetScale — реляционная, мультимодальная
- NonStop SQL — реляционная
- Cubrid — реляционная
- Infobright — реляционная
- Apache Kylin — реляционная
- GBase — реляционная
- Apache HAWQ — реляционная
- NuoDB — реляционная
- Dolt — реляционная, мультимодальная
- solidDB — реляционная
- FoundationDB — мультимодальная
- 1010data — реляционная
- openGauss — реляционная, мультимодальная
- HFSQL — реляционная
- Actian Vector — реляционная
- SQL.JS — реляционная
- OpenBase — реляционная
- Vitess — реляционная, мультимодальная
- Kognitio — реляционная
- StarRocks — реляционная
- TDSQL for MySQL — реляционная, мультимодальная
- DBISAM — реляционная
- FrontBase — реляционная
- TypeDB — мультимодальная
- NexusDB — реляционная
- Datacom/DB — реляционная
- Kinetica — реляционная, мультимодальная
- eXtremeDB — мультимодальная
- ScaleArc — реляционная
- VistaDB — реляционная
- Yellowbrick — реляционная
- Splice Machine — реляционная
- Postgres-XL — реляционная, мультимодальная
- Alibaba Cloud MaxCompute — реляционная
- AlaSQL — мультимодальная
- Apache Pinot — реляционная
- Alibaba Cloud AnalyticDB for MySQL — реляционная, мультимодальная
- SQream DB — реляционная
- Sequoiadb — мультимодальная
- Kingbase — реляционная, мультимодальная
- Trafodion — реляционная
- R:BASE — реляционная
- Apache Doris — реляционная
- Transbase — реляционная
- Lovefield — реляционная
- Raima Database Manager — мультимодальная
- Alibaba Cloud AnalyticDB for PostgreSQL — реляционная
- Tajo — реляционная
- Mimer SQL — реляционная
- Kyligence Enterprise — реляционная
- YDB — мультимодальная
- Databend — реляционная
- Actian PSQL — реляционная
- Alibaba Cloud ApsaraDB for PolarDB — реляционная
- Brytlyt — реляционная
- XtremeData — реляционная
- TransLattice — реляционная
- ElevateDB — реляционная
- Comdb2 — реляционная
- Linter — реляционная, мультимодальная
- AntDB — реляционная
- FeatureBase — реляционная
- LeanXcale — Multi-model
- PipelineDB — реляционная
- GeoSpock — реляционная, мультимодальная
- Faircom DB — мультимодальная
- Tibco ComputeDB — реляционная
- Valentina Server — реляционная
- PieCloudDB — реляционная
- BigObject — реляционная
- Edge Intelligence — реляционная
- Fujitsu Enterprise Postgres — реляционная, мультимодальна
- EsgynDB — реляционная
- Transwarp KunDB — реляционная
- JethroData — реляционная
- MyScale — мультимодальная
- OushuDB — реляционная
- AgensGraph — мультимодальная
- SmallSQL — реляционная
- ActorDB — реляционная
- DaggerDB — реляционная
- EdgelessDB — реляционная
- K-DB — реляционная
- Sadas Engine — реляционная
Из отечественных игроков можно выделить
- Postgres Pro — доработанный под корпоративные задачи PostgreSQL.
- Jatoba — как и вариант выше, основана на PostgreSQL.
- Квант-Гибрид — еще один вариант PostgreSQL.
- Ред — СУБД на базе Interbase/Firebird
- ProximaBD — на основе PostgreSQL.
- Arenadata DB — корпоративное решение на основе Greenplum
- YDB — serverless решение от Яндекса. Это Open Source продукт, который доступен в том числе как для on-premise инсталляций, так и как управляемый сервис с dedicated/serverless моделью потребления.
Вы можете развернуть реляционные базы данных PostgreSQL и MySQL в облаке Amvera Cloud c помощью простого push в выделенный Git-репозиторий. Для этого нужно выполнить несколько простых шагов, описанных в инструкциях для PostgreSQL и MySQL соответственно. Стоимость хостинга баз данных начинается от 170 руб. в месяц.
Реляционные базы закрывают широкий спектр задач, начиная от транзакционных баз и заканчивая аналитическими, но не являются “серебряной пулей” для всех задач. Рассмотрим другие виды базы данных.
Key-value (ключ значение) базы данных
Тип баз данных Key-value предназначен для осуществления быстрых, почти мгновенных запросов для таких задач как кэш, отображение баланса и т.д.. Высокая скорость осуществляется за счет хранения данных по принципу ключ-значение, и в большинстве случаев благодаря работе в оперативной памяти.
Словари содержат коллекцию объектов или записей, а объекты содержат множество различных полей, каждое из которых содержит данные. Записи хранятся и извлекаются с использованием ключа, который однозначно идентифицирует запись и используется для быстрого поиска данных.
Основным применением является ускорение отображения данных для конечных пользователей и снижение нагрузок, в том числе I/O на инфраструктуру организаций.
Наиболее известными и широко используемыми Key-Value решениями являются Redis и Memcached.
Полный список из 72 Key-Value СУБД под катом
- Redis — Key-value, мультимодальная
- Amazon DynamoDB — мультимодальная
- Microsoft Azure Cosmos DB — мультимодальная
- Memcached — Key-value
- etcd — Key-value
- Hazelcast — Key-value, мультимодальная
- Aerospike — мультимодальная
- Ehcache — Key-value
- Riak KV — Key-value
- Ignite — мультимодальная
- OrientDB — мультимодальная
- Google Cloud Bigtable — мультимодальная
- GemFire — Key-value, мультимодальная
- ArangoDB — мультимодальная
- Infinispan — Key-value
- Oracle NoSQL — мультимодальная
- RocksDB Key-value
- Oracle Berkeley DB — мультимодальная
- InterSystems Caché — мультимодальная
- InterSystems IRIS — мультимодальная
- LevelDB — Key-value
- LMDB — Key-value
- Geode — Key-value
- Amazon SimpleDB — Key-value
- Geode — Key-value
- Amazon SimpleDB — Key-value
- Oracle Coherence — Key-value
- GridGain — мультимодальная
- Tarantool — Key-value, мультимодальная
- GT.M — Key-value
- ZODB — Key-value
- FoudationDB — мультимодальная
- NCache — Key-value
- WebSphere eXtreme Scale — Key-value
- Hibari — Key-value
- MapDB — Key-value
- BoltDB — Key-value
- Graph Engine — мультимодальная
- Scalaris — Key-value
- KeyDB — Key-value
- Project Voldemort — Key-value
- Upscaledb — Key-value
- Cloudflare Workers KV — Key-value
- Elliptics — Key-value
- Tokyo — Tyrant — Key-value
- LeanXcale — мультимодальная
- Immudb — Key-value, мультимодальная
- STSdb — Key-value
- TomP2P — Key-value
- ArcadeDB — мультимодальная
- Speedb Key-value
- Faircom DB — мультимодальная
- Kyoto Tycoon — Key-value
- Skytable — Key-value
- HyperLevelDB — Key-value
- YTsaurus — мультимодальная
- InfinityDB — Key-value
- Tigris — мультимодальная
- Badger — Key — value
- Dragonfly — Key — value
- LedisDB — Key-value
- TerarkDB — Key-value
- Cachelot.io — Key-value
- ScaleOut StateServer — Key-value
- JaguarDB — Key-value
- Resin Cache — Key-value
- Faircom EDGE — мультимодальная
- SwayDB — Key-value
- BergDB — Key-value
- CortexDB — мультимодальная
- Helium — Key-value
- Tkrzw — Key-value
Из отечественных СУБД здесь следует отдельно выделить Tarantool, распространяемый под лицензией Упрощенная BSD и имеющий отдельную версию для крупных корпоративных клиентов. В Tarantool реализована гибридная схема данных: key-value, документно-ориентированная, реляционная и пространственная.
Вы можете развернуть Key-value базу данных Redis в облаке Amvera Cloud c помощью простого push в выделенный Git-репозиторий. Для этого нужно выполнить несколько простых шагов, описанных в инструкции по развертыванию Redis. Стоимость хостинга Redis начинается от 170 руб. в месяц.
Документо-ориентированные базы данных
Если вам нужно хранить много файлов/документов и вы не хотите задумываться (до разумных пределов, разумеется) о структуре хранения, иерархии, связях, вам может подойти одна из документо-ориентированных баз данных. Дополнительным преимуществом являются широкие возможности для масштабирования.
Документо-ориентированные базы данных созданы для хранения иерархических структур данных (документов). Основой документоориентированных СУБД являются документные хранилища, имеющие структуру дерева или леса. Деревья начинаются с корневого узла и может содержать несколько внутренних и листовых узлов. Листовые узлы содержат данные, которые при добавлении документа заносятся в индексы, это дает возможность даже при достаточно сложной структуре находить путь к искомых данных. В отличие от хранилищ типа ключ-значение, выборка по запросу к документному хранилищу может содержать части большого количества документов без полной загрузки этих документов в оперативную память.
Наиболее популярной документо-ориентированной базой данных на текущий момент является MongoDB.
Полный список из 56 решений документо-ориентированных баз данных подкатом
1. MongoDB — Документо-ориентированная, мультимодальная
2. Amazon DynamoDB — мультимодальная
3. Databricks — мультимодальная
4. Microsoft Azure Cosmos DB — мультимодальная
5. Couchbase — Документо-ориентированная, мультимодальная
6. Firebase Realtime Database — Документо-ориентированная
7. CouchDB — Документо-ориентированная, мультимодальная
8. Google Cloud Firestore — Документо-ориентированная
9. MarkLogic — мультимодальная
10. Realm — Документо-ориентированная
11. Aerospike — мультимодальная
12. Google Cloud Datastore — Документо-ориентированная
13. Virtuoso — мультимодальная
14. OrientDB — мультимодальная
15. ArangoDB — мультимодальная
16. RavenDB — Документо-ориентированная, мультимодальная
17. Oracle NoSQL — мультимодальная
18. IBM Cloudant — Документо-ориентированная
19. RethinkDB — Документо-ориентированная, мультимодальная
20. InterSystems IRIS — мультимодальная
21. PouchDB — Документо-ориентированная
22. CloudKit — Документо-ориентированная
23. Apache Drill — мультимодальная
24. Amazon DocumentDB — Документо-ориентированная
25. Mnesia — Документо-ориентированная
26. LiteDB — Документо-ориентированная
27. Fauna — мультимодальная
28. Datameer — Документо-ориентированная
29. GigaSpaces — мультимодальная
30. FoundationDB — мультимодальная
31. AllegroGraph — мультимодальная
32. HPE Ezmeral Data Fabric — мультимодальная
33. CrateDB — мультимодальная
34. LokiJS — Документо-ориентированная
35. BigchainDB — Документо-ориентированная
36. AlaSQL — мультимодальная
37. SurrealDB — мультимодальная
38. Sequoiadb — мультимодальная
39. Percona Server for MongoDB — Документо-ориентированная
40. HarperDB — Документо-ориентированная
41. EJDB — Документо-ориентированная
42. YDB — мультимодальная
43. ArcadeDB — мультимодальная
44. Bangdb — мультимодальная
45. XTDB — Документо-ориентированная
46. YTsaurus — мультимодальная
47. OrigoDB — мультимодальная
48. WhiteDB — Документо-ориентированная
49. ToroDB — Документо-ориентированная
50. SenseiDB — Документо-ориентированная
51. Acebase — Документо-ориентированная
52. iBoxDB — Документо-ориентированная
53. RaptorDB — Документо-ориентированная
54. NosDB — Документо-ориентированная
55. CortexDB — мультимодальная
56. JasDB — Документо-ориентированная
Из отечественных решений, к документо-ориентированным базам данных можно отнести СУБД Енисей.
И в рамках одной из модальностей к таким базам можно отнести YDB и YTsaurus.
Вы можете развернуть документо-ориентированную базу данных MongoDB в облаке Amvera Cloud c помощью простого push в выделенный Git-репозиторий. Для этого нужно выполнить несколько простых шагов, описанных в инструкции по развертыванию MongoDB. Стоимость хостинга MongoDB начинается от 170 руб. в месяц.
Базы данных временных рядов
Если у вас есть упорядоченные по времени данные с временными метками, такие как метрики от инфраструктуры или данные датчиков, может быть полезно использовать одну из баз данных временных рядов.
Общие характеристики баз данных временных рядов:
- Данные временных рядов всегда собираются на протяжении определенного периода времени.
- Данные из рабочих нагрузок являются новыми и записываются как вставки. Уже существующие данные не обновляются путем замены.
- Когда данные записываются, они автоматически назначаются последнему интервалу времени.
Базы даных временных рядов часто используются для осуществления мониторинга различных метрик (будь то загрузка CPU, или показатели работы какого-либо датчика).
Наиболее популярными и базами временных рядов являются Prometheus, InflubDB, Graphite.
Полный список из 43 СУБД для хранения временных рядов
Time Series, мультимодальная
Модели организации баз данных
Аннотация: В лекции рассматриваются модели организации баз данных, дается характеристика каждой модели. Описываются достоинства и недостатки существующих моделей баз данных. Даются определения атрибута, записи и отношений в различных моделях БД.
Цель лекции: Уяснить разницу между моделями организации БД . Ознакомиться с их достоинствами и недостатками. Понять, как организовываются связи в этих моделях, как применяются операции изменения в той или иной модели.
Различают три основные модели базы данных — это иерархическая, сетевая и реляционная. Эти модели отличаются между собой по способу установления связей между данными.
1. Иерархический подход к организации баз данных. Иерархические базы данных имеют форму деревьев с дугами-связями и узлами-элементами данных. Иерархическая структура предполагала неравноправие между данными — одни жестко подчинены другим. Подобные структуры, безусловно, четко удовлетворяют требованиям многих, но далеко не всех реальных задач.
2. Сетевая модель данных. В сетевых БД наряду с вертикальными реализованы и горизонтальные связи. Однако унаследованы многие недостатки иерархической и главный из них, необходимость четко определять на физическом уровне связи данных и столь же четко следовать этой структуре связей при запросах к базе.
3. Реляционная модель. Реляционная модель появилась вследствие стремления сделать базу данных как можно более гибкой. Данная модель предоставила простой и эффективный механизм поддержания связей данных.
Во-первых, все данные в модели представляются в виде таблиц и только таблиц. Реляционная модель — единственная из всех обеспечивает единообразие представления данных. И сущности, и связи этих самых сущностей представляются в модели совершенно одинаково — таблицами. Правда, такой подход усложняет понимание смысла хранящейся в базе данных информации, и, как следствие, манипулирование этой информацией.
Избежать трудностей манипулирования позволяет второй элемент модели — реляционно-полный язык (отметим, что язык является неотъемлемой частью любой модели данных, без него модель не существует). Полнота языка в приложении к реляционной модели означает, что он должен выполнять любую операцию реляционной алгебры или реляционного исчисления ( полнота последних доказана математически Э.Ф. Коддом). Более того, язык должен описывать любой запрос в виде операций с таблицами, а не с их строками. Одним из таких языков является SQL .
Третий элемент реляционной модели требует от реляционной модели поддержания некоторых ограничений целостности . Одно из таких ограничений утверждает, что каждая строка в таблице должна иметь некий уникальный идентификатор , называемый первичным ключом. Второе ограничение накладывается на целостность ссылок между таблицами. Оно утверждает, что атрибуты таблицы, ссылающиеся на первичные ключи других таблиц, должны иметь одно из значений этих первичных ключей.
4. Объектно-ориентированная модель. Новые области использования вычислительной техники, такие как научные исследования, автоматизированное проектирование и автоматизация учреждений, потребовали от баз данных способности хранить и обрабатывать новые объекты — текст, аудио- и видеоинформацию, а также документы. Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных , не существует. В большой степени, поэтому до сих пор нет базовой объектно-ориентированной модели. С другой стороны, некоторые авторы утверждают, что общая объектно-ориентированная модель данных в классическом смысле и не может быть определена по причине непригодности классического понятия модели данных к парадигме объектной ориентированности. Несмотря на преимущества объектно-ориентированных систем — реализация сложных типов данных , связь с языками программирования и т.п. — на ближайшее время превосходство реляционных СУБД гарантировано.
Рассмотрим более подробно эти модели данных далее.
Иерархическая модель базы данных
Иерархические базы данных — самая ранняя модель представления сложной структуры данных. Информация в иерархической базе организована по принципу древовидной структуры, в виде отношений «предок- потомок «. Каждая запись может иметь не более одной родительской записи и несколько подчиненных. Связи записей реализуются в виде физических указателей с одной записи на другую. Основной недостаток иерархической структуры базы данных — невозможность реализовать отношения » многие-ко-многим «, а также ситуации, когда запись имеет несколько предков.
Иерархические базы данных . Иерархические базы данных графически могут быть представлены как перевернутое дерево , состоящее из объектов различных уровней. Верхний уровень ( корень дерева ) занимает один объект , второй — объекты второго уровня и так далее.
Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка ( объект , более близкий к корню) к потомку ( объект более низкого уровня), при этом объект -предок может не иметь потомков или иметь их несколько, тогда как объект — потомок обязательно имеет только одного предка. Объекты, имеющие общего предка, называются близнецами.
Иерархической базой данных является Каталог папок Windows , с которым можно работать, запустив Проводник. Верхний уровень занимает папка Рабочий стол . На втором уровне находятся папки Мой компьютер , Мои документы, Сетевое окружение и Корзина , которые являются потомками папки Рабочий стол , а между собой является близнецами. В свою очередь , папка Мой компьютер является предком по отношению к папкам третьего уровня -папкам дисков ( Диск 3,5(А:), (С:), (D:), (Е:), (F:)) и системным папкам ( сканер , bluetooth и.т.д.) — на рис. 4.1.
Рис. 4.1. Иерархическая база данных Каталог папок Windows
Организация данных в СУБД иерархического типа определяется в терминах: элемент, агрегат, запись ( группа ), групповое отношение , база данных .
| Атрибут (элемент данных) | — наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем. |
| Запись | — именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи — конкретная запись с конкретным значением элементов. |
| Групповое отношение | — иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) — подчиненными. Иерархическая база данных может хранить только такие древовидные структуры. |
Корневая запись каждого дерева обязательно должна содержать ключ с уникальным значением. Ключи некорневых записей должны иметь уникальное значение только в рамках группового отношения. Каждая запись идентифицируется полным сцепленным ключом, под которым понимается совокупность ключей всех записей от корневой, по иерархическому пути.
При графическом изображении групповые отношения изображают дугами ориентированного графа, а типы записей — вершинами ( диаграмма Бахмана).
Для групповых отношений в иерархической модели обеспечивается автоматический режим включения и фиксированное членство. Это означает, что для запоминания любой некорневой записи в БД должна существовать ее родительская запись .
Пример
Рассмотрим следующую модель данных предприятия (см. рис. 4.2): предприятие состоит из отделов, в которых работают сотрудники. В каждом отделе может работать несколько сотрудников, но сотрудник не может работать более чем в одном отделе.
Поэтому, для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на рис. 4.2 (а) (Для простоты полагается, что имеются только две дочерние записи).
Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры: заказчик — контракты с ним — сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК (НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА) ( рис. 4.2 b).
Рис. 4.2. Пример иерархической базы данных
Из этого примера видны недостатки иерархических БД :
Частично дублируется информация между записями СОТРУДНИК и ИСПОЛНИТЕЛЬ (такие записи называют парными), причем в иерархической модели данных не предусмотрена поддержка соответствия между парными записями.
Иерархическая модель реализует отношение между исходной и дочерней записью по схеме 1:N, то есть одной родительской записи может соответствовать любое число дочерних.
Допустим теперь, что исполнитель может принимать участие более чем в одном контракте (т.е. возникает связь типа M:N). В этом случае в базу данных необходимо ввести еще одно групповое отношение , в котором ИСПОЛНИТЕЛЬ будет являться исходной записью, а КОНТРАКТ — дочерней ( рис. 4.2 c). Таким образом, мы опять вынуждены дублировать информацию.
Операции над данными, определенные в иерархической модели :
- Добавить в базу данных новую запись. Для корневой записи обязательно формирование значения ключа.
- Изменить значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.
- Удалить некоторую запись и все подчиненные ей записи.
- Извлечь корневую запись по ключевому значению, допускается также последовательный просмотр корневых записей.
- Извлечь следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева ).
В операции ИЗВЛЕЧЬ допускается задание условий выборки (например, извлечь сотрудников с окладом более 10 тысяч руб.)
Как видим, все операции изменения применяются только к одной «текущей» записи (которая предварительно извлечена из базы данных ). Такой подход к манипулированию данных получил название «навигационного».
Ограничения целостности
Поддерживается только целостность связей между владельцами и членами группового отношения (никакой потомок не может существовать без предка). Как уже отмечалось, не обеспечивается автоматическое поддержание соответствия парных записей, входящих в разные иерархии.