22.12.2025 16:11
spring_aio 0 7000 Источник

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

Каждый запрос MongoDB включает в себя больше, чем просто получение документов. За кулисами планировщик запросов базы данных оценивает индексы, фильтры и проекции, чтобы определить, как лучше всего получить результаты. Для Java-разработчиков, использующих Spring Boot или фреймворки, построенные на MongoDB Java Driver, понимание этого процесса имеет решающее значение для написания эффективных запросов.

На скорость выполнения запросов влияют несколько элементов:

  • Использование индексов: MongoDB полагается на индексы для эффективного поиска. Когда запрос соответствует индексированному полю, MongoDB находит документы напрямую, вместо того чтобы сканировать всю коллекцию.

    Комментарий от эксперта сообщества Spring АйО, Михаила Поливахи:

    Это далеко не всегда так. Планировщик запросто может решить пропустить индекс даже если он существует. 

    Например, индексация данных (сейчас даже конкретный вид индекса не так важен, btree+ или гео-индексы) подразумевает, что, если в индексе как в структуре данных отсуствуют все необходимые поля, то execution engine-у придётся делать ряд random access read-ов в на диск. Почитайте про разницу между index only scan и index scan в PostgreSQL для того, чтобы понять общую концепцию.

    Так вот поэтому, иногда, использование индекса совершенно неоправдано, и планировщик может посчитать, что проще сделать один относительно большой seqscan,  collscan и т.п. и уже в памяти наложить фильтрацию.

  • Форма запроса: Структура и операторы в запросе определяют, может ли MongoDB эффективно использовать индекс. Запросы диапазона и фильтры равенства ведут себя по-разному при выборе индекса.

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

  • Задержка сети: Приложения, удаленные от кластеров баз данных или не использующие пулы соединений, испытывают задержки, даже с оптимизированными запросами.

Когда запрос выполняется, планировщик запросов MongoDB оценивает доступные индексы, оценивает затраты и выбирает наиболее эффективный путь выполнения. Без подходящего индекса MongoDB выполняет сканирование коллекции, читая каждый документ для поиска совпадений. Разработчики могут проверить эти решения с помощью метода explain():

db.orders.find({ status: "shipped" }).explain("executionStats");

Вывод показывает, использовал ли MongoDB индекс (IXSCAN) или сканирование коллекции (COLLSCAN). Ключевые метрики включают время выполнения, количество проверенных документов против возвращенных и стадию выполнения. Низкое соотношение проверенных к возвращенным документам указывает на эффективное использование индекса.

Комментарий от эксперта сообщества Spring АйО, Михаила Поливахи:

Здесь кстати в тему эффективности индексов я рекомендую ознакомиться с понятиями кардинальности индекса, и с понятием селективности индекса. Тогда же будет ползено изучить, что такое битовая карта (она же bitmap).

Распространенные узкие места включают отсутствующие индексы, большие проекции, неэффективные фильтры, такие как $regex или $nin, и неограниченные запросы. При использовании Spring Data MongoDB убедитесь, что запросы репозитория сопоставляются с индексированными полями:

@Document(collection = "users")
public class User {

    @Indexed
    private String email;

    private String name;

    private Date createdAt;

}

Эта аннотация автоматически создает индекс, обеспечивая эффективное выполнение запросов типа findByEmail(String email). Сравнение сканирования коллекции и индексированного запроса показывает значительные различия в производительности. Без индекса вывод explain() показывает COLLSCAN и высокое количество документов. После добавления индекса тот же запрос показывает IXSCAN и гораздо меньше проверенных документов, сокращая время запроса с сотен миллисекунд до нескольких.

Профилирование и мониторинг запросов

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

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

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

db.setProfilingLevel(1, { slowms: 50 });

db.system.profile.find().sort({ ts: -1 }).limit(5);

Здесь slowms контролирует, какие операции квалифицируются как медленные. Сохранение этого значения консервативным помогает поддерживать чистое представление о проблемных запросах без перегрузки журнала профайлера. Это простая, но важная часть диагностики неэффективных форм запросов, таких как неиндексированные фильтры, дорогие стадии $lookup или широкие поля проекции.

