Что такое реляционная субд кратко

Обновлено: 05.07.2024

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

Каталог СУБД-решений и проектов доступен на TAdviser.

Реляционные базы данных занимают сейчас доминирующее положение. Иерархическая и сетевая структуры баз данных ушли в прошлое, уступив свое место реляционным базам, под которые постороено большинство современных СУБД (MS SQL Server, MS Access, InterBase, FoxPro, PostgreSQL, Paradox и другие).

Подробности

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

Каждый элемент таблицы является одним элементом данных
Каждый столбец обладает своим уникальным именем
Одинаковые строки в таблице отсутствуют
Все столбцы в таблице однородные, то есть все элементы в столбце имеют одинаковый тип
Порядок следования строк и столбцов может быть произвольным

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

Основные недостатки

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

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

Реляционные СУБД все еще доминируют в системах обработки финансовых транзакций, но сегодня компании все шире применяют СУБД новой архитектуры NoSQL — горизонтально масштабируемые, распределенные и разрабатываемые в открытых кодах. Примеры таких систем — Hadoop, MapReduce и VoltDB. По оценкам аналитиков Forrester, около 75% данных на предприятиях это либо полуструктурированная информация (XML, электронная почта и EDI), либо неструктурированная (текст, изображения, аудио и видео), и лишь 5% от этих данных хранится в реляционных СУБД, а остальное — в базах других типов или в виде файлов, и неподвластно обработке реляционными системами.

Реляционная СУБД (РСУБД; иначе Система управления реляционными базами данных, СУРБД) — СУБД, управляющая реляционными базами данных.

Понятие реляционный (англ. relation — отношение) связано с разработками известного английского специалиста в области систем баз данных Эдгара Кодда (Edgar Codd).

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

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

Базовыми понятиями реляционных СУБД являются:

См. также

Литература

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое "Реляционная СУБД" в других словарях:

реляционная СУБД, разработанная фирмой MicroRim для IBM PC-совместимых ПЭВМ — — [Е.С.Алексеев, А.А.Мячев. Англо русский толковый словарь по системотехнике ЭВМ. Москва 1993] Тематики информационные технологии в целом EN R:base … Справочник технического переводчика

Объектно-реляционная СУБД — Эта статья должна быть полностью переписана. На странице обсуждения могут быть пояснения. Объектно реляционная СУБД (ОРСУБД) реляционная СУБД (РСУБД), поддерживающая неко … Википедия

Реляционная модель данных — (РМД) логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка. На реляционной модели данных строятся… … Википедия

Реляционная алгебра — Реляционная алгебра замкнутая система операций над отношениями в реляционной модели данных. Операции реляционной алгебры также называют реляционными операциями. Первоначальный набор из 8 операций был предложен Э. Коддом в 1970 е годы и… … Википедия

реляционная база данных — База данных, реализованная в соответствии с реляционной моделью данных. [ГОСТ 20886 85] реляционная БД База данных, логически организованная в виде набора отношений ее компонентов. Характерной особенностью реляционной базы данных является… … Справочник технического переводчика

Реляционная модель — данных логическая модель данных, строгая математическая теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в реляционных базах данных. Структурный аспект (составляющая) данные в базе данных представляют собой… … Википедия

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

Реляционные СУБД — Реляционная СУБД (РСУБД; иначе Система управления реляционными базами данных, СУРБД) СУБД, управляющая реляционными базами данных. Понятие реляционный (англ. relation отношение) связано с разработками известного английского специалиста в… … Википедия

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

Основные функции СУБД¶

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

Обычно современная СУБД содержит следующие компоненты:

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

Классификации СУБД¶

По модели данных¶

Иерархические¶

Используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.

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

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

Примеры: Caché, Google App Engine Datastore API.

Сетевые¶

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

Реляционные¶

Практически все разработчики современных приложений, предусматривающих связь с системами баз данных, ориентируются на реляционные СУБД. По оценке Gartner в 2013 году рынок реляционных СУБД составлял 26 млрд долларов с годовым приростом около 9%, а к 2018 году рынок реляционных СУБД достигнет 40 млрд долларов. В настоящее время абсолютными лидерами рынка СУБД являются компании Oracle, IBM и Microsoft, с общей совокупной долей рынка около 90%, поставляя такие системы как Oracle Database, IBM DB2 и Microsoft SQL Server.

