Хранение информации в базе данных: пошаговое руководство

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

Проблема в том, что разработчики часто выбирают тип хранилища по аналогии с предыдущим проектом, а не по спецификации задачи. Реляционная модель по умолчанию, NoSQL потому что «тренд», кэш вместо базы — каждый из этих шагов имеет конкретные архитектурные последствия. Поэтому проектирование базы данных начинается не с вопроса о популярности PostgreSQL, MongoDB или Redis, а с анализа того, какие данные появляются в системе, как они связаны и каким образом приложение будет к ним обращаться.

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

Три уровня абстракции при проектировании базы данных

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

Концептуальное проектирование

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

Вопросы этого уровня звучат не как SQL-запросы:

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

Результатом часто становится ER-модель — схема сущностей, атрибутов и связей. Она помогает обнаружить логические противоречия до того, как они превратятся в таблицы и миграции. Например, связь «заказ — товар» обычно оказывается не прямой, а требующей промежуточной сущности: в ней нужно хранить количество товара, цену на момент покупки и, возможно, скидку. Если сразу рисовать только две таблицы, эти данные легко потерять или начать дублировать.

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

Логическое проектирование

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

Здесь определяют:

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

Жёсткая схема не означает, что каждый столбец обязан быть заполнен. В SQL значение NULL обычно разрешено, если для столбца явно не задано ограничение NOT NULL. При этом NULL — не пустая строка и не ноль, а специальное состояние «значение неизвестно или отсутствует». Это различие влияет на сравнения, сортировку, агрегатные функции и условия в запросах. Поэтому вопрос должен звучать не «разрешены ли пустые значения вообще», а «может ли именно этот атрибут быть неизвестен или неприменим и как приложение должно это обрабатывать».

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

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

Физическое проектирование

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

У одной и той же логической модели физическая реализация может выглядеть по-разному. В MySQL выбор между InnoDB и устаревшими сценариями использования MyISAM влияет на транзакции, блокировки и восстановление. В Microsoft SQL Server кластерные и некластерные индексы решают разные задачи. В PostgreSQL важны типы индексов, особенности MVCC, планы выполнения и работа вакуумирования. В распределённой NoSQL-СУБД критическими становятся ключ партиционирования, репликация и допустимая локальность данных.

Физическое проектирование включает и инфраструктурные решения:

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

Концептуальная модель отвечает на вопрос, что существует в системе. Физическая — как именно эти данные будут записываться, читаться, реплицироваться и восстанавливаться.

На практике три уровня часто схлопываются в один «проектировочный спринт», где архитектор одновременно рисует ER-диаграмму, выбирает движок и пишет первые миграции. Такой подход допустим для небольшого прототипа, но опасен для системы с долгим сроком жизни. Схема, которая работает на тестовых данных, ещё ничего не говорит о поведении при росте числа записей, конкурирующих транзакциях и восстановлении после отказа.

Реляционные СУБД: таблицы, ограничения и гарантии ACID

Реляционные базы данных организуют информацию в таблицах, состоящих из строк и столбцов. Данные описываются схемой, а доступ к ним обычно выполняется через SQL. Структура таблицы заранее определяет типы столбцов и ограничения, но это не означает, что все поля без исключения должны быть заполнены: допускаемость NULL задаётся для каждого столбца отдельно.

Целостность реляционной базы поддерживается несколькими механизмами. Первичный ключ однозначно идентифицирует строку. Внешний ключ связывает запись с объектом в другой таблице. Ограничение UNIQUE не позволяет создавать дубликаты в заданном контексте, а CHECK ограничивает допустимые значения. Эти правила переносят часть бизнес-логики из прикладного кода в саму базу. В результате разные сервисы, подключённые к одному хранилищу, не смогут записать заведомо некорректное состояние, если оно запрещено схемой.

Главное архитектурное преимущество реляционной модели — поддержка транзакций и свойств ACID:

• Atomicity, атомарность. Транзакция выполняется целиком или откатывается. Если операция включает несколько изменений и одно из них завершается ошибкой, база может отменить весь набор.
• Consistency, согласованность. После завершения транзакции должны сохраняться ограничения и правила целостности, заданные схемой и логикой системы. Это не обещание, что сама СУБД поймёт любой бизнес-инвариант: часть правил разработчик обязан явно выразить в ограничениях или коде.
• Isolation, изолированность. Параллельные операции не должны неконтролируемо ломать друг друга. Конкретный уровень изоляции определяет, какие изменения одна транзакция может увидеть относительно другой.
• Durability, долговечность. После подтверждения транзакции СУБД сохраняет её результат в соответствии с настройками надёжности. Обычно для этого используются журналирование, запись на устойчивое хранилище и механизмы восстановления.

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

Упрощённо уровни можно представить так:

1. Read Uncommitted допускает чтение ещё не зафиксированных изменений. Такой режим встречается редко и требует осторожного применения.

2. Read Committed не показывает незакоммиченные данные, но повторное чтение той же строки в рамках одной транзакции может дать другой результат после фиксации параллельной операции.