Мониторинг выходит за рамки журналов медленных запросов. В Java-приложениях драйвер предоставляет хуки для наблюдения за тем, как приложение взаимодействует с MongoDB. Spring Data MongoDB естественным образом интегрируется с этими функциями. Одним из наиболее полезных инструментов в этой области является интерфейс CommandListener, который позволяет прослушивать команды и помечать медленные операции до того, как они станут проблемами. Слушатель команд идеален для команд, которые хотят observability без включения широкого профилирования на уровне базы данных.

import com.mongodb.event.CommandListener;
import com.mongodb.event.CommandSucceededEvent;
import java.util.concurrent.TimeUnit;

public class QueryLoggingListener implements CommandListener {

    @Override
    public void commandSucceeded(CommandSucceededEvent event) {
        long took = event.getElapsedTime(TimeUnit.MILLISECONDS);
        if (took > 50) {
            System.out.println("Slow query: " + event.getCommandName() + " took " + took + " ms");
        }
    }
}

Чтобы зарегистрировать этот слушатель, добавьте его при создании вашего MongoClient:

MongoClientSettings settings = MongoClientSettings.builder()
    .applyConnectionString(new ConnectionString(connectionString))
    .addCommandListener(new QueryLoggingListener())
    .build();

MongoClient client = MongoClients.create(settings);

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

Многие команды также полагаются на план explain, встроенный в MongoDB. В отличие от реляционных баз данных, где планы explain часто кажутся абстрактными, вывод explain MongoDB представляет практическую информацию об использовании индекса, проверенных документах и выигрышных планах. Две наиболее важные метрики — это nReturned и totalDocsExamined. Если последняя значительно больше первой, ваш запрос сканирует больше документов, чем в итоге возвращает. Часто то указывает на отсутствующий или неиспользуемый индекс. План explain также полезен при подтверждении того, что составные индексы правильно соответствуют вашему паттерну запроса.

db.users.find({ email: "[email protected]" }).explain("executionStats");

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

Для команд, использующих MongoDB Atlas, Performance Advisor идет дальше, предлагая улучшения индексов на основе реального трафика. В отличие от ручного профилирования, которое требует копаться в журналах или выводе explain, советник постоянно наблюдает за вашей рабочей нагрузкой. Он идентифицирует проблемные формы запросов, рекомендует индексы и показывает, какие запросы больше всего выиграют от каждого улучшения. Встроенная панель метрик также помогает отслеживать использование CPU, потребление памяти и задержки операций без внешних инструментов.

MongoDB Compass предоставляет локальную альтернативу метрикам Atlas. Его встроенная визуализация плана explain четко отображает стадии запроса, что упрощает понимание того, какая часть конвейера отвечает за большую часть времени выполнения. Это особенно полезно при работе с конвейерами агрегации, где несколько стадий взаимодействуют сложным образом. MongoDB Compass отображает поток документов и покрытие индекса в дружественном формате, который помогает разработчикам понимать поведение запросов.

В Java-приложениях метрики запросов должны выходить за рамки уровня базы данных. Полная настройка мониторинга включает отслеживание задержки и на границе приложения. Micrometer является популярным выбором для этого, потому что он интегрируется со Spring Boot и экспортирует метрики в системы вроде Prometheus и Grafana. С таймерами Micrometer вы можете захватывать, сколько времени требуется для выполнения конкретных методов репозитория. Это позволяет сравнивать задержку на уровне драйвера с задержкой на уровне приложения и определять, исходят ли узкие места из самой базы данных или из окружающего кода.

Timer timer = Timer.builder("mongo.query.time")
    .tag("collection", "users")
    .register(meterRegistry);

return timer.record(() -> mongoTemplate.find(query, User.class));

Этот пример оборачивает вызов репозитория таймером. Записанная продолжительность помогает отслеживать среднее время запросов и выбросы. Вы можете отображать эти метрики с течением времени, чтобы понять базовую производительность. Наличие базовых показателей важно, потому что настройка производительности — это не разовая задача. Изменения в поведении пользователей, размере данных или паттернах индексации — все это влияет на то, как ведут себя запросы, поэтому исторические сравнения необходимы.

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

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

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

Проектирование эффективных запросов

Как только вы поймете, как профилировать и отслеживать запросы, следующий шаг — проектирование запросов, которые естественным образом соответствуют сильным сторонам MongoDB. Хорошо спроектированные запросы эффективно используют индексы, минимизируют передачу данных и используют вычисления на стороне сервера. Этот раздел охватывает практические паттерны, которые помогают вашему Java-приложению извлекать лучшую производительность из MongoDB.

