Урок 1.2: Разные типы баз данных

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

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

Почему существуют разные типы баз данных?

Ни одна модель базы данных не является идеальной для всех приложений.

Например:

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

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

Основные типы баз данных: краткий обзор

Вот краткое сравнение перед тем, как мы рассмотрим каждый тип подробнее:

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

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

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

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

1. Структурированная схема

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

Это делает структуру предсказуемой и более удобной для проверки.

2. Связи между таблицами

Одной из главных сильных сторон реляционных систем является возможность явно моделировать связи.

Например:

• Таблица customers может быть связана с таблицей orders.
• Таблица orders может быть связана с таблицей order_items.

Это делает реляционные базы данных особенно подходящими для бизнес-систем, где сущности взаимосвязаны.

3. Поддержка SQL

Реляционные базы данных обычно запрашиваются с помощью SQL (Structured Query Language). SQL предоставляет стандартный способ фильтрации, соединения, агрегации, сортировки и изменения структурированных данных.

4. Транзакции ACID

Реляционные базы данных хорошо известны поддержкой свойств ACID:

• Атомарность: Транзакция либо полностью выполняется, либо полностью завершается неудачей.
• Согласованность: Данные должны оставаться корректными в соответствии с заданными правилами.
• Изолированность: Параллельные транзакции не должны некорректно влиять друг на друга.
• Долговечность: После фиксации данные сохраняются даже после сбоев.

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

5. Ограничения целостности данных

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

• первичные ключи
• внешние ключи
• ограничения уникальности
• ограничения NOT NULL
• ограничения CHECK

Эти возможности помогают предотвращать появление некорректных или несогласованных данных.

6. Мощные соединения и отчетность

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

7. Нормализация и снижение избыточности

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

Например, информация о клиенте может храниться один раз в таблице customers, а не повторяться в каждой записи заказа.

Типичные сценарии использования реляционных баз данных

Реляционные базы данных обычно являются лучшим выбором, когда:

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

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

• PostgreSQL: Мощная реляционная база данных с открытым исходным кодом, поддерживающая стандарты и расширенные возможности.
• MySQL: Популярная реляционная база данных, широко используемая в веб-приложениях.
• MariaDB: Развиваемый сообществом форк MySQL.
• SQLite: Легковесная встроенная реляционная база данных, хранящаяся в одном файле.
• Oracle Database: Реляционная база данных корпоративного уровня.
• Microsoft SQL Server: Реляционная база данных, широко используемая в корпоративной среде.

Базы данных типа ключ-значение

Базы данных типа ключ-значение хранят данные как простую пару: ключ и связанное с ним значение.

Ключ выступает в роли уникального идентификатора, а база данных извлекает значение непосредственно по этому ключу. Эта модель очень проста и очень быстра.

Ключевые различия

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

Типичные сценарии использования

• кэширование результатов запросов
• хранение пользовательских сессий
• корзины покупок
• feature flags
• ограничение скорости запросов
• таблицы лидеров и счетчики

Примеры

• Redis
• Amazon DynamoDB
• Riak

Документные базы данных

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

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

Ключевые различия

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

Типичные сценарии использования

• системы управления контентом
• товарные каталоги
• профили пользователей
• мобильные и веб-приложения
• прототипирование систем с меняющимися требованиями

Примеры

• MongoDB
• Couchbase
• Google Firestore

Широкостолбцовые базы данных

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

Ключевые различия

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

Типичные сценарии использования

• журналирование событий
• телеметрия IoT
• системы обмена сообщениями
• приложения с интенсивной записью
• географически распределенные системы

Примеры

• Apache Cassandra
• Apache HBase
• ScyllaDB

Колоночные аналитические базы данных

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

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

Ключевые различия

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

Типичные сценарии использования

• business intelligence
• панели мониторинга
• хранилища данных
• аналитическая отчетность
• анализ логов в большом масштабе

Примеры

• ClickHouse
• DuckDB
• Amazon Redshift
• Google BigQuery

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

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

Ключевые различия

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

Типичные сценарии использования

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

Примеры

• Neo4j
• Amazon Neptune
• ArangoDB

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

Базы данных временных рядов специализированы на точках данных, связанных со временем. Они оптимизированы для высокой скорости загрузки, политик хранения, сжатия и агрегации по времени.

Ключевые различия

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

Типичные сценарии использования

• мониторинг серверов
• метрики приложений
• данные датчиков
• биржевые данные
• промышленные измерения

Примеры

• InfluxDB
• TimescaleDB
• OpenTSDB

Базы данных в памяти

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

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

Типичные сценарии использования

• кэширование
• хранение сессий
• счетчики в реальном времени
• игровые таблицы лидеров
• системы со сверхнизкой задержкой

Примеры

• Redis
• Memcached
• SAP HANA

Как выбрать подходящий тип базы данных

При выборе базы данных полезно задавать себе такие вопросы:

• Данные строго структурированы или гибкие?
• Нужны ли мне строгие ACID-транзакции?
• Буду ли я выполнять сложные соединения?
• Является ли быстрый поиск по ключу с низкой задержкой главным приоритетом?
• Нагрузка транзакционная или аналитическая?
• Будет ли система масштабироваться на множество серверов?
• Являются ли связи между сущностями центральной частью приложения?

Во многих реальных системах организации используют более одного типа базы данных. Например:

• реляционную базу данных для основных бизнес-данных
• Redis для кэширования
• документную базу данных для гибкого контента
• колоночное хранилище для аналитики

Такой подход часто называют polyglot persistence — полиглотной персистентностью.

Краткое резюме ключевых различий

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

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

Основные выводы из этого урока

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

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