Коротко. Компания выбрала базу данных за неделю до старта разработки, по совету одного инженера. Через два года выяснилось, что отчёты на ней строить нельзя, а перенос стоит как половина проекта. Выбор хранилища — самое дорогое в отмене архитектурное решение, и принимается оно чаще всего быстрее всех остальных.
Четыре вопроса до выбора
- Что происходит чаще: запись или чтение, и в какой пропорции?
- Нужны ли гарантии, что деньги не спишутся дважды при сбое?
- Кто будет строить отчёты и на каких данных?
- Что делаем, когда объём вырастет в десять раз?
Третий вопрос забывают чаще всего — и именно он через год превращается в отдельный проект по построению аналитического контура.
Типы хранилищ и их место
| Тип | Для чего | Где ломается |
|---|---|---|
| Реляционная база | Основная система учёта, деньги, связи между сущностями | Тяжёлая аналитика на боевой базе |
| Аналитическое хранилище | Отчёты и агрегаты по большим объёмам | Не годится для оперативных операций |
| Документная база | Гибкая структура, быстрый старт | Связи и согласованность приходится держать в коде |
| Ключ-значение и кэш | Быстрый доступ к горячим данным | Не источник истины, данные теряются |
| Очередь сообщений | Развязка систем, всплески нагрузки | Порядок и повторы требуют отдельной дисциплины |
| Поиск | Полнотекстовый поиск и подсказки | Индекс приходится синхронизировать с основной базой |
Практика: большинству компаний нужны первые две, третья — по обстоятельствам. Остальные добавляются под конкретную боль, а не «чтобы было».
Маршрут
| Ступень | Что читаем | Что забираем | Срок |
|---|---|---|---|
| 1. Язык запросов | «PostgreSQL. SQL + PL/pgSQL», «Оконные функции SQL» | Умение достать цифру самому | 3 недели |
| 2. Ошибки проектирования | «Антипаттерны SQL» | Почему в базе три версии одного клиента | 1 неделя |
| 3. Основы | «Базы данных», «Postgres 17. Первое знакомство» | Транзакции, блокировки, индексы | 3 недели |
| 4. Аналитический контур | «Хранилища данных» | Разделение оперативного и аналитического | 3 недели |
| 5. Потоки и масштаб | «Потоковые базы данных», «Apache Kafka», «Большие данные» | Когда суточной выгрузки уже мало | 4 недели |
| 6. Защита | «Защита данных: от авторизации до аудита» | Права, журналы, подготовка к проверке | 2 недели |
Шесть выводов — своими словами
- Реляционная база подходит дольше, чем кажется. Отказ от неё «ради масштаба» на объёмах средней компании почти всегда преждевременный.
- Аналитика на боевой базе — временное решение. Оно живёт ровно до момента, когда отчёт начинает мешать работе пользователей.
- Гибкая схема не означает отсутствие схемы. Она просто переезжает из базы в код, где её никто не контролирует.
- Резервная копия без проверенного восстановления не существует. Проверяется по расписанию и с секундомером.
- Миграция схемы — это релиз. Её планируют, откатывают и репетируют так же, как выпуск кода.
- Зоопарк хранилищ дорог не лицензиями, а людьми. Каждый новый тип требует компетенции, дежурства и мониторинга.
Красные флаги
- Выбор обоснован модой или опытом одного разработчика, а не характером нагрузки.
- Нет ответа на вопрос, где будут строиться отчёты.
- В проекте четыре разных хранилища при команде из пяти человек.
- Восстановление из копии ни разу не проверялось на реальном объёме.
Частые вопросы
Связанное
Книги названы как источники. KZSalesHub не распространяет файлы изданий.
Выбор базы определяется характером данных и запросов, а не популярностью. Ошибка на этом уровне исправляется миграцией, а миграция — это отдельный проект со своим бюджетом.
Материал обновлён 30 сентября 2026