СУБД: что такое, зачем нужны, классификация, советы

Категория: Что такое?

– Автор: Игорь (Администратор)

Система управления базами данных или СУБД. Как много мысли в этих буквах! А если серьёзно, то текущее развитие области информационных технологий было бы невозможно без подобных программных средств. Поэтому в данном обзоре рассмотрим что такое "эти СУБД", для чего они нужны и ещё ряд моментов.

Но обо всем по порядку.

БД и СУБД это

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

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

Примечание: Кстати, насколько знаю, единого определения БД и СУБД не существует. Поэтому если вы где-то встретили иное определение, то это вполне нормально. Кстати, в ГОСТ 34.321-96 примерно такие же определения, как и вышеприведённые.

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

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

Для чего нужны СУБД: функции и состав

Для начала рассмотрим функции СУБД:

1. Создание, удаление, изменение и объединение баз данных.

2. Ввод, корректирование и получение информации из баз данных.

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

4. Поддержка специализированного языка программирования (чтобы пользователь мог управлять данными, например, языка SQL).

5. Поддержка системы безопасности (если такое предусмотрено). Простыми словами разный уровень доступа к данным для разных пользователей.

6. Осуществление резервного копирования (если такое предусмотрено).

7. И многое другое, что может требоваться для нормального функционирования.

Теперь рассмотрим из чего состоит СУБД:

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

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

3. Интерфейс То, через что пользователи могут управлять данными.

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

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

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

Рассмотрим несколько основных классификаций СУБД.

По типу хранения БД:

1. Локальные. Всё хранится в одном компьютере.

2. Распределённые. Части системы хранятся в разных компьютерах (серверах), в том числе и облачный подход.

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

По типу хранения данных:

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

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

3. Встраиваемые. По сути, локальные СУБД, которые используются в качестве части какой-то другой программы (как отдельный модуль).

По типу модели данных:

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

Примеры: MySQL, MariaDB, PostgreSQL.

2. Key-Value (Ключ-Значение) СУБД. Данные хранятся в виде связки "1 ключ - 1 значение". Удобство такого подхода в том, что если вам нужно постоянно вытаскивать только какие-то простые данные с простой структурой, то вам не нужно сильно кумекать. Кроме того, масштабировать такие хранилища существенно проще. Утрируя, ключи с 000001 по 100000 хранятся в одном сервере, с 100001 по 200000 в другом и так далее. Минус, как не сложно догадаться, в том, что если требуется использовать множество объектов (получить суммарные данные, массово что-то подкорректировать), то это крайне затратное действие.

Примеры: Redis, Memcached.

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

Пример: CouchDB.

4. Графовые СУБД. Специальный тип, чья основная задача это хранение взаимосвязей между объектами. Чаще всего речь о социальных сетях, где основная информация, кроме данных самих пользователей, это их взаимосвязи.

Пример: Neo4j.

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

Это крайне удобно в случаях, когда речь идёт об аналитике, не говоря уже о разных хитростях хранения данных (их сжатия и т.п.). Абстрактный упрощённый пример, допустим, в таблице 100 колонок и 1000 строк, а вам нужны какие-то суммарные данные только из 10 колонок. В реляционных СУБД нужно вытащить все 1000 строк полностью (помним, что у каждой строки по 100 колонок, т.е. это 100 000 разных значений). В колоночных же СУБД нужно вытащить только 10 колонок для этих же 1000 строк (а это уже 10 000 значений). Грубо говоря, разница в нагрузке в 10 раз.

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

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

Пример: LucidDB.

Примечание: Учтите, что в примерах только некоторые бесплатные СУБД, а так СУБД существенно больше (как бесплатных, так и коммерческих).

Несколько советов по выбору СУБД

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

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

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

3. Лучшая СУБД не значит оптимальное решение. Например, если вы поинтересуетесь в интернете, то сможете узнать, что достаточно крупные проекты используют PostgreSQL, хотя эта СУБД является бесплатной. И ещё пример. Скажем, если вам нужно хранить совсем мало данных, то чем будет плох обычный текстовый файл (ну или файл в каком-то определённом формате)? Ничем. В реальности немалое количество приложений так и делают.

4. Не гонитесь за модой. Попытка создать сферического коня в вакууме редко приводит к хорошим результатам. Помнится в своё время много писали про Key-Value. И действительно, вещь полезная, но пихать такие СУБД только потому, что о них пишут, это не самая лучшая идея.

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

Так же вам может быть интересен обзор Уникальное или Универсальное решение, что лучше?

Понравилась заметка? Тогда время подписываться в социальных сетях и делать репосты!