Самое важное правило — писать запросы, которые соответствуют вашим индексам, а не наоборот. Индексы наиболее эффективны, когда запросы фильтруют и сортируют, используя точно те поля и порядок, которые определены в индексе. Если ваш составной индекс — { status: 1, createdAt: -1 }, структурируйте запросы для фильтрации по статусу и сортировки по времени создания. Несовпадающие запросы заставляют MongoDB сканировать больше данных, чем необходимо.

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

Комментарий от эксперта сообщества Spring АйО, Михаила Поливахи:

Вот это довольно спорное утверждение, которое на практике далеко не всегда вообще жизнеспособно. Оставим на совести автора.

Вместо получения целых документов укажите, какие поля действительно нужны вашему приложению:

Query query = new Query()
    .addCriteria(Criteria.where("status").is("active"))
    .fields().include("name").include("email");

List<User> users = mongoTemplate.find(query, User.class);

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

Избегайте использования $or и $in на неиндексированных полях. Эти операторы могут препятствовать эффективному использованию индекса и вынуждать сканирование коллекций. По возможности реструктурируйте запросы для использования фильтров равенства или запросов диапазона, которые соответствуют вашим индексам. Для сложной логики фильтрации рассмотрите использование конвейеров агрегации, которые обеспечивают больший контроль над порядком выполнения.

Конвейеры агрегации перемещают вычисления на сервер, уменьшая количество данных, передаваемых вашему приложению. Всегда размещайте стадии $match и $sort в начале конвейера, чтобы фильтровать документы перед дорогостоящими операциями, такими как $group или $lookup. Вот пример хорошо структурированного конвейера:

Aggregation pipeline = Aggregation.newAggregation(
    match(Criteria.where("status").is("completed")),
    sort(Sort.by(Sort.Direction.DESC, "total")),
    group("category").sum("total").as("revenue")
);

Комментарий от эксперта сообщества Spring АйО, Михаила Поливахи:

В этом кстати сильное отличие Aggregation Pipelines или как их называет автор "Конвейеров аггрегации" от вообще запросов в реляционные БД.

Если вы передаете в реляционную БД условный SQL запрос, который, например, содержит 3 условия фильтрации в WHERE, потом группировку с сортировкой, то это совершенно (как в теории, так и на практике) не значит, что планировщик сначала сделает SELECT, потом отфильтрует всё, что надо, потмо применит группировку и т.д. Планировщик вправе делать всё, что угодно, т.к. совершенно базовый постулат такой:

SQL - это декларативный язык запросов, не императивный.

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

И вот в случае с MongoDB Aggregation Pipelines это как раз не так. Там это больше императивный подход.

Этот подход фильтрует и сортирует перед группировкой, минимизируя данные, которые MongoDB обрабатывает на более поздних стадиях. Выбирайте запросы диапазона вместо поиска по префиксу regex. Паттерны regex с начальными подстановочными знаками, такими как /.*term/ или /.*term$/, не могут эффективно использовать индексы. Если вам нужно сопоставление паттернов, структурируйте запросы для использования префиксных паттернов типа /^pattern/, которые привязываются к началу строки и могут использовать индексы.

Стратегии индексирования для скорости

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

Индексы в MongoDB работают аналогично индексам в реляционных базах данных. Они создают вспомогательную структуру данных, которая хранит небольшое упорядоченное представление конкретных полей. Когда запрос использует эти поля на стадии фильтра или сортировки, MongoDB переходит непосредственно к соответствующим записям вместо обхода всей коллекции. Это снижает нагрузку на CPU и сохраняет стабильную производительность даже при масштабировании.

Типы индексов

