AnnaBright
New member
Когда в прошлом году мы запускали сервис с личными кабинетами, заказами и аналитикой, вопрос выбора базы данных казался мне решённым заранее. Все вокруг твердили, что схема будет меняться каждую неделю, поэтому MongoDB — это очевидный выбор для быстрого старта. Я повелся, и честно скажу: первые две недели я чувствовал себя гением.
Гибкая схема действительно дала скорость. Мы добавляли поля на лету, почти не писали миграции, и продукт рос буквально каждый день. Но очень быстро выяснилось, что за гибкость платишь не абстрактной архитектурой, а вполне конкретными багами. В документах появились заказы без обязательного поля, дубли, даты в трёх разных форматах — и всё это в одном и том же месте. Код приходилось защищать проверками везде, где только можно, и половина времени уходила не на фичи, а на разгребание чужих вольностей.
Следующий звонок прозвенел, когда бизнес попросил отчёт: сколько заказов за месяц по каждому городу с учётом скидок и возвратов. Я написал агрегацию, которая выглядела как отдельное произведение искусства и работала восемь секунд. Потом попросили добавить ещё пару условий — и она стала работать двадцать. Именно тогда я понял, что у нас не быстрое прототипирование, а полноценный продукт с кучей связанных сущностей и живыми деньгами.
Мы решили переехать на PostgreSQL. Признаюсь, я боялся, что снова начнётся ад и что скорость разработки упадёт. Ничего подобного не случилось. Ограничения на уровне схемы, внешние ключи и транзакции не замедлили нас — они убрали целый класс проблем. Часть того, что раньше было головной болью в коде, теперь просто нельзя было записать в базу. Оказалось, что дисциплина в схеме не мешает, а экономит силы.
Но я не хочу врать и делать вид, что MongoDB — плохая база. Она отлично работает там, где данные реально слабо связаны: логи, события, сырые ответы внешних сервисов, кэш, быстро меняющиеся структуры. Там, где документы живут сами по себе и не обязаны соответствовать строгой форме, она удобнее и легче. Проблема была не в ней, а во мне: я взял инструмент для одной задачи и попытался решить им прямо противоположную.
Что я советую читателям. Сначала посмотрите не на базу, а на свои данные. Если у вас много связанных сущностей, отчёты, оплаты, транзакции, аудит — берите реляционную базу без колебаний и не слушайте сказки про гибкость. Если у вас поток неструктурированных событий и слабая связность — документная база будет вам верным другом. И главное: не меняйте базу ради моды, меняйте её ради конкретной боли, которую чувствуете прямо сейчас.
И ещё одно наблюдение, которое стоило мне нескольких бессонных ночей. Самый дорогой технический долг — это не старый код, а неверно выбранная модель данных. Её потом очень тяжело и дорого менять, потому что она проросла во всю бизнес-логику и в головы команды. Так что выбор базы — это не спор в курилке, а решение с ценой на несколько лет вперёд. А какой опыт был у вас? Расскажите, начинали ли вы с документной базы и потом переезжали на реляционную, или наоборот, и что в итоге оказалось для вашей команды решающим аргументом?
Гибкая схема действительно дала скорость. Мы добавляли поля на лету, почти не писали миграции, и продукт рос буквально каждый день. Но очень быстро выяснилось, что за гибкость платишь не абстрактной архитектурой, а вполне конкретными багами. В документах появились заказы без обязательного поля, дубли, даты в трёх разных форматах — и всё это в одном и том же месте. Код приходилось защищать проверками везде, где только можно, и половина времени уходила не на фичи, а на разгребание чужих вольностей.
Следующий звонок прозвенел, когда бизнес попросил отчёт: сколько заказов за месяц по каждому городу с учётом скидок и возвратов. Я написал агрегацию, которая выглядела как отдельное произведение искусства и работала восемь секунд. Потом попросили добавить ещё пару условий — и она стала работать двадцать. Именно тогда я понял, что у нас не быстрое прототипирование, а полноценный продукт с кучей связанных сущностей и живыми деньгами.
Мы решили переехать на PostgreSQL. Признаюсь, я боялся, что снова начнётся ад и что скорость разработки упадёт. Ничего подобного не случилось. Ограничения на уровне схемы, внешние ключи и транзакции не замедлили нас — они убрали целый класс проблем. Часть того, что раньше было головной болью в коде, теперь просто нельзя было записать в базу. Оказалось, что дисциплина в схеме не мешает, а экономит силы.
Но я не хочу врать и делать вид, что MongoDB — плохая база. Она отлично работает там, где данные реально слабо связаны: логи, события, сырые ответы внешних сервисов, кэш, быстро меняющиеся структуры. Там, где документы живут сами по себе и не обязаны соответствовать строгой форме, она удобнее и легче. Проблема была не в ней, а во мне: я взял инструмент для одной задачи и попытался решить им прямо противоположную.
Что я советую читателям. Сначала посмотрите не на базу, а на свои данные. Если у вас много связанных сущностей, отчёты, оплаты, транзакции, аудит — берите реляционную базу без колебаний и не слушайте сказки про гибкость. Если у вас поток неструктурированных событий и слабая связность — документная база будет вам верным другом. И главное: не меняйте базу ради моды, меняйте её ради конкретной боли, которую чувствуете прямо сейчас.
И ещё одно наблюдение, которое стоило мне нескольких бессонных ночей. Самый дорогой технический долг — это не старый код, а неверно выбранная модель данных. Её потом очень тяжело и дорого менять, потому что она проросла во всю бизнес-логику и в головы команды. Так что выбор базы — это не спор в курилке, а решение с ценой на несколько лет вперёд. А какой опыт был у вас? Расскажите, начинали ли вы с документной базы и потом переезжали на реляционную, или наоборот, и что в итоге оказалось для вашей команды решающим аргументом?