Предсказание, с которым никто не согласен

Предсказание, с которым никто не согласен

Моё утверждение: выбирать базу данных под задачу — контрпродуктивно. Большинство разработчиков тратит недели на сравнение PostgreSQL vs MongoDB vs Redis, а потом тащит эту базу через весь проект, пока она не становится узким местом.

Вся эта возня с выбором «правильной» базы — это в 90% случаев преждевременная оптимизация. Потому что через полгода требования изменятся, и выбранная вами «идеальная» база данных окажется не той.

Анти-гайд: чего НЕ надо делать

1. Не выбирайте базу данных на старте проекта

Я видела, как команды месяцами выбирали между PostgreSQL и MySQL. Месяцы! На пустом проекте без единого реального запроса. Это аналогично тому, как если бы вы выбирали марку грузовика для перевозки одного чемодана.

Что происходит на практике: стартап выбирает MongoDB, потому что «гибкость схемы». Через год у них 50 миллионов документов, и они пишут пайплайны агрегации, которые работают по 30 секунд. А PostgreSQL с JSONB сделал бы то же самое быстрее.

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

2. Не стройте архитектуру вокруг одной базы данных

Классическая ошибка: «У нас Postgres, значит всё — пользователи, заказы, аналитика — в Postgres». Это как пытаться забить все гвозди одним молотком, включая винты.

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

Реальный пример: один мой знакомый разработчик хранил сессии пользователей в той же PostgreSQL, что и основные данные. Когда сессий стало 10 миллионов, каждый запрос на авторизацию начал конкурировать за ресурсы с аналитическими запросами. Перенос сессий в Redis решил проблему за день.

3. Не игнорируйте денормализацию

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

Представьте: у вас интернет-магазин. Запрос «показать заказ со всеми товарами, их ценами и статусами» в нормализованной схеме требует четырёх JOINов. В денормализованной — одного SELECT. На 1000 запросов в секунду разница колоссальная.

Когда денормализация оправдана:

• Данные читаются в 10 раз чаще, чем пишутся
• Вам нужна консистентность только «достаточно свежая», а не строгая
• Вы готовы обновлять дубликаты при изменении основной записи

4. Не доверяйте «вечному» хранению

Самая опасная иллюзия: «мы однажды загрузим данные, и они будут храниться вечно». В реальности данные устаревают, бизнес-требования меняются, а юридические требования требуют удаления.

Проектируйте схему так, чтобы у данных был TTL (time to live). Время жизни записи в кэше, время хранения сессии, срок актуальности статистики. Это не «удаление данных» — это управление жизненным циклом.

Что делать вместо этого

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

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

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

Вот моё предсказание: через два года большинство «экспертов» согласятся, что выбор базы данных на старте — это меньшая из проблем. Но пока они спорят о PostgreSQL vs MongoDB, кто-то уже запустился и собрал первых клиентов.