MongoDB поддерживает несколько типов индексов. Каждый из них служит очень специфической цели, и выбор правильного типа зависит от того, как ваше приложение запрашивает данные. Наиболее распространенные типы:

  • Индексы с одним полем: идеальны для простых фильтров равенства, таких как поиск по электронной почте, имени пользователя или категории продукта.

  • Составные индексы: полезны, когда ваши запросы включают более одного поля. Составной индекс на { status: 1, createdAt: -1 } ускоряет запросы, которые соответствуют статусу и сортируют результаты по времени создания.

  • Текстовые индексы: используются для полнотекстового поиска по выбранным строковым полям.

  • TTL индексы: предназначены для документов, которые должны автоматически истекать после определенной продолжительности. Они широко используются для токенов доступа, журналов или аналитических событий. Обратите внимание, что TTL индексы не гарантируют немедленного истечения. MongoDB удаляет истекшие документы во время фоновой очистки, которая обычно выполняется каждую минуту.

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

Понимание поведения индексов на раннем этапе предотвращает распространенные ошибки, такие как создание слишком большого количества индексов или построение индексов, которые никогда не используются. Оба варианта могут замедлить запись и увеличить использование памяти. Баланс — это главное.

Выбор правильного порядка индекса

Порядок составного индекса имеет значение. MongoDB использует правило, известное как паттерн префикса. Этот паттерн объясняет, сколькими способами ваш составной индекс может быть использован. В определениях индексов 1 указывает на возрастающий порядок, а -1 указывает на убывающий порядок. Например, индекс на { status: 1, createdAt: -1 } поддерживает:

  • Запросы по status.

  • Запросы по status и createdAt.

  • Сортировки, которые соответствуют направлению индекса.

  • Комбинации фильтров и сортировок, которые используют оба поля.

Тот же индекс не помогает запросам, которые фильтру��т только по createdAt. Понимание этого правила префикса помогает проектировать индексы, которые обслуживают несколько запросов без увеличения давления на память.

Покрытые запросы против непокрытых запросов

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

Например:

db.orders.find(
  { status: 'completed' },
  { _id: 0, status: 1, total: 1 }
)

Если индекс — { status: 1, total: 1 }, этот запрос может быть полностью покрыт. MongoDB не нужно получать документы, потому что все запрошенные поля уже есть в индексе.

Когда не индексировать

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

В целом избегайте индексирования:

  • Полей с низкой селективностью, таких как флаги, которые содержат только да или нет.

  • Полей, редко используемых в фильтрах или сортировках.

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

  • Коллекций с высокими нагрузками записи, если индекс не является необходимым.

Четкая стратегия индексирования должна возникать из мониторинга реальных паттернов трафика, а не из догадок.

Объявление индексов в Java

Java-приложения могут определять индексы либо через аннотации, либо программным созданием с использованием MongoTemplate. Это сохраняет дизайн индекса под контролем версий и повторяемым.

Вот простой пример с использованием аннотаций:

@Document(collection = "orders")
public class Order {

    @Indexed
    private String status;

    @Indexed
    private Date createdAt;

    private double total;
}

И пример программного создания:

Index index = new Index()
        .on("status", Sort.Direction.ASC)
        .on("createdAt", Sort.Direction.DESC);

mongoTemplate.indexOps("orders").ensureIndex(index);

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

Быстрое сравнение плана explain

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

Пример сканирования коллекции

db.orders.find({ status: 'completed' }).explain('executionStats')

Если вывод explain показывает…

"stage": "COLLSCAN",

"docsExamined": 150000

…это означает, что MongoDB отсканировал всю коллекцию. Это медленно и растет линейно.

Пример индексированного запроса

db.orders.createIndex({ status: 1 })

db.orders.find({ status: 'completed' }).explain('executionStats')

Теперь вывод может показывать:

"stage": "IXSCAN",

"keysExamined": 5000,

"docsExamined": 5000

Разница немедленная и предсказуемая. Индексы уменьшают количество данных, которые MongoDB нужно сканировать, и значительно улучшают время отклика.

Избежание распространенных антипаттернов запросов

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

Загрузка слишком большого количества данных

Одна из самых простых ошибок — возвращать полные документы, даже когда приложению нужно только подмножество полей. Большие документы увеличивают накладные расходы сети и требуют больше работы от Java-драйвера при декодировании ненужных полей. Они также увеличивают использование памяти в JVM.

Проекции помогают избежать этого:

Query query = new Query()
    .addCriteria(Criteria.where("status").is("ACTIVE"))
    .fields().include("name").include("email");

List<User> results = mongoTemplate.find(query, User.class);

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

Неэффективная пагинация со skip

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

Пагинация на основе диапазона намного быстрее.

Комментарий от эксперта сообщества Spring АйО, Михаила Поливахи:

