MongoDB *

Многие из нас любят 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-сервисов.

Привет, Хабр!

В этой статье — история запуска Telegram Mini App, куда за трое суток пришло 100.000 реальных пользователей.

Покажу, как мы масштабировали Node.js приложения на многоядерных серверах, увеличивали RPS в 10 раз, боролись с N+1 проблемой в MongoDB и снижали нагрузку на CPU. А ещё расскажу как мы быстро настроили мониторинг через Grafana, подключили Cloudflare и интегрировали Sentry. Поделюсь практическими инсайтами о том, на что стоит обращать внимание в первую очередь, и как эти инструменты помогли нам оперативно находить узкие места и устранять сбои в реальном времени. Всё, о чём будет в этой статье, основано на том, что действительно сработало. Кроме того, расскажу, какие моменты мы упустили до запуска.

Это разбор с цифрами, графиками и практическими выводами. Он может сэкономить вам время, нервы и деньги, если вы готовитесь к запуску Telegram Mini App или просто работаете с Node.js-приложениями, которые могут оказаться под серьёзной нагрузкой.

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

Первая часть про подготовку к запуску доступна здесь.

Привет, Хабр!

В этой статье — история запуска Telegram Mini App, куда за трое суток пришло 100.000 реальных пользователей.

Покажу, как мы масштабировали Node.js приложения на многоядерных серверах, увеличивали RPS в 10 раз, боролись с N+1 проблемой в MongoDB и снижали нагрузку на CPU. А ещё расскажу как мы быстро настроили мониторинг через Grafana, подключили Cloudflare и интегрировали Sentry. Поделюсь практическими инсайтами о том, на что стоит обращать внимание в первую очередь, и как эти инструменты помогли нам оперативно находить узкие места и устранять сбои в реальном времени. Всё, о чём будет в этой статье, основано на том, что действительно сработало. Кроме того, расскажу, какие моменты мы упустили до запуска.

Это разбор с цифрами, графиками и практическими выводами. Он может сэкономить вам время, нервы и деньги, если вы готовитесь к запуску Telegram Mini App или просто работаете с Node.js-приложениями, которые могут оказаться под серьёзной нагрузкой.

Это первая часть истории — про то, как мы готовились к запуску, что предусматривали и на что делали ставку.

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

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

Привет, Хабр! Я Сергей Гайдамаков. Уже 28 лет я занимаюсь проектированием и разработкой программных систем различного масштаба. Сейчас работаю в Т-Банке системным аналитиком и проектирую системы, которые в совокупности составляют большую распределенную систему. 

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

Привет, Хабр! Меня зовут Александр Цай, я ведущий аналитик в МТС Web Services, но на деле занимаюсь всеми вопросами, касающимися DA/DE/BI: выявлением потребностей и сбором требований, проектированием дашбордов и витрин для них, построением и развитием внутреннего хранилища, поиском источников данных, созданием сложных ETL-пайплайнов по их доставке, DQ, проведением аналитики и много чем еще.

В этом материале я расскажу про разворачивание пайплайна по стримингу данных из MongoDB в PostgreSQL с помощью Apache Flink (стримить из Kafka банально, а так заодно пощупаем документоориентированную БД). Делать это мы будем в minikube (kubernetes), а языком программирования для заданий выступит Python. Все описанное в посте выполняется на MacBook с процессором i7.

В интернете, тем более русскоязычном, нет информации о стриминге из MongoDB в Postgres с помощью Flink. Почти все материалы по Flink, которые мне попадались, сводятся к пережевыванию примера WordCount из flink-kubernetes-operator, где на запущенном поде из папки с примерами читается файл и в консоль выводится количество слов в нем. Если спускаться до использования PyFlink, то мы натыкаемся на кастомные образы с Harness SDK и Apache Beam и другие страшные слова. Знакомо?

Так вот, это не наш путь! Данное руководство будет полезно тем, кто такой же извращенец хочет пощупать Flink на родном Python и кто не планирует брать примеры, оторванные от реальности.

В работе веб-разработчика (в частности бекенд-разработчика) встречается много разных интересных и уникальных задач. В этой статье речь пойдёт о такой теме как написание миграций документно-ориентированной БД mongo. Как и в любой задаче у нас имеется несколько вариантов решения проблемы. Мы подробно разберём примеры использования 2х разных c#-библиотек, не углубляясь в детали реализации. Посмотрим их плюсы и минусы и выберем 1 из них для выполнения поставленной задачи. В конце нас ждёт небольшое сравнение производительности, так что пристегнитесь, ведь будет интересно.