Конфигурации вычислений и хранилища для кластеров виртуальных ядер Azure Cosmos DB для MongoDB

2025-05-30
Применяется к: ✅ MongoDB (vCore)

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

Вычисление в Azure Cosmos DB для виртуальных ядер MongoDB

Общий объем ОЗУ в одном шарде определяется выбранным количеством виртуальных ядер.

Уровень кластера	Количество виртуальных ядер	Один шард, ГиБ ОЗУ
M10	1 (с возможностью увеличения)	2
M20	2 (с возможностью ускорения)	4
M25	2 (с возможностью ускорения)	8
M30	2	8
M40	4	16
M50	8	32
M60	16	64
M80	32	128
M200	64	256

Хранилище в Azure Cosmos DB с поддержкой MongoDB vCore

Общий объем подготовленного хранилища также определяет емкость ввода-вывода, доступную для каждого сегмента в кластере.

Размер хранилища в ГиБ	Максимальное значение IOPS
32	3,500†
64	3,500†
128	3,500†
256	3,500†
512	3,500†
1024	5 000
2048	7500
4095	7500
8,192	16 000
16,384	18 000
32 767	20 000

† Максимальное число операций ввода-вывода в секунду с ускорением свободного диска. Хранилище объемом до 512 ГиБ включительно включает бесплатную функцию Burst.

Максимизация операций ввода-вывода в секунду (IOPS) для конфигурации вычислительных ресурсов и хранилища.

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

Объем памяти	Объем операций ввода-вывода в секунду в хранилище до	Минимальный уровень вычислений	Минимальное число vCores
До 0,5 ТиБ	3,500†	M30	2 виртуальных ядра
1 ТиБ	5 000	M40	Виртуальные ядра: 4
2 ТиБ	7500	M50	виртуальные процессоры: 8
4 ТиБ	7500	M50	виртуальные процессоры: 8
8 ТиБ	16 000	M60	16 виртуальных ядер
16 ТиБ	18 000	M60	16 виртуальных ядер
32 ТиБ	20 000	M60	16 виртуальных ядер

Например, если требуется 8 ТиБ хранилища на сегмент или больше, убедитесь, что для конфигурации вычислений узла выбрано 16 виртуальных ядер или больше. Этот выбор позволит максимально увеличить использование операций ввода-вывода в секунду, предоставляемое выбранным хранилищем.

Рекомендации по вычислению и хранилищу

Рассмотрение рабочего множества и памяти

В Azure Cosmos DB для MongoDB на базе виртуальных ядер рабочий набор обозначает ту часть ваших данных, к которой часто обращаются и которую используют ваши приложения. Он включает как данные, так и индексы, которые регулярно считываются или записываются во время типичных операций приложения. Концепция рабочего набора важна для оптимизации производительности, так как MongoDB, как и многие базы данных, лучше всего работает, когда рабочий набор умещается в ОЗУ.

Чтобы определить и понять рабочий набор базы данных MongoDB, рассмотрите следующие компоненты:

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

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

Выбор оптимальной конфигурации для рабочей нагрузки

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

Общие сведения о рабочей нагрузке
- Объем данных: оцените общий размер данных, включая индексы.
- Коэффициент чтения и записи: определение соотношения операций чтения и операций записи.
- Шаблоны запросов: анализ типов запросов, которые выполняет приложение. Например, простые операции чтения, сложные агрегирования.
- Параллелизм. Оцените количество параллельных операций, которые необходимо обрабатывать в базе данных.
Мониторинг текущей производительности
- Использование ресурсов. Используйте средства мониторинга для отслеживания ЦП, памяти, операций ввода-вывода диска и сетевого использования перед перемещением рабочей нагрузки в Azure и мониторинга метрик после запуска рабочей нагрузки MongoDB в кластере виртуальных ядер Azure Cosmos DB для MongoDB.
- Метрики производительности: отслеживайте ключевые показатели производительности, такие как задержка, пропускная способность и коэффициенты попаданий кэша.
- Узкие места. Определение существующих узких мест производительности, таких как высокая загрузка ЦП, давление памяти или медленный ввод-вывод диска.
Оценка требований к ресурсам
- Память. Убедитесь, что рабочий набор (часто доступ к данным и индексам) помещается в ОЗУ. Если размер рабочего набора превышает доступную память, попробуйте добавить больше ОЗУ или оптимизировать модель данных.
- ЦП: выберите конфигурацию ЦП, которая может обрабатывать требования к загрузке запросов и параллелизму. Для рабочих нагрузок с большим объемом ЦП может потребоваться больше ядер. Используйте метрику "Процент ЦП" с агрегированием Max в кластере виртуальных ядер Azure Cosmos DB для MongoDB, чтобы просмотреть исторические шаблоны использования вычислительных ресурсов.
- IOPS хранилища: выберите хранилище с достаточным количеством операций ввода-вывода для обработки операций чтения и записи. Используйте метрику 'IOPS' с агрегированием 'Max' в вашем кластере, чтобы увидеть историческое использование IOPS хранилища.
- Сеть. Обеспечение достаточной пропускной способности сети для обработки передачи данных между приложением и базой данных, особенно для распределенных настроек. Убедитесь, что вы настроили сервер для вашего приложения MongoDB для поддержки технологий ускоренных сетей, таких как SR-IOV.
Правильное масштабирование
- Вертикальное масштабирование: масштабирование вычислительных ресурсов или ОЗУ вверх и вниз и увеличение масштаба хранилища.
  - Ресурсы: Увеличьте количество виртуальных ядер или объём ОЗУ в кластере, если нагрузке временно требуется увеличение ресурсов или часто превышается использование ЦП выше 70 % в течение длительного периода.
  - Убедитесь, что у вас есть соответствующее хранение данных в базе данных виртуальных ядер Azure Cosmos DB для MongoDB. Хранение позволяет избежать ненужного использования хранилища. Отслеживайте использование хранилища, задав оповещения для метрик "Процент хранения" и (или) "Использованное хранилище" с агрегированием Max. Рассмотрите возможность увеличения объема хранилища, так как размер рабочей нагрузки пересекает 70 % использования.