Она же keyset пагинация или seek method пагинация. 

Проблема со skip(), которую описывает автор, она концептуальная. Она вполне себе имеет место быть и в реляционных БД в том числе. 

И как и в реляционных БД, если можно избежать skip/offset пагинации, то лучше это сделать.

Вместо пропуска документов вы фильтруете, используя последний увиденный ID с предыдущей страницы:

// Первая страница
Query query = new Query()
    .limit(20)
    .with(Sort.by(Sort.Direction.ASC, "_id"));

List<Order> firstPage = mongoTemplate.find(query, Order.class);

// Следующая страница - используйте последний ID с предыдущей страницы

ObjectId lastSeenId = firstPage.get(firstPage.size() - 1).getId();

Query nextQuery = new Query()
    .addCriteria(Criteria.where("_id").gt(lastSeenId))
    .limit(20)
    .with(Sort.by(Sort.Direction.ASC, "_id"));

List<Order> nextPage = mongoTemplate.find(nextQuery, Order.class);

Этот подход использует границы индекса вместо прохода по всему набору результатов. Поскольку _id всегда индексирован, этот запрос остается быстрым независимо от глубины страницы.

Неправильное использование $lookup в конвейерах

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

Используйте $lookup для отношений, которые действительно требуют запросов между коллекциями или когда встраивание вызвало бы неограниченный рост документов.

Избыточное извлечение больших массивов

Большие неограниченные массивы становятся узкими местами производительности. Возвращение больших массивов заставляет и MongoDB, и Java-драйвер обрабатывать больше данных, чем требуется. Это также рискует столкновением с ограничениями размера документа и памяти.

Используйте срезы массивов, чтобы ограничить количество возвращаемых данных:

Query query = new Query()
    .addCriteria(Criteria.where("category").is("TECH"))
    .fields().slice("tags", 10);

Сохранение массивов ограниченными или хранение их в отдельных коллекциях помогает поддерживать предсказуемую производительность.

Использование дорогих операторов на неиндексированных полях

Операторы, такие как $regex, $nin, $not и выражения, которые преобразуют поля, часто не могут использовать индексы. Это вынуждает полное сканирование коллекции. Паттерны regex с начальными подстановочными знаками, такие как /.*term/ или /.*term$/, особенно проблематичны, потому что никакой индекс не может их оптимизировать.

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

Чрезмерное использование findAll

Высокоуровневые фреймворки часто имеют удобные методы вроде findAll(). Вызов их в производственных путях почти всегда антипаттерн, потому что он читает всю коллекцию. Это увеличивает I/O, использование памяти и время отклика.

Вместо этого определяйте конкретные методы запросов:

List<Order> results = orderRepository
    .findByStatus("PENDING", PageRequest.of(0, 50));

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

Большинство антипаттернов в дизайне запросов MongoDB происходят от непреднамеренного запроса слишком большого количества данных или формирования запросов таким образом, что индексы не могут их поддерживать. Используя проекции, пагинацию на основе диапазона, ограниченные массивы и фильтры, дружественные к индексам, вы значительно снижаете нагрузку на CPU, память и I/O как на MongoDB, так и на вашем Java-приложении. Продуманный дизайн запросов часто является самым быстрым способом улучшить производительность без изменения вашей схемы или инфраструктуры.

Оптимизация паттернов чтения и записи

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

Оптимизация паттернов чтения

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

Используйте правильную реплику при чтении данных

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

Некоторые часто используемые опции чтения:

  • secondaryPreferred: читает с вторичного узла, когда это возможно, и возвращается к primary при необходимости.

  • nearest: читает с узла с наименьшей задержкой сети независимо от того, является ли он primary или вторичным.

Вот пример настройки пользовательского MongoClient в Java с предпочтением чтения:

import com.mongodb.ReadPreference;
import com.mongodb.client.MongoClient;
import com.mongodb.client.MongoClients;
import com.mongodb.MongoClientSettings;

MongoClientSettings settings = MongoClientSettings.builder()
        .applyConnectionString(new ConnectionString(connectionString))
        .readPreference(ReadPreference.secondaryPreferred())
        .build();

MongoClient client = MongoClients.create(settings);

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

Кэшируйте часто запрашиваемые запросы

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

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

