MongoDB *

В статье про юридический техдолг я писал, что он копится незаметно и вылезает через искажённые данные. Теперь покажу, как это выглядит вблизи: одно булево поле в схеме, 142 записи, и система, которая полгода уверенно сообщала неправду.

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

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

Почти любая распределенная платформа рано или поздно сталкивается с необходимостью синхронизировать данные между своими системами. И чем выше требования к надежности и скорости доставки изменений, тем меньше остается простых решений. Бизнес-пользователям при работе с интерфейсом одной из платформ нужно знать о сущностях, заведённых во второй. Первая хранит их в реляционной СУБД (неважно, какой именно), а вторая - в документоориентированной MongoDB. До кучи, обе платформы разнесены по сети. Можно, конечно, предложить открыть оба интерфейса бок о бок и сверять данные глазами. Но это справедливо негативно скажется на финансовом обеспечении команды разработки, да и как-то не по-человечески так относиться к своим коллегам. Поэтому приходится зарабатывать доверие в коллективе честным трудом.

Встаёт вопрос: как в условиях распределённой структуры наладить транспортировку данных для взаимодействия независимых систем? Прикручивать ко всем продуктам кастомные интеграции дорого и непродуктивно. 

В данной статье хочется представить вам, как мы реализовали интеграцию двух независимых платформ со своими базами данных при помощи инструментов MongoDB для мониторинга данных и брокера сообщений. Описать путь от самого простого решения на примитивных выгрузках метаданных одной пачкой до реализации на событиях Change Stream посредством брокера сообщений.

💾 MinIO, MongoDB, PostgreSQL для хранения 25 лет истории стоимости акций

Когда строишь эмулятор для проверки торговой стратегии 20 акций на 25 лет исторических данных поминутно, выбор хранилища становится архитектурной задачей. В статье разобрал, почему попытка использовать MinIO не оправдала себя, где упирается MongoDB и как PostgreSQL с Pgpool-II и read-репликами сократил время чтения одной свечи с 40мс до 10мс

Я давно хотел убрать из backend‑разработки одну особенно липкую рутину: когда для каждой новой сущности снова и снова приходится собирать одни и те же слои REST API — repository, service, handlers, request/response модели, OpenAPI, auth, тесты, curl‑примеры, Docker и прочую инфраструктуру.

В этой статье рассказываю про query‑first подход и open‑source Go CLI rest, который позволяет реализовать эту идею. Смысл простой: если SQL‑запросы или MongoDB‑контракты уже описывают, какие операции нужны приложению, то из них можно сгенерировать согласованный каркас REST‑сервиса.

В статье показано, как это работает для PostgreSQL и MongoDB, что именно генерируется, что такоеrest doctor и почему цель инструмента — не заменить бизнес‑логику, а снять первые 80–90% повторяющейся ручной работы.

_id в MongoDB кажется мелочью, пока не попадает в API, события и миграции.

Разбираем, когда оставить стандартный ObjectId, когда нужен UUID, почему его лучше хранить как BSON Binary subtype 4 и зачем иногда разделять внутренний и публичный идентификатор.

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data и эксперт курса Cloud DevSecOps по безопасной разработке от Академии вАЙТИ Beeline Cloud. Продолжаю цикл статей о клиенте для облачного сервиса Ollama. В первой части я рассказал, как родился этот клиент, с какими трудностями пришлось столкнуться при организации стриминга, и даже оставил пасхалку.

Многие из нас любят NoSQL. И MongoDB среди них является одним из топ-любимчиков. Очень часто мы выбираем нашу «Монгу» за гибкость и скорость. И это вполне логично, ведь MongoDB почти никогда не подводит... сразу. Неприхотливая, шустрая, удобная - она ведет себя как идеальный помощник: не требует лишнего, принимает любые данные, не задаёт неудобных вопросов про схему и с готовностью отвечает на каждый запрос за считанные миллисекунды.

Но потом ты начинаешь подозревать что-то неладное. И, что самое главное, происходит это не сразу, а постепенно. Сначала один запрос начинает задерживаться немного дольше обычного, потом еще один. Там, где раньше было 10-20 миллисекунд, становится 100. Ты замечаешь, что графики ведут себя странно. И начинаешь искать причину: грешишь то на версию софта, то на железо, то думаешь, что сама MongoDB какая-то не такая.

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

В своей статье я предлагаю разобрать распространенные антипаттерны, которые встречаются при проектировании и работе с MongoDB. Также посмотрим на реальные известные случаи пользователей, которые в своей работе сталкивались с проблемами с MongoDB.

Если серьезно, то сегодня мы поговорим про БАЗЫ данных. Как-то один мой друг разработчик сказал, что программирование можно понимать как

Что делать, если после статьи на Хабре количество пользователей выросло вдвое (даже если их стало всего десять)? В этой статье я пройду путь от "крепкого" монолита до взрослой архитектуры с разделением на API, Web и Auth. Поделюсь опытом создания изолированного тестового контура и разберу, почему модная связка Bun + Vercel на реальном продакшене может стоить вам нескольких седых волос и часов дебага.