Объектно-ориентированные¶

Управляют базами данных, в которых данные моделируются в виде объектов, их атрибутов, методов и классов.

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

Объектно-реляционные¶

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

Зачастую все те СУБД, которые называются реляционными, являются, по факту, объектно-реляционными.

В данном курсе мы будем, в первую очередь, гооврить об этом виде СУБД.

Примеры: PostgreSQL, DB2, Oracle, Microsoft SQL Server.

По степени распределённости¶

Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)
Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах).

По способу доступа к БД¶

Файл-серверные¶

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

На данный момент файл-серверная технология считается устаревшей, а её использование в крупных информационных системах — недостатком.

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

Клиент-серверные¶

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

Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.

Встраиваемые¶

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

Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.

Стратегии работы с внешней памятью¶

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

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

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

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

Реляционные базы данных уже давно используются в программировании. В своё время они обрели популярность благодаря простоте и удобству реляционной модели работы с данными.

Данная статья анализирует различия между наиболее популярными реляционными системами управления базами данных (СУБД): SQLite, MySQL и PostgreSQL.

Системы управления базами данных

Базы данных – это логически смоделированные хранилища различной информации (данных) всех видов. Каждая база данных SQL основана модели, которая предоставляет структуру для хранящихся в ней данных. Системы управления базами данных – это приложения (или библиотеки), которые управляют базами данных различных форм, размеров и видов.

Примечание: Чтобы узнать больше о СУБД, читайте статью SQL, NoSQL и другие модели баз данных.

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

Реляционные СУБД для работы с данными используют реляционную модель. Эта модель хранит любую информацию в таблицах в виде связанных записей с атрибутами.

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

Отношения и типы данных

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

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

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

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

SQLite

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

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

Типы данных SQLite

Примечание: Больше о типах данных SQLite можно узнать в официальной документации.

Преимущества SQLite

Простое строение на основе файлов: вся база данных состоит всего из одного файла, что увеличивает её портативность.
Стандарты: несмотря на простоту, система SQLite основана на SQL. Некоторые функции опущены (RIGHT OUTER JOIN или FOR EACH STATEMENT), однако вместо них добавлены другие.
SQLite отлично подходит для разработки или тестирования. На этих этапах почти всегда необходимо простое, но масштабируемое решение.

Недостатки SQLite

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

Когда лучше использовать SQLite

Простые встроенные приложения, которым нужна портативность, например, однопользовательские локальные приложения, мобильные приложения, игры.
Замена диска. Обычно приложения, которым необходимо читать или записывать файлы на диск, могут использовать SQLite для получения дополнительных функций.
Тестирование.

Когда лучше не использовать SQLite

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

MySQL

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

Примечание: Учитывая популярность MySQL, для этой системы было разработано большое количество сторонних приложений, инструментов и библиотек.

MySQL не реализует полный стандарт SQL. Несмотря на это, MySQL предлагает множество функциональных возможностей для пользователей: автономный сервер баз данных, взаимодействие с приложениями и сайтами и т.п.

Типы данных MySQL

TINYINT: целое число в диапазоне от -128 до 127 (1 байт).
SMALLINT: целое число от -32768 до 32767 (2 байта).
MEDIUMINT: число от -8388608 до 8388608 (3 байта).
INT или INTEGER: число в диапазоне от -2147683648 до 2147683648 (4 байта).
BIGINT: число от -2 63 до 2 63 -1 (8 байт).
FLOAT: число с плавающей точкой (4 байта).
DOUBLE, DOUBLE PRECISION, REAL: число с двойной точностью и плавающей точкой.
DECIMAL, NUMERIC: величины повышенной точности.
DATE: дата.
DATETIME: дата и время.
TIMESTAMP: временная метка.
TIME: время в формате hh:mm:ss.
YEAR: год (по умолчанию хранится в виде 4 цифр, но можно настроить и 2).
CHAR: строка фиксированной длины.
VARCHAR: строки переменных.
TINYBLOB, TINYTEXT: Тип TEXT позволяет хранить текст, а BLOB – изображения, звук, электронные документы и т.п. Максимальная длина – 225 символов.
BLOB, TEXT: большие объемы текста, максимум 65535 символов.
MEDIUMBLOB, MEDIUMTEXT: аналогично предыдущему, но максимум до 16777215 символов.
LONGBLOB, LONGTEXT: аналогично предыдущему, но максимум до 4294967295 символов.
ENUM: принимает только одно из значений заданного множества.
SET: принимает любой или все элементы из значений заданного множества.

