Данные переживают код

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

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

База отвечает на два вопроса

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

Любое хранилище определяется двумя вещами. Первая — модель данных (data model): как оно придаёт данным форму — жёсткие таблицы, гибкие документы, граф связей. Вторая — гарантии (guarantees): строгая корректность или скорость и доступность с более слабыми обещаниями. Почти любой выбор базы — это разный ответ на эти два вопроса, и остальной курс — это меню.

Access pattern — выбирай по тому, как читаешь и пишешь

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

Лучшей базы не бывает. Хранилище, идеальное под быстрые поиски по ключу, плохо для глубоких запросов по связям; построенное под огромные записи плохо для строгих банковских транзакций. Правильный вопрос — твой паттерн доступа (access pattern): что ты читаешь, что пишешь, как часто и как это должно вести себя, когда что-то идёт не так.

Карта: 20 понятий в шести группах

Карта метро: сначала видишь линии целиком, потом едешь по станциям.

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

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

Relational Database — таблицы, строки и связи

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

Это понятие реляционная база данных (relational database). Она хранит данные в таблицах (tables) с фиксированной схемой (schema) и связывает таблицы по ссылке — строка заказа держит id своего клиента. Такая ссылка называется внешний ключ (foreign key). Схема — это обещание о форме: у каждого заказа есть нужные колонки, проверенные на входе. Структура заранее в обмен на здравомыслие потом.

SQL — проси что хочешь, а не как достать

Ты говоришь библиотекарю «все романы французских авторов, изданные после 1950-го, по году» — и он сам соображает, как их найти. Ты описываешь результат, а не поиск.

SQL (Structured Query Language) — это декларативный язык запросов (declarative query language): ты заявляешь нужный ответ, а база сама строит план, как его достать, включая соединение таблиц (JOIN). Этот план строит планировщик запросов (query planner). SELECT ... JOIN ... WHERE ... может ответить на вопросы, которых ты не предвидел при проектировании, — одна из тихих суперсил реляционной модели.

Transactions — всё или ничего

Денежный перевод — это две записи: минус здесь, плюс там, — но одно намерение. Либо обе случились, либо ни одна; наполовину сделанный перевод — катастрофа.

Это понятие транзакция (transaction): группа изменений, которая либо целиком фиксируется (commit), либо целиком откатывается (rollback), изолированно от других, и переживает падение, как только подтверждена. Набор этих обещаний называют ACID (подробно — в главе 5). Поэтому банки, заказы и склад живут в SQL — когда корректность важнее голой скорости, тебе нужно именно это обещание.

Почему это правильный дефолт

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

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

Document Store — по JSON-документу на сущность

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

Это документное хранилище (document store). Оно хранит записи как гибкие JSON-подобные документы, вложенные и почти бессхемные (schema-less), так что две записи в одной коллекции (collection) могут различаться. Хорошо, когда формы разнятся или быстро меняются, и целая сущность — товар, профиль — живёт как один документ, который ты достаёшь за одно чтение.

Key-Value Store — гигантская хеш-таблица

Гардероб — отдаёшь номерок, получаешь ровно своё пальто. Никаких поисков, никаких вопросов, мгновенно.

Это хранилище ключ-значение (key-value store) — простейшая форма: ключ на входе, значение на выходе, ослепительно быстро. Идеально для кэша, сессий, счётчиков ограничения запросов (rate limit) и всего, что ты достаёшь по известному id.

Wide-Column Store — под огромные потоки записей

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

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

Graph Database — когда суть в связях

Доска детектива — фото, соединённые нитями. Ценность не в отдельном фото, а в паутине того, кто с кем связан.

Это графовая база данных (graph database). Она моделирует данные как узлы (nodes) и рёбра (edges) между ними, делая запросы по связям — «друзья друзей, которым это нравится», «путь между этими двумя аккаунтами» — естественными и быстрыми там, где SQL понадобились бы болезненные многосторонние соединения. Тянись за этим, когда связи важнее самих записей.

Time-Series Database — данные со штампом времени

Лента кардиомонитора — бесконечная полоса показаний, каждое привязано к моменту, и ты почти всегда спрашиваешь «что было между этими двумя временами?»

Это база временных рядов (time-series database). Она заточена под данные, которые приходят по порядку времени и запрашиваются по времени — метрики, показания датчиков, цены. Принимает огромные потоки и быстро отвечает «среднее за минуту за прошлую неделю», со встроенным удалением старых данных (retention).

Search Engine — полный текст и релевантность

Строка поиска, которая прощает опечатки, ставит лучшие совпадения первыми и находит «running», когда ты набрал «run», — как библиотекарь, понимающий, что ты имел в виду.

Это поисковый движок (search engine). Он строит обратный индекс (inverted index) — «слово → документы» — ради быстрого полнотекстового поиска (full-text search) с ранжированием, нечётким совпадением и фильтрами — того, что LIKE '%word%' в SQL делает медленно и плохо. Обычно работает рядом с основной базой, держится в синхроне и питает строку поиска и разбор логов.

Vector Database — поиск по смыслу

Вместо совпадения точных слов ты спрашиваешь «найди то, что похоже на это» — и получаешь соседей по сходству, а не по ключевому слову.

Это векторная база данных (vector database). Она хранит embeddings — числовые отпечатки смысла — и находит ближайшие (nearest neighbours), так что ты ищешь по сходству, а не по точному тексту. Это движок под семантическим поиском (semantic search) и RAG, где AI-приложение достаёт самые релевантные куски, чтобы из них ответить.

