14 видов баз данных: полный обзор типов СУБД с примерами и описанием

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

В статье разобраны 14 видов баз данных: от классических реляционных через NoSQL до современных векторных и NewSQL. Для каждого типа — примеры СУБД, типовые задачи и ключевые свойства. В конце — практическое дерево решений «задача → тип БД».

Все виды СУБД: сводная таблица с примерами

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

Далее в статье каждый тип разобран подробно — модель хранения, сильные стороны, ограничения, примеры. Если нужен быстрый выбор — листайте в раздел «Как выбрать тип базы данных под задачу».

Курс «Специалист по аналитике и базам данных» — освоить СУБД бесплатно

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

Программа реализуется в рамках национального проекта «Кадры»: участие полностью бесплатно, государственное финансирование покрывает стоимость в 120 000 ₽. По итогам — удостоверение о повышении квалификации установленного образца, обучение ведётся по государственной лицензии.

Формат удобен для работающих: занятия 1–2 раза в неделю онлайн, лекции и материалы доступны в любое время. Предыдущий опыт в IT не требуется — обучение с нуля.

Что получает выпускник:

• зарплата аналитика данных — от 70000 ₽;
• доступ в Центр карьеры: 7 500+ вакансий, HR-консультации, биржа заказов;
• бонусный пакет: курс китайского языка, сертификат в Sigma Academy, карьерный марафон.

Более 200 000 студентов уже прошли обучение по программам проекта, 85% выпускников трудоустроены. Сейчас доступно 74 места из 100. Подробнее — на странице программы по аналитике и базам данных.

Реляционные базы данных

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

Язык запросов — SQL (Structured Query Language, структурированный язык запросов). Он стандартизирован и работает во всех реляционных системах, хотя диалекты отличаются.

Главное преимущество — ACID-гарантии: атомарность (Atomicity), согласованность (Consistency), изолированность (Isolation), долговечность (Durability). Это делает реляционные базы незаменимыми там, где данные нельзя потерять или исказить: финансы, ERP, CRM, e-commerce, здравоохранение.

Примеры: PostgreSQL, MySQL, Oracle Database, Microsoft SQL Server, SQLite.

Нормализация реляционных баз данных

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

Нормальные формы — последовательные уровни нормализации данных:

• 1НФ (первая нормальная форма): каждая ячейка содержит одно атомарное значение; нет повторяющихся групп столбцов.
• 2НФ: все неключевые атрибуты полностью зависят от первичного ключа — нет частичных зависимостей.
• 3НФ: нет транзитивных зависимостей — атрибуты зависят только от ключа, а не от других неключевых атрибутов.
• БКНФ (нормальная форма Бойса — Кодда): строгая версия 3НФ для таблиц с несколькими перекрывающимися ключами-кандидатами.

Пример: таблица «блюдо–категория–поставщик» хранит повторяющееся название категории в каждой строке. После нормализации категории и поставщики выносятся в отдельные таблицы — избыточные повторы исчезают. Нормализация данных снижает объём хранения и исключает аномалии при обновлении.

Виды связей таблиц в реляционных базах данных

Связи между таблицами реализуются через внешние ключи (FOREIGN KEY … REFERENCES). Три основных вида:

1:1 (один-к-одному). Каждой записи в одной таблице соответствует ровно одна запись в другой. Пример: пользователь → паспорт. Реализуется внешним ключом с ограничением UNIQUE.

1:N (один-ко-многим). Одной записи в «родительской» таблице соответствует несколько записей в «дочерней». Пример: клиент → его заказы. Самый распространённый вид связей таблиц в реляционных базах данных.

M:N (многие-ко-многим). Одной записи в таблице A соответствует несколько записей в таблице B, и наоборот. Пример: студент ↔ курс. Реализуется через промежуточную таблицу-связку с двумя внешними ключами.

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

Денормализация — когда оправдан обратный процесс

Денормализация — перенос полей из связанных таблиц в основную ради ускорения запросов на чтение. Классический сценарий: мессенджер выносит last_message и unread_count в таблицу-связку, чтобы загружать список чатов без тяжёлых JOIN.

Компромисс очевиден: быстрый SELECT оборачивается усложнённым UPDATE и DELETE — при изменении данных нужно обновлять их в нескольких местах. Денормализация оправдана, когда нормализованная схема плюс индексы уже не справляются с пиковой нагрузкой.