Преимущества MySQL

Простота в работе: MySQL очень просто установить и настроить. Сторонние инструменты, в том числе визуализаторы (интерфейсы) значительно упрощают работу с данными.
Функциональность: MySQL поддерживает огромное количество функций SQL.
Безопасность: MySQL предоставляет много встроенных продвинутых функций для защиты данных.
Масштабируемость и производительность: MySQL может работать с большими объёмами данных.

Недостатки MySQL

Ограничения: структура MySQL накладывает некоторые ограничения, из-за которых не смогут работать продвинутые приложения.
Уязвимости: метод обработки данных, применяемый в MySQL, делает эту СУБД немного менее надёжной по сравнению с другими СУБД.
Медленное развитие: хотя MySQL является продуктом с открытым исходным кодом, он очень медленно развивается. Однако тут следует заметить, что на MySQL основано несколько полноценных баз данных (например, MariaDB).

Когда использовать MySQL

Распределенные операции: автономный сервер баз данных MySQL поддерживает множество операций и предоставляет несколько дополнительных функций.
Высокая безопасность данных: MySQL предлагает высокую защиту данных.
Веб-сайты и веб-приложения: несмотря на ограничения MySQL может поддерживать работу почти любого сайта и веб-приложения. Этот гибкий и масштабируемый инструмент прост в использовании.
Пользовательские решения: MySQL можно подогнать под строгие требования сайта или приложения.

Когда лучше не использовать MySQL

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

PostgreSQL

PostgreSQL – это продвинутая открытая объектно-ориентированная СУБД. PostgreSQL реализует SQL-стандарты ANSI/ISO.

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

Основанная на надёжной технологии СУБД PostgreSQL может одновременно обрабатывать большое количество задач. Поддержка согласованности достигается без блокирования операций чтения благодаря MVCC.

Хотя СУБД PostgreSQL не так популярна, как MySQL, для неё тоже разработано большое количество дополнительных инструментов и библиотек, которые упрощают работу с данными и увеличивают производительность СУБД.

Значительная часть программного обеспечения — будь то ПО для банков, страховых организаций, фондов, денежного рынка, платежных сервисов — разрабатывается на основе базы данных.

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

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

Вот список наиболее часто используемых СУБД:

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

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

Типы СУБД. Как выбрать правильный?

Реляционная СУБД

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

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

Самые известные реляционные СУБД:

Oracle;
Microsoft SQL;
PostgreSQL;
MySQL;
IBM DB2.

Когда следует выбирать реляционную базу данных?

Во-первых (1), при высокой нормализации данных. А во-вторых (2), при обработке большого количества коротких транзакций, среди которых немалый процент транзакций с вставкой.

Когда не следует выбирать реляционную СУБД?

Графовая СУБД

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

Простой пример — создание приложений типа соцсетей, где нужно хранить соединения между пользователями (узлами) в соответствии с критериями: общие интересы, коллеги, родственники.

Самые известные графовые СУБД:

Neo4j;
Amazon Neptune;
InfiniteGraph;
InfoGrid.

Когда следует выбирать графовую базу данных?

1) При создании соцсети или реализации рейтинговой и рекомендательной системы и 2) при глубоком понимании графов и их назначения.

Когда не следует выбирать графовую базу данных?

Почти во всех остальных случаях.

Документная СУБД

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

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

Самые известные документные СУБД:

CouchDB;
MongoDB;
Amazon DocumentDB.

Когда следует выбирать документную БД?

У документной СУБД широкий диапазон применения: от 1) компактной БД для одного микросервиса до 2) крупномасштабных решений в качестве хранилища состояния.

Лучше хранить объекты в одной сущности, но с разными структурами. Кстати, очень полезны они и 3) для хранения структур (включая объекты, списки и словари), особенно в JSON-подобном формате.

Когда не следует выбирать документную СУБД?

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

Столбцовая СУБД

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

Реляционная СУБД хранит данные построчно. То есть для считывания значения конкретного столбца приходится считывать почти всю строку — от первого до этого столбца.

Столбцовая СУБД хранит данные по столбцам. То есть столбец предстает в виде отдельной таблицы. А считывание выполняется прямо из конкретного столбца. На самом деле работает очень быстро — протестировано на нескольких реализованных хранилищах данных.