Object Storage — куда кладут большие файлы

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

Это объектное хранилище (object storage). Оно не база данных, но именно туда кладут большие блобы (blobs) — картинки, видео, бэкапы, документы — адресуемые ключом (key) внутри бакета (bucket) и отдаваемые дёшево на масштабе. Паттерн почти универсален: файл — в объектном хранилище, а строку, указывающую на него, — в базе. Записи в БД, нагрузка в бакете.

ACID — пессимистично, корректно, осторожно

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

ACID — это строгое обещание реляционных баз о транзакциях: каждая транзакция оставляет данные корректными и полными или не происходит вовсе. Четыре буквы: Atomicity (всё или ничего), Consistency (правила данных всегда соблюдены), Isolation (параллельные транзакции не мешают друг другу), Durability (подтверждённое переживает падение). Для денег, заказов и всего, где неверное число недопустимо, это тот размен, что тебе нужен.

BASE — оптимистично, доступно, в итоге верно

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

Многие NoSQL-системы занимают противоположную позицию: BASE (Basically Available, Soft state, Eventually consistent). Они остаются быстрыми и доступными и принимают, что копии данных могут ненадолго расходиться, прежде чем сойтись. Это называется согласованность в конечном счёте (eventual consistency).

CAP Theorem — при обрыве сети выбирай

Команда, разрезанная упавшей телефонной линией: каждая половина может работать сама (но они разойдутся) или сложить инструменты до восстановления связи (но ты встаёшь). И то, и другое сразу — нельзя.

Теорема CAP (CAP theorem) говорит: когда сетевой раздел (network partition) разрезает машины твоей базы, ты должен выбрать Consistency (отказывать в записи, оставаться корректным) или Availability (продолжать обслуживать, рискуя расхождением) — оба сразу во время раздела невозможны. Любая распределённая база делает этот выбор. Знать, что выбирает твоё хранилище, — значит знать, как оно ведёт себя в худший день.

Index — предметный указатель для данных

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

Индекс (index) — это побочная структура, превращающая полный перебор таблицы (full table scan) в прямой поиск, самый большой рычаг скорости чтения. Подвох: каждый индекс стоит места и замедляет записи (каждая вставка должна обновить и его).

Replication — держи копии, переживай отказ

Документ, хранимый в трёх сейфах в трёх зданиях — если одно сгорит, другие всё равно держат его, и трое могут читать одновременно.

Репликация (replication) держит копии данных на нескольких машинах. Все записи идут в лидера (leader), а реплики (followers, replicas) получают копию и обслуживают чтения. Если лидер умирает, его место занимает реплика (failover). Подвох — лаг репликации (replication lag): реплика может отставать на миг, так что только что записанное значение может ещё не показаться на ней.

Sharding — дели, когда одной машины мало

Один переполненный картотечный шкаф становится A–M в одном шкафу и N–Z в другом. Больше места — но теперь надо знать, в каком шкафу живёт имя.

Когда данные или нагрузка на запись перерастают одну машину, шардинг (sharding) делит данные по многим — пользователи A–M здесь, N–Z там. Каждая часть называется шард (shard), а поле, по которому делим, — ключ шардирования (shard key). Это открывает почти безграничный масштаб, но ключ шардирования — тяжёлый, почти необратимый выбор: ошибёшься — получишь горячие точки (hotspots) или запросы, которым приходится бить по всем шардам.

Normalization / Denormalization — один факт в одном месте или копии ради скорости

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

Нормализация (normalization) держит каждый факт ровно в одном месте — чисто, без противоречий, реляционный дефолт. Денормализация (denormalization) намеренно дублирует данные, чтобы чтения были быстрее и требовали меньше соединений. Оба подхода годятся; правило — делать это осознанно и всегда знать, какая копия источник правды (source of truth), а какая просто быстрый дубль. (Тот же урок, что с кэшем.)

Polyglot Persistence — несколько хранилищ осознанно

На кухне есть холодильник, морозилка и кладовка — а не одна коробка, заставленная делать всё три. Каждая держит то, что ей подходит.

Это паттерн Polyglot persistence — «многоязычное хранение». Зрелые системы обычно используют несколько хранилищ: Postgres как источник правды, Redis для кэша и сессий, поисковый индекс для строки поиска, может быть, векторное хранилище для AI-фич и объектное хранилище для файлов. Каждое делает то, в чём хорошо. Дисциплина в том, чтобы ясно держать, какое из них хранит правду, а остальные — быстрые копии, держащиеся в синхроне.

Postgres First — начинай с Postgres, вырастай осознанно

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

Это практика Postgres first. Современный Postgres поразительно способен — реляционное ядро, JSON-документы, полнотекстовый поиск, векторы, даже рабочая очередь задач. Большинство продуктов должны начинать просто с Postgres и добавлять специализированное хранилище, только когда реальная, измеренная боль этого требует. Каждая лишняя база — это ещё одно, что надо эксплуатировать, бэкапить и держать согласованным. Самое дешёвое хранилище — то, которое ты не добавил.

Как всё связано

Карта района после прогулки: теперь видно, какие улицы куда ведут.

Понятия курса не живут поодиночке. Реляционная база — источник правды с гарантиями ACID; индекс ускоряет её чтения; поисковый движок и векторная база — копии, которые от неё питаются; в объектном хранилище лежат файлы, на которые указывают её строки. Когда одной машины мало, приходят репликация и шардинг — и вместе с ними выбор CAP. NoSQL-семейство часто выбирает BASE — противоположность ACID.