Простой пример кэша Caffeine выглядит так:

Cache<String, List<Product>> productCache = Caffeine.newBuilder()
        .expireAfterWrite(Duration.ofMinutes(5))
        .maximumSize(10_000)
        .build();

public List<Product> getFeaturedProducts() {
    return productCache.get("featured", key ->
        mongoTemplate.find(query(where("featured").is(true)), Product.class)
    );

}

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

Сохраняйте проекции узкими

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

Использование проекций — это простое исправление:

Query query = new Query();
query.addCriteria(Criteria.where("status").is("active"));
query.fields().include("name").include("email");
List<User> users = mongoTemplate.find(query, User.class);

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

Оптимизация паттернов записи

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

Используйте массовые операции везде, где это возможно

Вставка или обновление документов один за другим увеличивает количество сетевых переходов туда-обратно и замедляет сервер. Массовые API MongoDB позволяют группировать операции в батчи. Java-драйвер предоставляет BulkOperations в Spring Data, что сохраняет код простым, улучшая производительность.

Вот типичный пример:

BulkOperations ops = mongoTemplate.bulkOps(BulkOperations.BulkMode.UNORDERED, Order.class);

for (OrderUpdate update : updates) {
    ops.updateOne(
        Query.query(Criteria.where("_id").is(update.getId())),
        Update.update("status", update.getStatus())
    );
}

ops.execute();

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

Настройте уровни надежности записи на основе бизнес-потребностей

Уровни надежности записи определяют уровень долговечности операций записи. Более высокие уровни долговечности обеспечивают более сильные гарантии, но снижают производительность. Многие Java-разработчики оставляют уровни надежности записи по умолчанию, не задумываясь о компромиссах.

Вот краткое резюме, которое вы можете применить:

  • w=1: самый быстрый; подтвержден только primary; достаточно безопасен, когда потеря нескольких записей приемлема

  • w=majority: сильная долговечность по всему набору реплик; требуется для финансовых или транзакционных операций

  • j=true: обеспечивает попадание записи в журнал; медленнее, но безопаснее

Вы можете настроить уровни надежности записи глобально:

MongoClientSettings settings = MongoClientSettings.builder()
    .applyConnectionString(new ConnectionString(connectionString))
    .writeConcern(WriteConcern.MAJORITY)
    .build();

MongoClient client = MongoClients.create(settings);
MongoTemplate template = new MongoTemplate(client, "mydb");

Или для отдельной операции:

UpdateResult result = mongoTemplate
    .withWriteConcern(WriteConcern.W1)
    .updateFirst(query, update, Product.class);

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

Например, микросервис, получающий события из Kafka, может собирать 500 событий или сбрасывать каждые 200 миллисекунд, в зависимости от того, что наступит раньше. Эти паттерны легко реализовать с помощью обычных инструментов параллелизма Java.

Настройте ваш пул соединений

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

Spring Data позволяет настраивать размеры пула в свойствах приложения:

spring.data.mongodb.uri: mongodb+srv://...
spring.data.mongodb.connection-pool.max-size: 100
spring.data.mongodb.connection-pool.min-size: 10
spring.data.mongodb.connection-pool.max-wait-time: 2000ms

Вот хорошая отправная точка:

  • Размер пула в два-четыре раза больше количества ядер CPU на узле приложения.

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

  • Следите за очередями ожидания и корректируйте на основе наблюдаемых паттернов.

Собираем все вместе

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

Использование фреймворков агрегации

Фреймворк агрегации — это одна из самых мощных частей MongoDB. Он позволяет базе данных выполнять преобразования, вычисления и фильтрацию в структурированном конвейере вместо того, чтобы полагаться на множество переходов туда-обратно из вашего Java-приложения. Как только ваш проект вырастает за пределы простых фильтров и проекций, обучение использованию конвейеров агрегации становится необходимым для производительности. На практике конвейеры позволяют изменять форму документов, выполнять аналитику и объединять связанные наборы данных, оставаясь внутри движка базы данных.

В своей основе фреймворк агрегации работает как последовательность стадий. Каждая стадия принимает текущий набор документов, выполняет на них операцию и передает результаты на следующую стадию. Стадии, такие как $match, $group, $project, $sort, $lookup и $facet, каждая служит конкретной роли. Сила этого дизайна заключается в том, как эти стадии могут быть объединены. Хорошо спроектированный конвейер сохраняет документы как можно меньше на раннем этапе, помещает селективные фильтры в начало и выполняет более тяжелую работу, такую как группировка или объединение, только на сокращенном наборе данных.

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