В Java-приложениях, работающих с MongoDB, преобразование данных между нативным документо-ориентированным представлением MongoDB и обычными Java-объектами (POJO — Plain Old Java Objects) является частой задачей.

Базы данных прибыльнее нефти? В 2025 году Ларри Эллисон стал самым богатым человеком в истории человечества, обойдя Рокфеллера. Тем временем на рынке M&A настоящий пожар: миллиардные сделки, банкротства и судебные иски MongoDB против конкурентов. Перевели подробный разбор того, кто выиграл, а кто проиграл в битве за данные в этом году.

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

У меня был выбор: внедрять тяжелый стандарт RRULE или писать свой велосипед? Для своего трекера задач в Telegram «OK, Bob!» я выбрал второй путь.

В статье рассказываю про подход «буферизированной материализации»: как хранить бесконечные серии в MongoDB, не убивая базу, зачем нужно «скользящее окно» генерации и почему работа с таймзонами сложнее, чем просто хранение в UTC. Разбор архитектуры, кода и неочевидных UX-компромиссов.

В прошлой статье я закончил обзор open source решения для аналитики и, что важно для нас, решения для менеджера тегов - Matomo Tag Manager. В этой статье приступаем к разбору по косточкам самого решения. И начинаем с установки его на сервер. А я продолжаю выступать своего рода евангелистом Matomo Tag Manager в рунете, где он незаслуженно, по моему мнению, обойден стороной.

Команда Spring АйО подготовила материал о том, почему «быстрый запрос в MongoDB» — это не магия, а дисциплина: индексы, форма запроса, проекции, explain(), профайлер и наблюдаемость в Java/Spring Boot. Разбираем, как отличать IXSCAN от COLLSCAN, где чаще всего прячутся антипаттерны (skip-пагинация, тяжёлые $regex/$nin, findAll), и как выстроить измеримый цикл оптимизаций от Atlas/Compass до Micrometer.

KRepo: Никаких имплементаций или инъекций. Под капотом — динамический прокси, кэширование метаданных и независимость от фреймворков: плагины под Exposed, JDBC или MongoDB реализуются отдельно.

Работаете с PostgreSQL и хотите попробовать MongoDB? Я спроецировал опыт работы с реляционными БД на NoSQL и собрал два чек-листа: проверенные практики для PostgreSQL и их аналоги для MongoDB.

Без воды, только ключевые пункты чтобы быстро стартовать и не наступать на типичные грабли.

Нормализация vs Денормализация: Mongo, Postgres и реальная жизнь. Почему у нас вырастает 160 таблиц там, где мог быть один jsonb? И как понять, когда денормализация — это костыль, а когда осознанный выбор?

Если при слове «нормализация» у тебя начинается зевота, а менеджер с порога предлагает «спроектировать базу» — этот текст для тебя.

Всем привет! Меня зовут Андрей, я бэкенд‑разработчик ядра Яндекс Диска. В индустрии я уже около 15 лет и повидал некоторое ПО. Последние три года занимаюсь ядром файловой системы — всем, что связано с метаданными о файлах.

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

Однако при дублировании важно было избежать распределённых транзакций, так как они снижают общую производительность. Также проблемой был сам процесс перехода: у нас сотни миллионов пользователей, которые не должны были ощущать процесс перехода и потерять доступ к своим данным. При этом надо было выкатывать изменения не сразу на 100%, а частично, с возможностью в любой момент отключить функциональность. При выкатке также нельзя было допустить даунтайм.

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

Привет, Хабр! На связи Сергей Гайдамаков. Продолжаем обсуждать и тестировать набор реплик MongoDB. 

В предыдущей статье мы рассмотрели структуру отдельного узла MongoDB, разобрали свойства параметров writeConcern и readConcern для работы с набором реплик MongoDB. 

В этой статье я покажу результаты тестов при аварийных ситуациях, которые могут происходить в распределенной системе. Сделаем выводы о свойствах набора реплик с точки зрения CAP- и PACELC-теорем для распределенных систем и посмотрим параметры управления CAP-свойствами неоднородных распределенных систем.

Введение

В данной статье будет рассмотрена практическая интеграция MongoDB с веб-приложением на Go, построенным на базе маршрутизатора Gorilla Mux. Цель — получить минимальный, но функциональный REST API с поддержкой CRUD-операций над сущностью Book, при этом соблюдая лучшие практики структурирования кода.

Материал рассчитан на разработчиков, знакомых с Go, HTTP API и основами работы с базами данных.

Выбор стека

Go — компилируемый язык с лаконичным синтаксисом, встроенной поддержкой параллелизма и богатой стандартной библиотекой для работы с сетью. Эти качества делают его удобным выбором для разработки API-сервисов.