- Горизонтальное масштабирование: Рассмотрите возможность использования нескольких шардов для вашего кластера, чтобы распределить данные между несколькими узлами vCore Azure Cosmos DB для MongoDB, улучшая производительность и управление емкостью по мере увеличения рабочей нагрузки. Это особенно полезно для больших наборов данных (более 2–4 ТиБ) и приложений с высокой пропускной способностью.
Тестирование и итерацию
- Тестирование. Выполните измерение для наиболее часто используемых запросов с различными конфигурациями, чтобы определить влияние на производительность. Используйте метрики ЦП/ОЗУ и метрики операций ввода-вывода в секунду и тестовые показатели на уровне приложения.
- Нагрузочное тестирование. Выполните нагрузочное тестирование для имитации рабочих нагрузок и проверьте производительность выбранной конфигурации.
- Непрерывный мониторинг. Непрерывно отслеживайте развертывание виртуальных ядер Azure Cosmos DB для MongoDB и настраивайте ресурсы по мере необходимости на основе изменения рабочих нагрузок и шаблонов использования.

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

Соображения для хранения

Выбор подходящего размера хранилища для рабочей нагрузки включает несколько рекомендаций, чтобы обеспечить оптимальную производительность и масштабируемость. Ниже приведены рекомендации по размеру хранилища в Azure Cosmos DB для виртуальных ядер MongoDB:

Оценка размера данных:
- Вычислите ожидаемый размер данных виртуального ядра Azure Cosmos DB для MongoDB. Рассмотрите
  - Текущий размер данных: при миграции из существующей базы данных.
  - Скорость роста: оцените, сколько данных будет добавлено с течением времени.
  - Размер документа и структура. Понимание схемы данных и размеров документов, так как они влияют на эффективность хранения.
Фактор в индексах:
- Виртуальные ядра Azure Cosmos DB для MongoDB используют индексы для эффективного выполнения запросов. Индексы используют дополнительное место на диске.
- Оцените размер индексов на основе:
  - Число индексов.
  - Размер индексированных полей.
Рекомендации по производительности:
- Производительность диска влияет на операции с базой данных, особенно для рабочих нагрузок, которые не могут поместить свой рабочий набор в ОЗУ. Рассмотрите
  - Пропускная способность ввода-вывода: IOPS, или операции ввода-вывода в секунду, определяет количество запросов, отправляемых на диски хранения за одну секунду. Более крупный размер хранилища сопровождается большим количеством IOPS (операций ввода-вывода в секунду). Убедитесь в наличии достаточной пропускной способности для операций чтения и записи. Используйте метрику IOPS с агрегированием Max для мониторинга используемых операций ввода-вывода в вашем кластере.
  - Задержка. Задержка — это время, которое требуется приложению для получения одного запроса, отправки его на диски хранилища и отправки ответа клиенту. Задержка является критической мерой производительности приложения в дополнение к IOPS и пропускной способности. Задержка в значительной степени определяется типом используемого хранилища и конфигурацией хранилища. В управляемой службе, такой как Azure Cosmos DB для MongoDB, быстрое хранилище, например диски SSD уровня "Премиум", используется с параметрами, оптимизированными для уменьшения задержки.
Будущий рост и масштабируемость:
- Планирование будущих потребностей в росте и масштабируемости данных.
- Выделите больше места на диске за пределами текущих потребностей, чтобы обеспечить рост без частых расширений хранилища.
Пример вычисления:
- Предположим, что исходный размер данных составляет 500 ГиБ.
- С индексами он может увеличиться до 700 ГиБ.
- Если вы ожидаете удвоение данных за два года, планируйте на 1,4 ТиБ (700 ГиБ * 2).
- Добавьте буфер для затрат, роста и операционных потребностей.
- Вы можете начать с 1 ТиБ хранилища сегодня и масштабировать его до 2 ТиБ, как только его размер растет более 800 ГиБ.

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

Следующие шаги

Варианты миграции для Azure Cosmos DB for MongoDB vCore