3. Repeatable Read обеспечивает более стабильное повторное чтение, однако детали поведения различаются между СУБД. Например, важны MVCC, блокировки и обработка фантомных строк.

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

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

ACID — это не обещание одинакового поведения любой транзакции при любой настройке. Это набор свойств, конкретная реализация которых зависит от СУБД, режима изоляции и параметров надёжности.

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

Цена этой выразительности — сложность схемы и стоимость некоторых операций. Индексы ускоряют чтение, но занимают место и замедляют запись. Внешние ключи защищают целостность, но добавляют проверки. Транзакции и журналирование требуют ресурсов. Поэтому производительность нельзя оценивать по ярлыку «SQL медленный» или «NoSQL быстрый»: результат определяется запросами, объёмом данных, индексами, настройками, оборудованием и способом распределения нагрузки.

Эволюция NoSQL: от идеи Карло Строззи к гибким моделям

Термин NoSQL впервые использовал Карло Строззи в 1998 году для обозначения открытой реляционной базы данных без SQL-интерфейса. Это значение заметно отличалось от современного: речь шла не об отказе от реляционной модели как таковой. Позднее обозначение стали связывать с более широким классом систем, которые предлагали альтернативные SQL-подходы к хранению, масштабированию и запросам. Распространилась и расшифровка «Not Only SQL», подчёркивающая, что SQL не обязан быть единственным способом работы с данными.

Современные NoSQL-хранилища не образуют единую технологическую категорию. MongoDB, Redis, Cassandra, DynamoDB и Neo4j решают разные задачи, используют разные модели данных и предъявляют разные требования к проектированию. Общее у них — отказ от предположения, что универсальная реляционная схема подходит для любой нагрузки.

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

Многие распределённые NoSQL-системы описывают через модель BASE:

• Basically Available, базовая доступность. Архитектура стремится отвечать на запросы даже при части отказов, но конкретные гарантии зависят от продукта, настройки кворума, типа операции и состояния кластера.
• Soft state, мягкое состояние. Состояние реплик может меняться в процессе фоновой синхронизации, даже если в конкретный момент не поступают новые пользовательские запросы.
• Eventual consistency, согласованность в конечном счёте. Если обновления прекращаются и система продолжает обмениваться данными, реплики со временем могут прийти к одному состоянию. Точный момент этого перехода обычно не является универсально гарантированным.

BASE — не синоним «данные всегда устаревшие», а описание возможного компромисса между доступностью, задержкой, масштабированием и строгостью согласованности. Многие современные NoSQL-продукты поддерживают более одного режима чтения и записи. Например, можно выбирать требования к подтверждению записи или читать только после определённого уровня репликации. Поэтому классифицировать всю систему одним словом без учёта конкретной операции некорректно.

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

ACID и BASE: не соревнование продуктов, а выбор компромисса

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

Сравнивать нужно не названия технологий, а профиль нагрузки:

• какие операции преобладают — чтение, запись, обновление или удаление;
• нужны ли точечные запросы, диапазоны, полнотекстовый поиск, агрегации;
• сколько сущностей изменяется в одной бизнес-операции;
• допустимы ли повторное чтение с другим результатом и задержка репликации;
• каким будет размер партиции и как распределятся ключи;
• что произойдёт при недоступности узла или сетевом разделении.

Формулировка «реляционная база выбирает CP, а Cassandra и DynamoDB — AP» слишком груба для инженерного решения. CAP описывает поведение распределённой системы при сетевом разделении, а не выдаёт постоянную характеристику всему продукту. В реальной эксплуатации значение имеют режимы чтения и записи, кворумы, политика конфликтов, топология репликации и требования конкретной операции. Реляционная СУБД в одном экземпляре вообще не является тем же архитектурным объектом, что распределённый кластер с несколькими регионами.

CAP-теорема говорит о невозможности одновременно гарантировать согласованность, доступность и устойчивость к разделению сети в одном и том же смысле при наличии partition. Поскольку устойчивость к разделению для распределённой системы обычно не выбирают, на практике обсуждают компромисс между доступностью и согласованностью во время отказа связи. Но это не означает, что у любой AP-системы все ответы устаревшие, а у любой CP-системы запросы всегда блокируются. Сценарий определяется настройками и характером операции.

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

Четыре типа нереляционных хранилищ

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

Документные хранилища

В документной модели данные представлены документами, обычно в формате JSON-подобной структуры. Документ может содержать вложенные объекты и массивы, а разные документы одной коллекции не обязаны иметь полностью одинаковый набор полей. Такой подход удобен для профилей пользователей, каталогов товаров с неодинаковыми атрибутами, контента CMS и объектов, которые чаще читаются целиком, чем собираются из множества независимых таблиц.

MongoDB поддерживает фильтрацию по вложенным полям, индексы, агрегации и различные варианты соединения данных. Поэтому утверждение об «отсутствии нативных JOIN» для MongoDB неверно. Операция $lookup позволяет выполнять соединение между коллекциями в рамках конвейера агрегации. При этом $lookup не превращает MongoDB в реляционную СУБД: стоимость операции, требования к индексам, объём передаваемых данных и влияние на распределённый кластер нужно оценивать отдельно.

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