Нереляционные базы данных (NoSQL)

Нереляционные СУБД — собирательный термин для всех баз данных без жёсткой реляционной схемы. Аббревиатура NoSQL расшифровывается как «not only SQL» — «не только SQL». Они появились в 2000-х годах как ответ на ограничения реляционных систем при работе с большими данными и высокими веб-нагрузками.

Ключевой инструмент понимания NoSQL — CAP-теорема: распределённая система не может одновременно гарантировать Consistency (согласованность), Availability (доступность) и Partition Tolerance (устойчивость к разделению сети) — только два из трёх свойств. MongoDB выбирает CP, Cassandra — AP, классические реляционные СУБД на одном сервере — CA.

Единого стандарта запросов нет: каждый подтип использует собственную модель и язык.

Базы данных «ключ-значение» (Key-Value)

Простейшая модель: данные хранятся как словарь «ключ → значение», где значением может быть строка, число, JSON-объект, список или хэш. Физически данные находятся в оперативной памяти (in-memory хранение), поэтому задержки при чтении и записи — менее миллисекунды.

Типичное применение: кэширование результатов запросов, хранение пользовательских сессий, счётчики лайков и просмотров, балансы в игровых системах.

Ограничение: невозможно искать по содержимому значения — только по точному ключу. Для сложной аналитики этот тип не подходит.

Примеры: Redis, Memcached, etcd, Tarantool. Redis дополнительно поддерживает персистентность на диск и богатые структуры данных: списки, множества, отсортированные множества, потоки.

Документо-ориентированные базы данных

Документные СУБД хранят данные в виде документов — структурированных объектов в форматах JSON, BSON или XML. Разные документы в одной коллекции могут иметь различный набор полей: у одного товара есть поле color, у другого его нет — это не вызывает ошибок схемы.

Структура хранилища напоминает дерево с корневыми и листовыми узлами. Благодаря гибкой модели данных команды быстро итерируют: новое поле добавляется в документ без ALTER TABLE и миграций.

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

Примеры: MongoDB, CouchDB, RethinkDB, Firebase Realtime Database.

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

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

Язык запросов: Cypher (Neo4j), Gremlin (JanusGraph). Обход рёбер в графовой СУБД значительно быстрее, чем эквивалентные многоуровневые JOIN в реляционной базе данных — особенно при глубине связей от трёх уровней и выше.

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

Примеры: Neo4j, JanusGraph, Dgraph, NebulaGraph, TigerGraph.

Колоночные базы данных и Wide Column Stores

В реляционных СУБД данные хранятся построчно: при запросе SELECT age FROM users с диска читается вся строка целиком. Колоночные базы данных переворачивают этот принцип — данные хранятся постолбечно, и при аналитическом запросе читаются только нужные колонки.

Это резко снижает ввод-вывод при OLAP-аналитике: агрегации по миллиардам строк выполняются за секунды.

Wide Column Stores (Cassandra, HBase) добавляют к этому «колоночные семейства» с гибкой структурой каждой строки. Cassandra оптимизирована под запись и горизонтальное масштабирование. ClickHouse — пример чисто колоночной СУБД для аналитики петабайтного масштаба.

Специализированные типы баз данных

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

Базы данных временны́х рядов

Временны́е ряды — последовательности измерений с метками времени, упорядоченные хронологически. Данные только добавляются (insert), практически никогда не изменяются; каждое новое значение автоматически получает временну́ю метку.

Применение: мониторинг нагрузки серверов (CPU, RAM, сеть), IoT-датчики, биржевые котировки, телеметрия транспортных систем.

Prometheus стал стандартом сбора метрик в Kubernetes-кластерах: агенты опрашивают сервисы каждые 15–30 секунд, а Grafana визуализирует данные в реальном времени.

Примеры: InfluxDB, Prometheus, TimescaleDB (расширение PostgreSQL), VictoriaMetrics, QuestDB.

Векторные базы данных

Векторные базы данных хранят числовые массивы — эмбеддинги (векторные представления), создаваемые нейросетями. Каждый эмбеддинг кодирует смысл объекта: текста, изображения, аудиозаписи. Близкие по смыслу объекты имеют математически схожие векторы.

