Конфигурации вычислений и хранилища для кластеров виртуальных ядер Azure Cosmos DB для MongoDB
Область применения: 
Виртуальные ядра MongoDB
Вычислительные ресурсы поставляются в виде виртуальных ядер, которые представляют собой логические ЦП основного оборудования. Размер хранилища для подготовки относится к емкости, доступной сегментам в кластере. Хранилище используется для файлов базы данных, временных файлов, журналов транзакций и журналов сервера базы данных. Вы можете самостоятельно выбрать параметры вычислений и хранилища. Выбранные значения вычислений и хранилища применяются к каждому сегменту в кластере.
Вычисление в Azure Cosmos DB для виртуальных ядер MongoDB
Общий объем ОЗУ в одном сегменте основан на выбранном количестве виртуальных ядер.
| Уровень кластера | Количество виртуальных ядер | Один сегмент, ГиБ ОЗУ |
|---|---|---|
| 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
Общий объем подготовленного хранилища также определяет емкость ввода-вывода, доступную для каждого сегмента в кластере.
| Размер хранилища в ГиБ | Максимальное значение 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 ГиБ включительно включает бесплатный диск с включенным ускорением.
Максимальное увеличение операций ввода-вывода в секунду для конфигурации вычислительных ресурсов или хранилища
Каждая конфигурация вычислений имеет ограничение операций ввода-вывода в секунду, зависящее от количества виртуальных ядер. Убедитесь, что вы выбрали конфигурацию вычислений для кластера, чтобы полностью использовать операции ввода-вывода в секунду в выбранном хранилище.
| Объем памяти | Объем операций ввода-вывода в секунду в хранилище до | Минимальный уровень вычислений | Минимальное число виртуальных ядер |
|---|---|---|---|
| До 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 виртуальных ядер |
† Максимальное число операций ввода-вывода в секунду с ускорением свободного диска. Хранилище до 512 ГиБ включительно включает бесплатный диск с включенным ускорением.
Например, если требуется 8 ТиБ хранилища на сегмент или больше, убедитесь, что для конфигурации вычислений узла выбрано 16 виртуальных ядер или больше. Этот выбор позволит максимально увеличить использование операций ввода-вывода в секунду, предоставляемое выбранным хранилищем.
Рекомендации по вычислению и хранилищу
Рекомендации по работе с набором и памятью
В Azure Cosmos DB для виртуального ядра MongoDB рабочий набор ссылается на часть ваших данных, к которым часто обращаются и используются приложениями. Он включает как данные, так и индексы, которые регулярно считываются или записываются во время типичных операций приложения. Концепция рабочего набора важна для оптимизации производительности, так как MongoDB, как и многие базы данных, лучше всего выполняется, когда рабочий набор подходит в ОЗУ.
Чтобы определить и понять рабочий набор базы данных MongoDB, рассмотрите следующие компоненты:
- Часто доступные данные: эти данные включают документы, которые приложение регулярно считывает или обновляет.
- Индексы: индексы, используемые в операциях запросов, также являются частью рабочего набора, так как их необходимо загрузить в память, чтобы обеспечить быстрый доступ.
- Шаблоны использования приложений. Анализ шаблонов использования приложения может помочь определить, к каким частям данных обращаются чаще всего.
Сохраняя рабочий набор в ОЗУ, можно свести к минимуму более медленные операции ввода-вывода диска, тем самым повышая производительность базы данных MongoDB. Если вы обнаружите, что рабочий набор превышает доступную ОЗУ, можно рассмотреть возможность оптимизации модели данных, добавления дополнительных ОЗУ или сегментирования для распределения данных между несколькими узлами.
Выбор оптимальной конфигурации для рабочей нагрузки
Определение правильной конфигурации вычислений и хранилища для рабочей нагрузки виртуальных ядер Azure Cosmos DB для MongoDB включает в себя оценку нескольких факторов, связанных с требованиями и шаблонами использования приложения. Основные шаги и рекомендации по определению оптимальной конфигурации:
Общие сведения о рабочей нагрузке
- Объем данных: оцените общий размер данных, включая индексы.
- Коэффициент чтения и записи: определение соотношения операций чтения и операций записи.
- Шаблоны запросов: анализ типов запросов, которые выполняет приложение. Например, простые операции чтения, сложные агрегаты.
- Параллелизм. Оцените количество параллельных операций, которые необходимо обрабатывать в базе данных.
Мониторинг текущей производительности
- Использование ресурсов. Используйте средства мониторинга для отслеживания ЦП, памяти, операций ввода-вывода диска и сетевого использования перед перемещением рабочей нагрузки в Azure и мониторинга метрик после запуска рабочей нагрузки MongoDB в кластере виртуальных ядер Azure Cosmos DB для MongoDB.
- Метрики производительности: отслеживайте ключевые показатели производительности, такие как задержка, пропускная способность и коэффициенты попаданий кэша.
- Узкие места. Определение существующих узких мест производительности, таких как высокая загрузка ЦП, давление памяти или медленный ввод-вывод диска.
Оценка требований к ресурсам
- Память. Убедитесь, что рабочий набор (часто доступ к данным и индексам) помещается в ОЗУ. Если размер рабочего набора превышает доступную память, попробуйте добавить больше ОЗУ или оптимизировать модель данных.
- ЦП: выберите конфигурацию ЦП, которая может обрабатывать требования к загрузке запросов и параллелизму. Для рабочих нагрузок с большим объемом ЦП может потребоваться больше ядер. Используйте метрику "Процент ЦП" с агрегированием Max в кластере виртуальных ядер Azure Cosmos DB для MongoDB, чтобы просмотреть исторические шаблоны использования вычислительных ресурсов.
- Операций ввода-вывода в секунду хранилища. Выберите хранилище с достаточным объемом операций ввода-вывода в секунду для обработки операций чтения и записи. Используйте метрику ввода-вывода в секунду с агрегированием Max в кластере, чтобы просмотреть использование операций ввода-вывода в секунду в хранилище.
- Сеть. Обеспечение достаточной пропускной способности сети для обработки передачи данных между приложением и базой данных, особенно для распределенных настроек. Убедитесь, что вы настроили узел для приложения MongoDB для поддержки ускоренных сетевых технологий, таких как SR-IOV.
Правильное масштабирование
- Вертикальное масштабирование: масштабирование вычислительных ресурсов или ОЗУ вверх и вниз и увеличение масштаба хранилища.
- Вычисление. Увеличьте виртуальные ядра или ОЗУ в кластере, если для рабочей нагрузки требуется временное увеличение или часто пересекает более 70 % использования ЦП в течение длительного периода.
- Убедитесь, что у вас есть соответствующее хранение данных в базе данных виртуальных ядер Azure Cosmos DB для MongoDB. Хранение позволяет избежать ненужного использования хранилища. Отслеживайте использование хранилища, задав оповещения для метрик "Процент хранения" и (или) "Использованное хранилище" с агрегированием Max. Рассмотрите возможность увеличения объема хранилища, так как размер рабочей нагрузки пересекает 70 % использования.
- Горизонтальное масштабирование. Рассмотрите возможность использования нескольких сегментов для кластера для распределения данных между несколькими узлами виртуальных ядер Azure Cosmos DB для MongoDB для повышения производительности и повышения производительности по мере роста рабочей нагрузки. Это особенно полезно для больших наборов данных (более 2–4 ТиБ) и приложений с высокой пропускной способностью.
- Вертикальное масштабирование: масштабирование вычислительных ресурсов или ОЗУ вверх и вниз и увеличение масштаба хранилища.
Тестирование и итерацию
- Тестирование. Выполните измерение для наиболее часто используемых запросов с различными конфигурациями, чтобы определить влияние на производительность. Используйте метрики ЦП/ОЗУ и метрики операций ввода-вывода в секунду и тестовые показатели на уровне приложения.
- Нагрузочное тестирование. Выполните нагрузочное тестирование для имитации рабочих нагрузок и проверьте производительность выбранной конфигурации.
- Непрерывный мониторинг. Непрерывно отслеживайте развертывание виртуальных ядер Azure Cosmos DB для MongoDB и настраивайте ресурсы по мере необходимости на основе изменения рабочих нагрузок и шаблонов использования.
Систематически оценивая эти факторы и постоянно отслеживая конфигурацию, вы можете убедиться, что развертывание MongoDB хорошо оптимизировано для конкретной рабочей нагрузки.
Рекомендации по службе хранилища
Выбор подходящего размера хранилища для рабочей нагрузки включает несколько рекомендаций, чтобы обеспечить оптимальную производительность и масштабируемость. Ниже приведены рекомендации по размеру хранилища в Azure Cosmos DB для виртуальных ядер MongoDB:
Оценка размера данных:
- Вычислите ожидаемый размер данных виртуального ядра Azure Cosmos DB для MongoDB. Рассматривать:
- Текущий размер данных: при миграции из существующей базы данных.
- Скорость роста: оцените, сколько данных будет добавлено с течением времени.
- Размер документа и структура. Понимание схемы данных и размеров документов, так как они влияют на эффективность хранения.
- Вычислите ожидаемый размер данных виртуального ядра Azure Cosmos DB для MongoDB. Рассматривать:
Фактор в индексах:
- Виртуальные ядра Azure Cosmos DB для MongoDB используют индексы для эффективного запроса. Индексы используют дополнительное место на диске.
- Оцените размер индексов на основе:
- Число индексов.
- Размер индексированных полей.
Рекомендации по производительности:
- Производительность диска влияет на операции базы данных, особенно для рабочих нагрузок, которые не могут соответствовать их рабочему набору в ОЗУ. Рассматривать:
- Пропускная способность ввода-вывода: операции ввода-вывода или операции ввода-вывода в секунду — это количество запросов, отправляемых на диски хранилища в одну секунду. Более крупный размер хранилища поставляется с большим количеством операций ввода-вывода в секунду. Убедитесь, что достаточная пропускная способность для операций чтения и записи. Используйте метрику ввода-вывода в секунду с агрегированием Max для мониторинга используемых операций ввода-вывода в кластере.
- Задержка. Задержка — это время, которое требуется приложению для получения одного запроса, отправки его на диски хранилища и отправки ответа клиенту. Задержка является критической мерой производительности приложения в дополнение к операций ввода-вывода в секунду и пропускной способности. Задержка в значительной степени определяется типом используемого хранилища и конфигурацией хранилища. В управляемой службе, такой как Azure Cosmos DB для MongoDB, быстрое хранилище, например диски SSD уровня "Премиум", используется с параметрами, оптимизированными для уменьшения задержки.
- Производительность диска влияет на операции базы данных, особенно для рабочих нагрузок, которые не могут соответствовать их рабочему набору в ОЗУ. Рассматривать:
Будущий рост и масштабируемость:
- Планирование будущих потребностей в росте и масштабируемости данных.
- Выделите больше места на диске за пределами текущих потребностей, чтобы обеспечить рост без частых расширений хранилища.
Пример вычисления:
- Предположим, что исходный размер данных составляет 500 ГиБ.
- С индексами он может увеличиться до 700 ГиБ.
- Если вы ожидаете удвоение данных за два года, планируйте на 1,4 ТиБ (700 ГиБ * 2).
- Добавьте буфер для затрат, роста и операционных потребностей.
- Вы можете начать с 1 ТиБ хранилища сегодня и масштабировать его до 2 ТиБ, как только его размер растет более 800 ГиБ.
Выбор размера хранилища включает сочетание оценки текущих и будущих потребностей данных, рассмотрения индексирования и сжатия, а также обеспечения достаточной производительности и масштабируемости. Регулярный мониторинг и корректировка на основе фактических тенденций использования и роста также важны для поддержания оптимальной производительности MongoDB.