Хранилища ключ-значение

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

Но не все системы ключ-значение одинаково ограничены. Для Amazon DynamoDB корректнее говорить о таблицах элементов и ключах, а не о простом доступе «только ключ → значение». DynamoDB поддерживает операции GetItem для точечного чтения, Query для выборки по ключу раздела с условиями по ключу сортировки, а также Scan для просмотра элементов с последующей фильтрацией. Кроме того, сервис поддерживает вторичные индексы — глобальные и локальные, — которые позволяют строить дополнительные паттерны доступа. Эти возможности не отменяют необходимости проектировать ключи заранее: неудачный ключ раздела может привести к горячим партициям, неравномерной нагрузке или дорогим сканированиям.

У Redis также есть средства поиска по структурам и дополнительные модули, но использовать его как универсальную реляционную базу обычно не стоит. Значение key-value-модели раскрывается там, где запросы заранее известны и сводятся к быстрым операциям над ключом или ограниченным набором структур.

Нельзя универсально обещать «наносекунды на чтение из памяти». Даже если данные находятся в оперативной памяти, итоговая задержка зависит от сетевого обмена, сериализации, очереди на сервере, конкуренции за ресурсы, клиента и топологии. Локальная операция в памяти и запрос к удалённому экземпляру Redis — это разные измерения. В архитектуре важны не рекламные единицы времени, а измерения полного пути от приложения до хранилища на реальной нагрузке.

Wide-column и column-family-хранилища

Apache Cassandra, HBase и ScyllaDB относятся к wide-column, или column-family, хранилищам. Их нельзя без оговорок описывать как классические колоночные СУБД, где значения одного столбца физически хранятся рядом для аналитического сканирования. В wide-column-системах модель строится вокруг строк, партиций, ключей и семейств столбцов, а физическая организация и поведение чтения зависят от конкретного продукта.

Такие хранилища позволяют строкам иметь разный набор столбцов и рассчитаны на распределённые нагрузки. Ключевым становится не абстрактная «таблица», а схема доступа: как формируется partition key, какие записи попадают в одну партицию, нужен ли clustering key и какие диапазоны будут читаться вместе. В Cassandra запросы проектируют от будущих операций. Нормализовать данные по реляционным правилам, а затем рассчитывать на произвольные JOIN обычно нельзя: модель должна заранее поддерживать нужные выборки.

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

Классические колоночные аналитические СУБД решают другую задачу. Они оптимизируют чтение отдельных столбцов из больших наборов строк, агрегации и сканирование объёмов данных. Wide-column и columnar — близкие по названию, но разные архитектурные категории. Смешивать их в одном описании значит дать читателю неверную модель работы системы.

Графовые хранилища

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

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

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

Как превратить выбор СУБД в инженерное решение

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

Минимальный набор вопросов выглядит так:

1. Как приложение обращается к данным? Нужны точечные чтения, диапазонные выборки, поиск по вложенным атрибутам, агрегации, обход связей или потоковая обработка?

2. Какие операции должны быть атомарными? Если изменение затрагивает баланс, заказ и резерв товара, необходимо определить, должны ли эти действия подтверждаться одной транзакцией.

3. Допустима ли устаревшая реплика? Для ленты новостей это может быть приемлемо, а для разрешения доступа или финансового остатка — нет.

4. Как распределяется нагрузка? Важно знать не только среднее число запросов, но и пики, размер объектов, долю повторяющихся ключей и вероятность горячих партиций.

5. Как система переживает отказ? Нужно заранее определить RPO — Recovery Point Objective, допустимую потерю данных по времени, — и RTO — Recovery Time Objective, целевое время восстановления сервиса.

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

7. Как устроено восстановление? Репликация не заменяет резервную копию: ошибка приложения или удаление данных может распространиться на реплики так же быстро, как и корректная запись.

8. Есть ли у команды опыт эксплуатации? Документация, мониторинг, инструменты миграции и навыки восстановления иногда важнее разницы в синтетическом бенчмарке.

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

Для части систем разумна полиглотная персистентность — использование нескольких хранилищ с разными ролями. Транзакционная реляционная база может оставаться источником истины, Redis — обслуживать кэш, поисковый движок — отвечать за полнотекстовые запросы, а wide-column-хранилище — принимать поток событий. Но такая архитектура не бесплатна. Появляются CDC, повторная доставка событий, дедупликация, мониторинг рассинхронизации и правила восстановления. Второе хранилище нельзя добавлять только ради красивой диаграммы: у него должна быть ясная нагрузка и понятный источник данных.

Финальная логика проектирования

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

Реляционная СУБД подходит не только для «старых» систем и не становится узким местом автоматически. Она остаётся сильным выбором, когда важны связи, ограничения, транзакции и сложные запросы. NoSQL не означает отсутствие структуры: в документных, key-value, wide-column и графовых системах структура просто проектируется вокруг других способов доступа.

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