Основная операция — поиск ближайших соседей (Approximate Nearest Neighbor, ANN): по вектору запроса система находит векторы с минимальным расстоянием в многомерном пространстве.

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

Векторные СУБД — самый быстрорастущий класс в 2024–2026 годах, напрямую связанный с бумом ML/AI. Примеры: Pinecone, Milvus, Qdrant, Weaviate, Chroma.

Поисковые базы данных

Поисковые СУБД оптимизированы для полнотекстового поиска. Механизм — инвертированный индекс: для каждого слова (леммы, n-граммы) хранится список документов, где оно встречается. Поиск по индексу несравнимо быстрее, чем построчное сканирование текстов.

Применение: поиск по петабайтам логов в SIEM-системах, каталог товаров с нечётким поиском, полнотекстовая аналитика.

Примеры: Elasticsearch, OpenSearch (форк Elasticsearch), Solr, Manticore Search, Sphinx.

GEO/GIS пространственные базы данных

Пространственные СУБД хранят геометрические объекты: точки (координаты), линии (маршруты), полигоны (границы регионов). Ключевое отличие — пространственные операторы: «пересекается», «содержится в», «находится в радиусе N км».

Применение: картографические сервисы, геоаналитика (расчёт зон покрытия), навигационные приложения, кадастровые системы.

Примеры: PostGIS (расширение PostgreSQL), SpatiaLite, GeoMesa.

Нишевые и исторические модели баз данных

До появления реляционной модели в 1970-х годах данные организовывались иначе. Исторические типы изучают в информатике и системном анализе; часть из них применяется в нишевых задачах до сих пор.

Иерархические, сетевые и навигационные базы данных

Иерархическая модель организует данные как дерево: каждый узел-потомок связан ровно с одним родителем (связь 1:N). Структуры с такой логикой работают и сегодня — DNS-записи, LDAP-каталоги, файловые системы. Принципиальное ограничение: невозможность связей M:N.

Сетевая модель расширяет иерархическую: потомок может иметь несколько родителей. Реализована в IDMS (Integrated Database Management System). Позволяет отражать связи M:N, но навигация по данным требует знания физической структуры базы.

Навигационная модель — общий принцип доступа к данным через указатели и пути, а не через декларативный SQL. К ней относятся обе исторические системы — IBM IMS и IDMS. Декларативный SQL появился именно как альтернатива этому подходу.

Объектно-ориентированные СУБД, RDF, Event и контентные базы данных

Объектно-ориентированные СУБД (ОО СУБД) хранят объекты напрямую — без преобразования в таблицы. Это устраняет объектно-реляционное несоответствие (impedance mismatch). Примеры: Db4o, ObjectBox. Применяются во встроенных и мобильных приложениях со специфическими требованиями.

RDF-базы данных хранят данные в виде триплетов «субъект → предикат → объект» (S→P→O). Стандарт W3C, язык запросов — SPARQL. Применяются в семантической паутине (Semantic Web), онтологиях, системах связанных данных. Примеры: GraphDB, Virtuoso.

Event СУБД хранит поток событий-изменений, а не текущее состояние объектов. Полная история — основа для аудита и расследований. Пример: EventStoreDB.

Контентные базы данных работают с иерархическими репозиториями контента: документами, изображениями, медиафайлами. Пример: Apache Jackrabbit.

NewSQL и мультимодальные СУБД

NewSQL — класс СУБД, объединяющий SQL и ACID-гарантии реляционных баз с горизонтальным масштабированием NoSQL. Термин ввёл аналитик Мэтью Аслет из 451 Group в 2011 году.

В основе NewSQL — шардирование (автоматическое разбиение данных по узлам кластера) и алгоритмы распределённого консенсуса: Raft или Paxos. Это позволяет добавлять серверы без просадки производительности, сохраняя при этом транзакционные гарантии.

Применение: финансовые системы (FinTech), здравоохранение, высоконагруженные транзакционные сервисы, где нельзя жертвовать ни консистентностью, ни масштабом. Примеры: CockroachDB, YugabyteDB, TiDB, VoltDB.

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

Преимущество: один инструмент вместо трёх, меньше операционной сложности. Примеры: ArangoDB, SurrealDB, Tarantool, Microsoft Azure Cosmos DB.

