TatianaPopov
New member
Приветствую всех на форуме! За последние восемь лет я запускал и переписывал немало сервисов, и почти каждый раз спор о базе данных начинался с фразы «давайте возьмём MongoDB, она же проще». Я и сам так говорил не раз. Поэтому хочу рассказать, как набивал шишки с обеими системами и что понял в итоге.
Начну с PostgreSQL. Один из моих проектов — сервис финансовой отчётности для небольшой торговой сети. Там были счета, позиции, склады, взаимозачёты, и любая ошибка в цифрах стоила реальных денег. Postgres закрыл эту задачу идеально: строгая схема, транзакции, ограничения целостности и понятный SQL. Когда бухгалтер просил очередной отчёт «а покажите ещё вот так», я писал обычный запрос с объединением таблиц и через десять минут отдавал результат. Никаких ночных миграций данных и ручной склейки коллекций в коде.
Теперь MongoDB. Другой мой проект — сбор событий от мобильных приложений и логов с десятков сервисов. Схема менялась каждый месяц, поля приходили и исчезали, а нагрузка была в основном на запись. Вот здесь документная модель раскрылась в полную силу: я просто писал объект в коллекцию, не бегая к миграциям из-за каждого нового поля. А горизонтальное шардирование спасало, когда поток событий вырос в разы.
А теперь про ошибки, ради которых всё это и пишется. Однажды я поддался моде и посадил на Mongo систему с явными связями между сущностями: пользователи, заказы, платежи, статусы. Мы полгода писали ручные «склейки» данных в коде, ловили рассинхрон и в итоге делали ночные скрипты проверки целостности. Переезд на Postgres снял эту боль за пару недель. В зеркальной ситуации я пробовал держать сотни гигабайт разномастных логов в Postgres — стало больно от бесконечных миграций и от того, что реляционные гарантии там просто не нужны.
Отсюда мой главный совет: выбирайте базу не по хайпу и не по тому, что «модно в этом году», а по природе ваших данных. Задайте себе четыре вопроса. Есть ли между сущностями настоящие связи и правила целостности? Нужны ли вам многошаговые транзакции? Насколько стабильна структура данных? И как вы чаще всего будете её читать — целыми связанными наборами или отдельными документами по ключу?
Если ответы складываются в картину «строгие правила, связи, отчёты, деньги» — берите PostgreSQL и не сомневайтесь. Если это «поток событий, гибкая структура, много записи, документы живут сами по себе» — MongoDB честно сделает свою работу. И не забывайте про третий путь: современный Postgres умеет хранить JSON прямо в колонках, что часто закрывает хотелки гибкости без второй базы в инфраструктуре. Ещё один момент, который я вынес из своего опыта: решает не только движок, а умение вашей команды с ним работать и поддерживать его в проде ночью.
В общем, обе системы хороши на своём месте, и универсального «правильного» ответа нет — есть ваш конкретный случай. А что в вашей практике? Какой вопрос про данные помог вам выбрать базу и не пожалеть — поделитесь историей в комментариях, будет очень интересно сравнить опыт!
Начну с PostgreSQL. Один из моих проектов — сервис финансовой отчётности для небольшой торговой сети. Там были счета, позиции, склады, взаимозачёты, и любая ошибка в цифрах стоила реальных денег. Postgres закрыл эту задачу идеально: строгая схема, транзакции, ограничения целостности и понятный SQL. Когда бухгалтер просил очередной отчёт «а покажите ещё вот так», я писал обычный запрос с объединением таблиц и через десять минут отдавал результат. Никаких ночных миграций данных и ручной склейки коллекций в коде.
Теперь MongoDB. Другой мой проект — сбор событий от мобильных приложений и логов с десятков сервисов. Схема менялась каждый месяц, поля приходили и исчезали, а нагрузка была в основном на запись. Вот здесь документная модель раскрылась в полную силу: я просто писал объект в коллекцию, не бегая к миграциям из-за каждого нового поля. А горизонтальное шардирование спасало, когда поток событий вырос в разы.
А теперь про ошибки, ради которых всё это и пишется. Однажды я поддался моде и посадил на Mongo систему с явными связями между сущностями: пользователи, заказы, платежи, статусы. Мы полгода писали ручные «склейки» данных в коде, ловили рассинхрон и в итоге делали ночные скрипты проверки целостности. Переезд на Postgres снял эту боль за пару недель. В зеркальной ситуации я пробовал держать сотни гигабайт разномастных логов в Postgres — стало больно от бесконечных миграций и от того, что реляционные гарантии там просто не нужны.
Отсюда мой главный совет: выбирайте базу не по хайпу и не по тому, что «модно в этом году», а по природе ваших данных. Задайте себе четыре вопроса. Есть ли между сущностями настоящие связи и правила целостности? Нужны ли вам многошаговые транзакции? Насколько стабильна структура данных? И как вы чаще всего будете её читать — целыми связанными наборами или отдельными документами по ключу?
Если ответы складываются в картину «строгие правила, связи, отчёты, деньги» — берите PostgreSQL и не сомневайтесь. Если это «поток событий, гибкая структура, много записи, документы живут сами по себе» — MongoDB честно сделает свою работу. И не забывайте про третий путь: современный Postgres умеет хранить JSON прямо в колонках, что часто закрывает хотелки гибкости без второй базы в инфраструктуре. Ещё один момент, который я вынес из своего опыта: решает не только движок, а умение вашей команды с ним работать и поддерживать его в проде ночью.
В общем, обе системы хороши на своём месте, и универсального «правильного» ответа нет — есть ваш конкретный случай. А что в вашей практике? Какой вопрос про данные помог вам выбрать базу и не пожалеть — поделитесь историей в комментариях, будет очень интересно сравнить опыт!