import org.springframework.data.mongodb.core.aggregation.Aggregation;
import org.springframework.data.mongodb.core.aggregation.AggregationResults;
import org.springframework.data.mongodb.core.query.Criteria;
import org.bson.Document;

import static org.springframework.data.mongodb.core.aggregation.Aggregation.*;

Aggregation pipeline = Aggregation.newAggregation(
    match(Criteria.where("status").is("published")),
    group("category").count().as("count"),
    sort(Sort.by(Sort.Direction.DESC, "count"))
);

AggregationResults<Document> results = mongoTemplate.aggregate(
    pipeline,
    "articles",
    Document.class
);

Стадия match ограничивает работу на раннем этапе. Стадия group вычисляет количество. Стадия sort упорядочивает результаты. Этот подход выполняет все вычисления внутри MongoDB и возвращает только конечные документы в ваш Java-код. Объект AggregationResults содержит результирующие документы, к которым вы можете получить доступ с помощью getMappedResults().

Более продвинутые случаи использования включают панели аналитики, сводки потоков событий, контентные ленты и конвейеры, которые объединяют несколько коллекций через $lookup. Например, объединение деталей пользователя в ленту активности становится одним конвейером, а не несколькими запросами:

Aggregation pipeline = Aggregation.newAggregation(
    match(Criteria.where("type").is("activity")),
    lookup("users", "userId", "_id", "user"),
    unwind("user"),
    project("timestamp", "action")
        .and("user.name").as("userName")
);

Практические улучшения производительности часто появляются, когда вы заменяете цепные запросы find или повторяющуюся постобработку одним конвейером. Реальный случай, который хорошо это иллюстрирует, — это превращение многозапросного рабочего процесса аналитики в один серверный конвейер. Это уменьшает накладные расходы сети, освобождает память JVM и сокращает задержку, иногда на порядок величины. Конвейеры получают еще большую выгоду в сочетании с индексами, которые поддерживают начальные стадии $match и $sort.

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

Измерение и бенчмаркинг улучшений

Настройка запросов без их измерения — это догадки. Как только вы начнете изменять формы запросов, индексы или конвейеры агрегации, вам нужен повторяемый способ проверить, действительно ли вы сделали все быстрее или просто переместили узкое место в другое место. Вот где помогает простой рабочий процесс измерения: измерить, изменить одну вещь, измерить снова, затем сохранить или отменить.

В типичном Spring Boot приложении у вас уже есть Micrometer в classpath. Вы можете обернуть критические вызовы MongoDB в таймеры и начать строить базовую линию задержки перед касанием любого запроса. Например, измерение вызова MongoTemplate выглядит так:

@Autowired
private MongoTemplate mongoTemplate;

@Autowired
private MeterRegistry meterRegistry;

public List<Order> findRecentPaidOrders() {
    Timer timer = meterRegistry.timer("mongo.orders.recentPaid");
    return timer.record(() ->
        mongoTemplate.find(
            Query.query(Criteria.where("status").is("PAID"))
                .limit(50)
                .with(Sort.by(Sort.Direction.DESC, "createdAt")),
            Order.class,
            "orders"
        )
    );
}

После нескольких развертываний вы можете сравнить средние значения и значения p95 для mongo.orders.recentPaid до и после изменения. Когда вы также записываете explain("executionStats") во время профилирования, вы можете отслеживать соотношение отсканированных к возвращенным вместе с задержкой, что дает более четкую картину, чем только измерение времени.

Для реактивных стеков паттерн похож, но вы сохраняете реактивный поток нетронутым. Простой подход использует Timer.Sample внутри обработчика:

public Flux<Order> streamRecentPaidOrders() {
    Timer.Sample sample = Timer.start(meterRegistry);
    return reactiveMongoTemplate
        .find(Query.query(Criteria.where("status").is("PAID")), Order.class)
        .doOnComplete(() -> sample.stop(
            Timer.builder("mongo.orders.recentPaid.reactive")
                .register(meterRegistry)
        ));
}