Российские СУБД: обзор отечественных решений

С 2022 года в России реализуется курс на импортозамещение программного обеспечения: государственные организации переходят на отечественные СУБД из реестра российского ПО Минцифры.

Tarantool (лицензия BSD, разработчик — VK / Mail.ru Group) — гибридная СУБД: работает как key-value хранилище, документная и реляционная база одновременно. Данные хранятся в оперативной памяти с опциональной персистентностью на диск. Клиенты: Avito, крупные российские банки. Входит в семейство мультимодальных решений — архитектура позволяет выбирать модель данных под конкретный сервис.

YDB (Яндекс, Open Source с 2022 года) — NewSQL-система с реляционным интерфейсом и горизонтальным масштабированием. Поддерживает два режима: serverless (облако) и on-premise (локальная установка). Используется внутри Яндекса для продуктов с нагрузкой в миллиарды операций в сутки.

Postgres Pro — корпоративная версия PostgreSQL российской компании Postgres Professional. Включает патчи для совместимости с 1С, поддержку на русском языке, расширенный мониторинг и коммерческую поддержку. Внесена в реестр отечественного ПО.

Arenadata DB — MPP-аналитическая платформа (массово-параллельная обработка) на базе Greenplum. Ориентирована на OLAP-нагрузку и корпоративные большие данные.

Jatoba — PostgreSQL-совместимая СУБД с сертификатом ФСТЭК России. Применяется в государственных информационных системах и объектах критической инфраструктуры, где требуется документальное подтверждение уровня защищённости.

Резервное копирование баз данных: полное, инкрементальное, дифференциальное

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

Полное резервное копирование (full backup) — снимок всей базы данных целиком. Это основа стратегии: с него начинается восстановление при любом типе аварии. Инструменты: pg_dump (PostgreSQL), mysqldump (MySQL), mongodump (MongoDB). Недостаток — наибольший объём и время выполнения.

Инкрементальное резервное копирование — копирует только изменения с момента последнего любого бэкапа: полного или инкрементального. Минимальный объём каждого снимка, но при восстановлении нужно последовательно применить всю цепочку.

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

Репликация (master-slave, master-master) — синхронизация данных между несколькими серверами в реальном времени. Обеспечивает доступность, но не заменяет бэкап: ошибочно удалённые данные реплицируются мгновенно.

PITR (Point-in-time Recovery, восстановление на точный момент времени) — механизм PostgreSQL на основе WAL-журнала (Write-Ahead Log, журнал опережающей записи). Позволяет восстановить базу на любой момент до аварии с точностью до секунды.

Как выбрать тип базы данных под задачу

Единого правила нет: выбор зависит от структуры данных, характера нагрузки, команды и этапа разработки продукта.

Критерий 1: структура данных. Чёткая схема со сложными связями между сущностями — реляционные СУБД. Разнородные документы с переменным набором полей — документные базы. Данные — это прежде всего связи — графовые СУБД.

Критерий 2: характер нагрузки (OLTP или OLAP). Транзакционные операции с требованием целостности (банк, интернет-магазин) — реляционные с ACID. Аналитические агрегации по огромным таблицам — колоночные (ClickHouse, Cassandra). Быстрый кэш — key-value (Redis).

Критерий 3: глубина связей. Многоуровневые отношения между объектами — графовые СУБД ускоряют обход в разы по сравнению с JOIN в реляционных базах.

Критерий 4: масштаб. Вертикальное масштабирование (более мощный сервер) подходит реляционным СУБД. Горизонтальное (больше серверов) — NoSQL и NewSQL. Если кластер уже запланирован — Cassandra, CockroachDB или YugabyteDB.

Критерий 5: специализированные требования. Метрики и мониторинг → InfluxDB или Prometheus. Семантический поиск и ML/AI → векторные (Qdrant, Milvus). Геоданные → PostGIS. Полнотекстовый поиск → Elasticsearch.

Типичные архитектурные сочетания:

• E-commerce: PostgreSQL (основная БД) + Redis (кэш и сессии) + Elasticsearch (поиск по товарам).
• Мониторинг: InfluxDB или Prometheus (метрики) + Grafana (визуализация).
• Социальная сеть: Neo4j или NebulaGraph (граф связей) + MongoDB (профили и посты).
• FinTech с highload: CockroachDB или YugabyteDB (транзакции с горизонтальным масштабированием).