Преимущества столбцовой СУБД:

эффективно выполняет сложные аналитические запросы для большого объема данных;
простое и почти мгновенное реструктурирование таблиц с данными;
существенное сжатие, которое экономит много места.

Самые известные столбцовые СУБД:

Sybase IQ (SAP IQ);
Vertica;
ClickHouse;
Google BigQuery;
InfoBright;
Apache Druid.

Когда следует выбирать столбцовую БД?

1) При создании хранилища данных и осуществлении выборки со сложными аналитическими вычислениями. 2) Когда количество запрашиваемых строк превышает сотни миллионов.

Когда не следует выбирать столбцовую СУБД?

1) Когда количество строк в таблице, из которой делаются запросы, меньше сотен миллионов. Здесь у столбцовой СУБД перед реляционной преимуществ будет немного.

2) Когда запросы достаточно простые и со статичными параметрами. В этом случае — учитывая специфику системы — столбцовая СУБД будет неэффективна.

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

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

Когда 1) в БД хранится много сущностей (таблиц), имеющих сложные структуры с разными типами данных. Когда 2) надо выполнять сложные запросы, возвращающие много строк.

СУБД временных рядов

Эта СУБД оптимизирована для хранения данных с метками времени или данных временных рядов. Данные временных рядов содержат измерения или события, которые отслеживаются, собираются или объединяются за определенный период времени.

Это данные с датчиков отслеживания движения, метрики JVM из приложений на Java, данные о рыночной торговле, сетевые данные, ответы от API, время безотказной работы процесса и т. д.

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

Самые известные СУБД временных рядов:

Когда следует выбирать СУБД временных рядов?

Основная область применения таких СУБД — мониторинг, обработка телеметрии и финансовые системы.

Когда не следует выбирать СУБД временных рядов?

Воздержитесь от использования такой СУБД в задачах, не связанных с временными рядами и метками времени.

Объектно-ориентированная СУБД

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

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

Самые известные объектно-ориентированные СУБД:

Когда следует выбирать объектно-ориентированную СУБД?

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

В то же время разработка 2) предполагает применение объектно-ориентированных языков программирования. Объектно-ориентированные БД распространены в системах реального времени, архитектуре и инженерии для 3D-моделирования, телекоммуникациях и научных продуктах, молекулярной науке и астрономии.

Когда не следует выбирать объектно-ориентированную СУБД?

1) При использовании классического языка SQL, 2) когда не применяется ООП или 3) при переходе на другую БД. И 4) при отсутствии глубокого понимания ООП. Тогда стоит выбрать документную СУБД.

Поисковая СУБД

Этот тип СУБД используется для осуществления полнотекстового поиска. А также поиска по различным данным, например из других БД, электронной почты, RSS-канала, текста, JSON, XML, CSV и даже PDF и документам MS Office.

Поисковая СУБД имеет собственные оптимизированные подходы к индексированию данных, в том числе использование так называемых инвертированных и фасетных индексов для поиска почти в реальном времени.

Различные СУБД этого типа применяют разные языки запросов.

Самые известные поисковые СУБД:

Когда следует выбирать поисковую СУБД?

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

Когда не следует выбирать поисковую СУБД?

При поиске по ограниченному числу полей структурированных данных.

СУПБД (система управления пространственными базами данных)

Этот тип СУБД оптимизирован для работы с объектами, определенными в геометрическом пространстве — как простыми (точки, кривые, многоугольники), так и сложными (3D-объекты, топологическое покрытие, линейные сети).

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

Самые известные СУПБД:

Когда следует выбирать СУПБД?

При создании ГИС-решений — не только для хранения, но и для работы с геометрическими объектами на уровне СУПБД.

Когда не следует выбирать СУПБД?

Для хранения геометрических объектов в качестве координат.

Заключение

Определиться с выбором СУБД бывает нелегко, ведь их так много! Надеемся, вы немного прояснили для себя этот вопрос и теперь легко выберите подходящую.

Хотите создать сложное решение? Тогда понадобится несколько типов СУБД. И не торопитесь с выбором поставщиков СУБД: обычно это тема второстепенная.

Выбирайте тип СУБД на основе следующих трех факторов:

тип решаемых задач;
типы обрабатываемых данных;
перспективы роста и масштабирование.

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

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