Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
Область применения: MongoDB
Оптимизация производительности записи помогает получить большую часть azure Cosmos DB для неограниченного масштаба MongoDB. В отличие от других управляемых служб MongoDB, API для MongoDB автоматически и прозрачно сегментирует коллекции (при использовании сегментированных коллекций) для бесконечного масштабирования.
Способ записи данных должен учитывать этот факт за счет паралеллизации и распределения данных по сегментам для максимизации числа операций записи для баз данных и коллекций. В этой статье приведены рекомендации по оптимизации производительности записи.
Распределение нагрузки по сегментам
При записи данных в сегментированную коллекцию API для MongoDB данные разбиваются (сегментируются) на мелкие срезы и записываются в каждый сегмент на основе значения в поле ключа сегмента. Каждый срез можно считать небольшой частью виртуальной машины, в которой хранятся только документы, содержащие одно уникальное значение ключа сегмента.
Если приложение записывает большой объем данных в один сегмент, это является неэффективным решением, так как приложение будет использовать по максимуму пропускную способность только одного сегмента вместо того, чтобы распределять нагрузку по всем сегментам. Нагрузка по записи равномерно распределяется по всей коллекции путем параллельной записи данных во множество документов с уникальными значениями ключей сегментов.
Одним из примеров является приложение с каталогом продуктов, сегментированное по полю "Категория". Вместо записи в одну категорию (сегмент) в каждый момент времени лучше выполнить запись сразу во все категории, чтобы добиться максимальной пропускной способности записи.
Сокращение числа индексов
Индексирование — это отличная функция, значительно уменьшающая время на запрос данных. Для максимально гибкого обслуживания запросов в API для MongoDB по умолчанию включен индекс по данным с подстановочными знаками, чтобы невероятно ускоряет обработку запросов ко всем полям. Однако все индексы, в том числе с подстановочными знаками, повышают нагрузку при записи данных, поскольку операции записи изменяют как коллекцию, так и индексы.
Снижение числа индексов до минимума, необходимого для обслуживания ваших запросов, позволяет ускорить и удешевить операции записи. Таким образом, мы рекомендуем сделать следующее:
- У любого поля, по которому выполняется фильтрация, должен быть индекс по одному полю. Это также позволяет выполнять фильтрацию по нескольким полям.
- У любой группы полей, по которым выполняется сортировка, должен быть составной индекс.
Установите для параметра ordered в драйверах MongoDB значение false.
По умолчанию драйверы MongoDB устанавливают для параметра ordered при записи данных значение true, в результате чего каждый документ записывается последовательно. Это снижает производительность записи, поскольку каждый следующий запрос на запись должен ожидать завершения предыдущего. Чтобы повысить производительность, задайте для этого параметра при записи данных значение false.
db.collection.insertMany(
[ <doc1> , <doc2>, ... ],
{
ordered: false
}
)
Настройка оптимального размера пакета и числа потоков
Ключом к масштабированию операций записи является параллельное выполнение операций записи во многих потоках и процессах. API для MongoDB принимает записи в пакетах размером до 1000 документов для каждого процесса или потока.
Если вы записываете одновременно более 1000 документов для каждого процесса или потока, для клиентских функций, например insertMany(), должно быть установлено примерное ограничение в 1000 документов. В противном случае клиент будет ожидать фиксации каждого пакета перед переходом к следующему. В некоторых случаях работу ускоряет разделение пакетов с числом документов меньше или чуть больше 1000.
Следующие шаги
- Узнайте больше об индексировании в API для MongoDB.
- Узнайте больше о секционировании в Azure Cosmos DB.
- Узнайте больше об устранении распространенных неполадок.
- Если вы планируете ресурсы для миграции в Azure Cosmos DB, Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.
- Если вам известно только количество виртуальных ядер и серверов в существующем кластере баз данных, прочитайте об оценке единиц запроса на основе этих данных.
- Если вам известна стандартная частота запросов для текущей рабочей нагрузки базы данных, ознакомьтесь со статьей о расчете единиц запросов с помощью планировщика ресурсов Azure Cosmos DB