Я бэкенд-инженер с большим опытом работы с реляционными базами, в первую очередь PostgreSQL. В своих пет-проектах иногда приходил к выводу: задача проще и чище решается, если хранить данные в одной коллекции, т.е. перейти на NoSQL. Для таких задач я выбирал MongoDB.

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

Что важно из опыта с PostgreSQL

Опыт эксплуатации реляционных БД научил меня смотреть не только на структуру данных под функционал, но и на нефункциональные требования: масштабируемость, резервирование, бэкап, мониторинг, индексы, миграции, тестирование и т.п. Простая схема, которая отвечает требованиям сейчас, часто ломается при росте нагрузки и функционала поэтому обслуживание БД и забота о расширяемости не менее важны, чем модель данных.

Почему я решил попробовать MongoDB

• В пет-проектах подключить MongoDB просто документация и драйверы дружелюбны

• .Для некоторых задач модель «одна коллекция» логичнее и производительнее.

• У меня мало продакшен-опыта с MongoDB, поэтому я не хотел полагаться только на интуицию.

Как я переносил практики PostgreSQL на MongoDB

• Я составил список ключевых моментов, на которые обращаю внимание при работе с PostgreSQL (индексы, транзакции, бэкапы, мониторинг, тесты и т. д.).

• Объяснил ChatGPT задачу: дать аналогичный, практичный чек-лист для MongoDB, сопоставимый по уровню детализации с моим PostgreSQL-списком.

• Полученный результат мне понравился поэтому я решил поделиться обеими шпаргалками.

Результат

Я представляю две краткие шпаргалки: одна ключевые моменты для PostgreSQL (мой накопленный опыт), вторая аналогичные контрольные пункты для MongoDB (полученные с помощью ChatGPT). Я сознательно не добавляю длинных объяснений к каждому пункту их легко поиском или у любого чата GPT развернуть в нужный объём.

Как использовать эти шпаргалки

• Воспринимайте их как чек-лист при проектировании и приёмке системы.

• Для каждого пункта делайте минимальную проверку в своём проекте: реализовано/не реализовано/планируется.

• Если не уверены в пункте быстро запросите у документации или у чат-ассистента расширение в 2–3 практических шага.

Кому это полезно

Статья ориентирована на разработчиков, которые:

• знают реляционные БД, но только начинают работать с MongoDB;

• хотят быстро получить набор практических пунктов, чтобы не наступать на обычные грабли;

• предпочитают чек-листы вместо длинных теоретических эссе.

Шпаргалка для PostgreSQL

1. Соединения
◦ Используй connection pooler (PgBouncer, HikariCP).
◦ Избегай большого числа долгоживущих idle-соединений.
2. Запросы и индексы
◦ Анализируй EXPLAIN (ANALYZE) для запросов.
◦ Проверяй эффективность индексов, убирай неиспользуемые.
◦ Следи за корректностью статистики (ANALYZE, default_statistics_target).
3. Рост таблиц / партиционирование
◦ Следи за ростом «горячих» таблиц.
◦ Используй партиционирование (range/list/hash), если таблица становится слишком большой.
4. Размер строк
◦ Избегай слишком «толстых» строк (много JSON/BLOB).
◦ Выносить большие поля в отдельные таблицы.
5. Память и кэш
◦ Настраивай work_mem, shared_buffers, effective_cache_size, hash_mem_multiplier.
◦ Следи за использованием temp файлов (это сигнал, что work_mem мал).
6. Autovacuum и bloat
◦ Контролируй работу autovacuum.
◦ Настраивай autovacuum_vacuum_scale_factor, autovacuum_analyze_scale_factor.
◦ Используй pg_repack или REINDEX при сильном bloat.
7. Бэкапы и восстановление
◦ Настрой регулярные pg_basebackup + WAL архивирование.
◦ Планируй и тестируй PITR (point-in-time recovery).
◦ Используй реплики для бэкапов и отказоустойчивости.
8. Мониторинг
◦ pg_stat_activity, pg_stat_statements, pg_stat_io.
◦ Локи, долгие транзакции, количество соединений.
◦ Мониторинг реплик и WAL lag.

Шпаргалка для MongoDB

1. Соединения
◦ Управляй connection pool (maxPoolSize, minPoolSize, timeout).
◦ Избегай частого создания/закрытия клиентов.
2. Запросы и индексы
◦ Используй explain("executionStats") для анализа.
◦ Создавай compound/multikey/TTL индексы при необходимости.
◦ Убирай неиспользуемые индексы (тратят RAM и место).
◦ Следи за covered queries.
3. Рост коллекций / шардирование
◦ При больших данных — планируй shard key заранее (high cardinality, равномерное распределение).
◦ Используй pre-splitting для избежания hotspot.
◦ Мониторь балансировку чанков.
4. Размер документов
◦ Лимит — 16MB на документ.
◦ Не держи слишком большие массивы и вложенные структуры.
◦ Для больших файлов - GridFS или внешнее хранилище.
5. Память и кэш
◦ WiredTiger cache должен вмещать рабочий набор.
◦ Настрой storage.wiredTiger.engineConfig.cacheSizeGB.
◦ Следи за page faults и cache hit ratio.
6. Фрагментация / reclaim
◦ Mongo не уменьшает файлы на диске автоматически.
◦ Используй compact или пересоздание коллекций.
◦ Следи за документами, которые часто «растут» (обновления увеличивают размер).
7. Бэкапы и восстановление
◦ mongodump/mongorestore (логический способ).
◦ Snapshot на уровне файловой системы (быстрее).
◦ PITR через oplog (как WAL в Postgres).
◦ Репликационные наборы для отказоустойчивости и бэкапов.
8. Мониторинг
◦ Метрики: replication lag, cache usage, page faults, connections, opCounters.
◦ Инструменты: serverStatus, mongostat, mongotop.
◦ Настрой алерты на p99 latency, queue length, lag.