Это сохраняет измерение на границе и предотвращает искажение реактивного конвейера блокирующим кодом.

Micrometer дает вам измерение времени на уровне приложения, но иногда вы хотите микробенчмаркнуть конкретный паттерн запроса или метод репозитория изолированно. Вот где подходит Java Microbenchmark Harness (JMH). JMH — это фреймворк бенчмаркинга, созданный командой OpenJDK для измерения производительности Java-кода. Небольшой бенчмарк, который подготавливает набор данных в экземпляре MongoDB, поддерживаемом Testcontainers (Testcontainers позволяет запускать Docker-контейнеры для тестирования), затем выполняет один и тот же запрос в узком цикле, может показать, уменьшает ли новый индекс, проекция или стадия агрегации медианную и крайнюю задержку.

Инструменты нагрузочного тестирования, такие как Gatling и JMeter, дополняют микробенчмарки. Они попадают в ваши HTTP-эндпоинты с реалистичными темпами, в то время как ваши запросы выполняются под ними. В сочетании с метриками MongoDB Atlas или db.serverStatus() вы можете наблюдать за пропускной способностью, использованием соединений и количеством медленных запросов по мере увеличения нагрузки.

Наконец, подключите все к панели управления. Экспортируйте метрики Micrometer в Prometheus, создайте представление Grafana для таймеров mongo.* и разместите их рядом с специфичными для MongoDB индикаторами, такими как соотношение отсканированных к возвращенным и скорость попадания в кэш. Относитесь к этому как к живому отчету, а не к разовому контрольному списку. Когда появляются новые функции или изменяются паттерны трафика, вы повторно запускаете бенчмарки, сравниваете с базовой линией и решаете, нужна ли дополнительная работа с запросами или пора пересмотреть схему.

Лучшие практики для production

Запуск оптимизированных запросов в разработке — это одно, но сохранение их быстрыми и предсказуемыми в production требует другого уровня дисциплины. Рабочие нагрузки production вводят более высокий уровень параллелизма, непредсказуемые всплески трафика, сложные паттерны доступа и медленные запросы, которые появляются только под реальным давлением. Этот раздел выделяет наиболее важные практики, которые помогают поддерживать согласованную производительность запросов после развертывания вашего приложения.

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

Также полезно использовать ограниченные коллекции для журналов, метрик или эфемерных диагностических данных. Ограниченные коллекции — это коллекции фиксированного размера, которые поддерживают порядок вставки и автоматически отбрасывают самые старые документы при достижении емкости. Это предотвращает влияние роста коллекции журналов на использование диска или производительность с течением времени.

Вы можете создать ограниченную коллекцию из оболочки MongoDB:

db.createCollection("queryLogs", { capped: true, size: 10485760, max: 5000 });

Это создает ограниченную коллекцию, ограниченную 10 МБ или 5000 документами, в зависимости от того, какой лимит достигнут первым.

Многие команды получают выгоду от использования контрольного списка производительности запросов, который разработчики могут быстро просмотреть перед отправкой новых функций:

Проверка

Описание

Покрытие индексом

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

Ограничения проекции

Убедитесь, что запросы возвращают только необходимые поля

Целевые фильтры

Подтвердите, что фильтры соответствуют индексированным полям

Стадии агрегации

Просмотрите порядок конвейера и раннюю фильтрацию

Политика кэширования

Проверьте кэширование часто запрашиваемых данных

Профилирование включено

Проверьте, что журналирование медленных запросов активно

Наконец, сделайте привычкой проверять db.currentOp() во время инцидентов или при мониторинге деградированной производительности. Эта команда показывает активные операции, блокирующие запросы и время выполнения:

db.currentOp({ "active": true, "secs_running": { "$gt": 5 } })

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

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

Заключение

Оптимизация запросов MongoDB в Java-приложениях — это не разовая деятельность, а непрерывный процесс, который эволюционирует вместе с вашими данными, рабочей нагрузкой и функциями продукта. Каждый раздел этого руководства выделял разную часть этого процесса, начиная с профилирования и мониторинга, затем переходя через дизайн запросов, индексирование, избежание антипаттернов, агрегацию и готовность к production. Вместе эти техники образуют полный рабочий процесс, который помогает понять, как ведут себя ваши запросы и как безопасно их улучшить.

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

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

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.

Комментарии (0)