Практический совет для стартапа: начинайте с PostgreSQL — он закроет 80% задач. При росте нагрузки добавляйте специализированные СУБД под конкретные узкие места: Redis для кэша, Elasticsearch для поиска, InfluxDB для мониторинга.

Хотите разобраться в базах данных на практике — проектировать схемы, работать с SQL и аналитическими инструментами? В рамках федерального проекта «Активные меры содействия занятости» можно пройти обучение бесплатно — за счёт государства. Смотрите каталог доступных программ и выбирайте направление, которое подходит вашим задачам.

Часто задаваемые вопросы

Какие основные виды баз данных существуют?

Реляционные (PostgreSQL, MySQL), документные (MongoDB), ключ-значение (Redis), графовые (Neo4j), колоночные (Cassandra, ClickHouse), временны́х рядов (InfluxDB), векторные (Pinecone, Qdrant), поисковые (Elasticsearch), NewSQL (CockroachDB) и мультимодальные (ArangoDB). Выбор определяется структурой данных и характером задачи.

В чём разница между реляционными и нереляционными базами данных?

Реляционные: жёсткая схема, SQL, ACID-гарантии, вертикальное масштабирование. Нереляционные (NoSQL): гибкая схема, горизонтальное масштабирование, компромисс по консистентности согласно CAP-теореме. Реляционные — для транзакций со строгими требованиями к целостности; NoSQL — для высоких нагрузок и разнородных данных.

Что такое нормализация базы данных?

Нормализация — устранение избыточности данных через разбиение на связанные таблицы. Нормальные формы: 1НФ (атомарные значения), 2НФ (полная зависимость от ключа), 3НФ (нет транзитивных зависимостей), БКНФ. Повышает целостность данных и снижает объём хранения.

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

Когда данные — это прежде всего связи: антифрод в финансах, социальные графы, рекомендательные системы, граф знаний. Обход рёбер в Neo4j или JanusGraph быстрее многоуровневых JOIN в реляционных базах данных.

Что такое CAP-теорема и как она влияет на выбор NoSQL?

Распределённая система не может одновременно гарантировать Consistency (согласованность), Availability (доступность) и Partition Tolerance (устойчивость к разделению сети) — только два из трёх. MongoDB выбирает CP, Cassandra — AP. Это объясняет поведение NoSQL-систем при сетевых сбоях и отказах узлов.

Какие виды резервного копирования баз данных существуют?

Три основных: полное (вся БД, основа восстановления), инкрементальное (изменения с последнего любого бэкапа, минимальный объём), дифференциальное (изменения с последнего полного, быстрее восстанавливается). Дополнительно — репликация и PITR через WAL-журнал для восстановления на точный момент.

Что такое векторная база данных?

СУБД для хранения числовых эмбеддингов нейросетей. Используется в ML/AI: семантический поиск, рекомендации, распознавание образов. Основные примеры: Pinecone, Milvus, Qdrant, Weaviate. Самый быстрорастущий класс СУБД в 2024–2026 годах.

Что такое NewSQL и чем он отличается от NoSQL?

NewSQL совмещает горизонтальное масштабирование NoSQL с ACID-гарантиями реляционных баз через шардирование и алгоритмы консенсуса (Raft, Paxos). Применяется в FinTech и высоконагруженных транзакционных системах. Примеры: CockroachDB, YugabyteDB, TiDB.

Какие российские базы данных существуют?

Tarantool (VK/Mail.ru, BSD-лицензия), YDB (Яндекс, Open Source, NewSQL), Postgres Pro (корпоративный PostgreSQL), Arenadata DB (аналитика на базе Greenplum), Jatoba (PostgreSQL + сертификат ФСТЭК для государственного сектора).

Чем отличаются виды связей в реляционных базах данных?

Три вида: 1:1 (пользователь → паспорт, ограничение UNIQUE на внешнем ключе), 1:N (клиент → заказы, самый распространённый), M:N (студент ↔ курс, реализуется через промежуточную таблицу-связку). Все связи реализуются через FOREIGN KEY с REFERENCES.