Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Вычислительные ресурсы Azure DocumentDB предоставляются в виде виртуальных ядер, представляющих логический ЦП базового оборудования. Размер хранилища для подготовки относится к емкости, доступной сегментам в кластере.
Хранилище используется для файлов базы данных, временных файлов, журналов транзакций и журналов сервера базы данных. Вы можете самостоятельно выбрать параметры вычислений и хранилища. Выбранные значения вычислений и хранилища применяются к каждому сегменту в кластере.
Вычисления в Azure DocumentDB
Общий объем ОЗУ в одном шарде основан на выбранном количестве виртуальных ядер.
| Уровень кластера | vCores | Один шард, ГиБ ОЗУ |
|---|---|---|
| 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 DocumentDB
Общий объем хранилища, который вы назначаете, также определяет емкость ввода-вывода, доступную для каждого сегмента в кластере.
| Размер хранилища, ГиБ | Максимальное значение IOPS |
|---|---|
| 32 | 3,500† |
| 64 | 3,500† |
| 128 | 3,500† |
| 256 | 3,500† |
| 512 | 3,500† |
| 1,024 | 5,000 |
| 2,048 | 7,500 |
| 4,095 | 7,500 |
| 8,192 | 16,000 |
| 16,384 | 18,000 |
| 32,767 | 20,000 |
† максимальное количество IOPS (операций ввода-вывода в секунду) с бесплатным ускорением диска. Хранилище объемом до 512 ГиБ включительно имеет функцию автоматического увеличения производительности диска бесплатно.
Максимизация показателя IOPS для конфигурации вычислительных и хранилищных ресурсов
Каждая конфигурация вычислений имеет ограничение операций ввода-вывода в секунду, зависящее от количества виртуальных ядер. Убедитесь, что вы выбрали конфигурацию вычислений для вашего кластера, чтобы полностью использовать IOPS в выбранном хранилище.
| Объем памяти | IOPS хранилища, до | Минимальный уровень вычислений | Минимальные виртуальные ядра |
|---|---|---|---|
| До 0,5 ТиБ | 3,500† | M30 | 2 виртуальных ядра |
| 1 ТиБ | 5,000 | M40 | 4 виртуальных ядра |
| 2 ТиБ | 7,500 | M50 | 8 виртуальных ядер |
| 4 ТиБ | 7,500 | M50 | 8 виртуальных ядер |
| 8 ТиБ | 16,000 | M60 | 16 виртуальных процессоров |
| 16 ТиБ | 18,000 | M60 | 16 виртуальных процессоров |
| 32 ТиБ | 20,000 | M60 | 16 виртуальных процессоров |
† Максимальное число операций ввода-вывода в секунду с ускорением свободного диска. Хранилище объемом до 512 ГиБ включительно предоставляет бесплатное временное ускорение (bursting) для диска.
Например, если требуется 8 ТиБ хранилища на сегмент или больше, убедитесь, что для конфигурации вычислений узла выбрано 16 виртуальных ядер или больше. Этот выбор позволит максимально увеличить использование операций ввода-вывода в секунду, предоставляемое выбранным хранилищем.
Рекомендации по вычислению и хранилищу
При настройке кластера Azure DocumentDB важно понимать, как выбор вычислений и хранилища влияет на производительность, затраты и масштабируемость для конкретной рабочей нагрузки.
Рассмотрение рабочего набора и аспектов памяти
В Azure DocumentDB рабочий набор ссылается на часть ваших данных, к которым часто обращаются и используются приложениями. Он включает как данные, так и индексы, которые регулярно считываются или записываются во время типичных операций приложения. Концепция рабочего набора важна для оптимизации производительности, так как MongoDB, как и многие базы данных, работает более эффективно, когда рабочий набор помещается в оперативной памяти.
Чтобы определить и понять рабочий набор базы данных MongoDB, рассмотрите следующие компоненты:
- Часто доступные данные: эти данные включают документы, которые приложение регулярно считывает или обновляет.
- Индексы: индексы, используемые в операциях запросов, также являются частью рабочего набора, так как их необходимо загрузить в память, чтобы обеспечить быстрый доступ.
- Шаблоны использования приложений. Анализ шаблонов использования приложения может помочь определить, к каким частям данных обращаются чаще всего.
Сохраняя рабочий набор в ОЗУ, можно свести к минимуму более медленные операции ввода-вывода диска, что повышает производительность базы данных MongoDB. Если рабочий набор превышает доступную ОЗУ, рассмотрите возможность оптимизации модели данных, добавление большего объема ОЗУ в кластер или сегментирование для распределения данных между несколькими узлами.
Выбор оптимальной конфигурации для рабочей нагрузки
Определение правильной конфигурации вычислений и хранилища для рабочей нагрузки Azure DocumentDB включает в себя оценку нескольких факторов, связанных с требованиями и шаблонами использования приложения. Основные шаги и рекомендации по определению оптимальной конфигурации:
Общие сведения о рабочей нагрузке
- Объем данных: оцените общий размер данных, включая индексы.
- Коэффициент чтения и записи: определение соотношения операций чтения с операциями записи.
- Шаблоны запросов: анализ типов запросов, которые выполняет приложение. Например, простые операции чтения, сложные агрегации.
- Параллелизм. Оцените количество параллельных операций, которые необходимо обрабатывать в базе данных.
Мониторинг текущей производительности
- Использование ресурсов. Используйте средства мониторинга для отслеживания ЦП, памяти, операций ввода-вывода диска и сетевого использования перед переносом рабочей нагрузки в Azure. После развертывания рабочей нагрузки MongoDB в кластере Azure DocumentDB продолжайте мониторинг с помощью метрик мониторинга Azure.
- Метрики производительности: отслеживайте ключевые показатели производительности, такие как задержка, пропускная способность и коэффициенты попаданий кэша.
- Узкие места. Определение существующих узких мест производительности, таких как высокая загрузка ЦП, давление памяти или медленный ввод-вывод диска.
Оценка требований к ресурсам
- Память. Убедитесь, что рабочий набор (часто доступ к данным и индексам) помещается в ОЗУ. Если размер рабочего набора превышает доступную память, попробуйте добавить больше ОЗУ или оптимизировать модель данных.
- ЦП: выберите конфигурацию ЦП, которая может обрабатывать требования к загрузке запросов и параллелизму. Для рабочих нагрузок с большим объемом ЦП может потребоваться больше ядер. Используйте метрику "Процент ЦП" с агрегированием Max в кластере Azure DocumentDB, чтобы просмотреть исторические шаблоны использования вычислений.
- IOPS (операции ввода-вывода в секунду): Выберите хранилище с достаточным количеством операций ввода-вывода в секунду для обработки операций чтения и записи. Используйте метрику операций ввода-вывода в секунду (IOPS) с агрегированием Max в кластере, чтобы просмотреть историческое использование операций ввода-вывода в секунду в хранилище.
- Сеть. Обеспечение достаточной пропускной способности сети для обработки передачи данных между приложением и базой данных, особенно для распределенных настроек. Убедитесь, что вы настроили хост для вашего приложения MongoDB для поддержки таких технологий, как ускоренная работа в сети, таких как SR-IOV.
Правильное масштабирование
-
Вертикальное масштабирование: масштабирует вычислительные ресурсы и ОЗУ вверх и вниз и масштабирует хранилище вверх.
- Увеличьте количество виртуальных ядер или объём ОЗУ в кластере, если ваше рабочее задание требует временного увеличения ресурсов или регулярно превышает 70% использования процессора на протяжении длительных периодов.
- Убедитесь, что в базе данных Azure DocumentDB есть соответствующее хранение данных. Хранение позволяет избежать ненужного использования хранилища. Отслеживайте использование хранилища, задав оповещения для метрик "Процент хранения" и (или) "Использованное хранилище" с агрегированием Max. Рассмотрите возможность увеличения объема хранилища, так как размер рабочей нагрузки пересекает 70% использования.
- Горизонтальное масштабирование. Рассмотрите возможность использования нескольких сегментов для кластера для распределения данных между несколькими узлами Azure DocumentDB для повышения производительности и улучшения управления емкостью по мере роста рабочей нагрузки. Это масштабирование особенно полезно для больших наборов данных (более 2–4 ТиБ) и приложений с высокой пропускной способностью.
-
Вертикальное масштабирование: масштабирует вычислительные ресурсы и ОЗУ вверх и вниз и масштабирует хранилище вверх.
Тестируйте и итерайте
- Тестирование. Выполните измерение для наиболее часто используемых запросов с различными конфигурациями, чтобы определить влияние на производительность. Используйте метрики ЦП/ОЗУ и метрики операций ввода-вывода в секунду и тестовые показатели на уровне приложения.
- Нагрузочное тестирование. Выполните нагрузочное тестирование для имитации рабочих нагрузок и проверьте производительность выбранной конфигурации.
- Непрерывный мониторинг. Непрерывно отслеживайте развертывание Azure DocumentDB и настраивайте ресурсы по мере необходимости на основе изменяющихся рабочих нагрузок и шаблонов использования.
Систематически оценивая эти факторы и постоянно отслеживая конфигурацию, вы можете убедиться, что развертывание MongoDB хорошо оптимизировано для конкретной рабочей нагрузки.
Рекомендации по хранению
Выбор подходящего размера хранилища для рабочей нагрузки включает несколько рекомендаций, чтобы обеспечить оптимальную производительность и масштабируемость. Ниже приведены рекомендации по размеру хранилища в Azure DocumentDB:
Оценка размера данных:
- Вычислите ожидаемый размер данных Azure DocumentDB. Рассмотрите:
- Текущий размер данных: При миграции из существующей базы данных.
- Темп роста: Оцените, сколько данных будет добавлено с течением времени.
- Размер документа и структура: Изучите схему данных и размеры документов, так как они влияют на эффективность хранения.
- Вычислите ожидаемый размер данных Azure DocumentDB. Рассмотрите:
Фактор в индексах:
- Azure DocumentDB использует индексы для эффективного запроса. Индексы используют дополнительное место на диске.
- Оцените размер индексов на основе:
- Число индексов.
- Размер индексированных полей.
Рекомендации по производительности:
- Производительность диска влияет на операции базы данных, особенно для рабочих нагрузок, которые не умещаются в рабочий набор в ОЗУ. Рассмотрите:
- Пропускная способность ввода-вывода: Операции ввода-вывода или операции ввода-вывода в секунду — это количество запросов, отправляемых на диски хранилища в одну секунду. Более крупный размер хранилища сопровождается большим количеством IOPS. Убедитесь, что пропускная способность для операций чтения и записи является достаточной. Используйте метрику IOPS с агрегированием Max для мониторинга используемых операций ввода-вывода в кластере.
- Задержка: Задержка — это время, которое требуется приложению для получения одного запроса, отправки его на диски хранилища и отправки ответа клиенту. Задержка является критической мерой производительности приложения в дополнение к операциям ввода-вывода в секунду и пропускной способности. Тип используемого хранилища и конфигурации хранилища в значительной степени определяет задержку. В управляемой службе, такой как Azure DocumentDB, быстрое хранилище, например диски SSD уровня "Премиум", используется с параметрами, оптимизированными для уменьшения задержки.
- Производительность диска влияет на операции базы данных, особенно для рабочих нагрузок, которые не умещаются в рабочий набор в ОЗУ. Рассмотрите:
Будущий рост и масштабируемость:
- Планирование будущих потребностей в росте и масштабируемости данных.
- Выделите больше места на диске за пределами текущих потребностей, чтобы обеспечить рост без частых расширений хранилища.
Пример вычисления:
- Предположим, что исходный размер данных составляет 500 ГиБ.
- С индексами он может увеличиться до 700 ГиБ.
- Если вы ожидаете удвоение данных за два года, планируйте на 1,4 ТиБ (700 ГиБ * 2).
- Добавьте буфер для затрат, роста и операционных потребностей.
- Вы можете начать с 1-ТиБ хранилища сегодня и масштабировать его до 2 ТиБ, как только его размер растет более 800 ГиБ.
Выбор размера хранилища включает сочетание оценки текущих и будущих потребностей данных, рассмотрения индексирования и сжатия, а также обеспечения достаточной производительности и масштабируемости. Регулярный мониторинг и корректировка на основе фактических тенденций использования и роста также важны для поддержания оптимальной производительности MongoDB.
Что такое ресурсоемкие вычислительные ресурсы?
Уровень burstable предлагает интеллектуальное решение, адаптированное для небольших нагрузок баз данных. Обеспечивая минимальную производительность ЦП во время простоя, эти кластеры оптимизируют использование ресурсов. Тем не менее, настоящая эффективность заключается в их способности легко масштабироваться до полной мощности ЦП в ответ на возрастающий спрос на трафик или увеличение рабочей нагрузки. Эта адаптация обеспечивает пиковую производительность точно при необходимости, обеспечивая значительную экономию затрат.
Снижая начальную ценовую точку услуги, уровень Burstable Cluster Tier Azure DocumentDB направлен на упрощение подключения пользователей и изучение возможностей Azure DocumentDB по сниженным ценам. Эта демократизация доступа позволяет предприятиям всех размеров использовать возможности Azure DocumentDB, не превышая бюджет. Независимо от того, является ли вы стартапом, небольшим бизнесом или предприятием, этот уровень открывает новые возможности для экономичной масштабируемости.
Подготовка масштабируемого уровня столь же проста, как и подготовка регулярных уровней; в параметре уровня кластера нужно выбрать "M10", "M20" или "M25". Ниже приведено краткое руководство по настройке кластера Azure DocumentDB .