Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье приведены рекомендации по использованию пакета SDK Azure Cosmos DB для Java. С их помощью можно уменьшить задержку, повысить доступность и общую производительность.
Checklist
| Проверено | Topic | Сведения/ссылки |
|---|---|---|
| Версия пакета SDK | Всегда используйте последнюю версию пакета SDK Azure Cosmos DB, доступную для оптимальной производительности. | |
| Одиночный клиент | Для оптимальной производительности используйте CosmosClient на протяжении времени существования приложения. |
|
| Регионы | Чтобы сократить задержку, запускайте приложение в том же регионе Azure, что и учетная запись Azure Cosmos DB, если это возможно. Для повышения доступности включите 2–4 региона и репликацию учетных записей в нескольких регионах. Для производственных нагрузок включите переключение при отказе, управляемое службой. При отсутствии этой конфигурации учетная запись потеряет возможность записи на весь период сбоя в регионе записи, поскольку ручной переход не будет успешным из-за отсутствия подключенности к региону. Дополнительные сведения о добавлении нескольких регионов с помощью пакета SDK для Java см. здесь. | |
| Доступность и переключение на резервную систему | Задайте preferredRegions в пакете SDK версии 4. Во время сбоя операции записи отправляются в текущий регион записи, а все операции чтения — в первый регион в списке предпочтительных регионов. Дополнительные сведения о региональных механизмах аварийного переключения см. в руководстве по обеспечению доступности. | |
| ЦП | Вы можете столкнуться с проблемами подключения или доступности из-за недостатка ресурсов на клиентском компьютере. Отслеживайте использование ЦП на узлах, на которых работает клиент Azure Cosmos DB, и увеличивайте масштаб вертикально/горизонтально, если уровень использования ресурсов очень высок. | |
| Хостинг | Для наиболее распространенных вариантов с производственными рабочими нагрузками мы настоятельно рекомендуем по возможности использовать как минимум 4-ядерные и 8-гигабайтные виртуальные машины с памятью. | |
| Режимы подключения | Для оптимальной производительности используйте режим прямого подключения. Соответствующие инструкции см. в документации по пакету SDK версии 4. | |
| Networking | Если вы используете для запуска приложения виртуальную машину, включите на ней ускорение сети, чтобы устранить узкие места при большом объеме трафика и уменьшить задержку или нагрузку на ЦП. Кроме того, можно использовать конечную виртуальную машину более высокого класса, где максимальная загрузка ЦП будет составлять менее 70 %. | |
| Истощение эфемерных портов | Для редких и периодических подключений рекомендуется установить более высокое значение idleEndpointTimeout. Свойство idleEndpointTimeout в DirectConnectionConfig помогает управлять временем закрытия неиспользуемых подключений. Это позволяет сократить их количество. По умолчанию неактивные подключения к конечной точке остаются открытыми в течение одного часа. Если нет запросов к определенной конечной точке в течение времени ожидания простоя конечной точки, прямой клиент закрывает все подключения к этой конечной точке для экономии ресурсов и затрат на операции ввода-вывода. |
|
| Использование надлежащего планировщика (избегайте перехвата потоков цикла обработки событий ввода-вывода netty) | Избегайте блокирующих вызовов: .block(). Весь стек вызовов является асинхронным, чтобы получить преимущества от шаблонов асинхронного API и использования соответствующих потоков и планировщиков. |
|
| Сквозное время ожидания | Чтобы получить сквозные тайм-ауты, реализуйте политику сквозного тайм-аута в SDK для Java. Дополнительные сведения о времени ожидания с помощью Azure Cosmos DB см. здесь | |
| Логика повторных попыток | Временная ошибка — это ошибка, причина которой быстро устраняется сама собой. При разработке приложений, которые подключаются к вашей базе данных, необходимо учитывать возможность появления этих временных ошибок и предусматривать их обработку путем реализации логики повторных попыток в коде вместо вывода пользователю сообщений об ошибках приложения. В SDK есть встроенная логика обработки таких временных ошибок в повторяемых запросах, таких как операции чтения или запроса. Пакет SDK не будет повторять попытки записи при временных сбоях, поскольку эти операции не являются идемпотентными. В SDK пользователи могут настраивать логику повторных попыток для регулирования. Дополнительные сведения о том, для каких ошибок нужны повторные попытки, см. здесь. | |
| Кэширование имен баз данных и коллекций | Извлеките имена ваших баз данных и контейнеров из конфигурации или кэшируйте их при запуске. Вызовы, такие как CosmosAsyncDatabase#read() или CosmosAsyncContainer#read(), приводят к вызовам метаданных службы, которые потребляют зарезервированное системой ограничение на RU.
createDatabaseIfNotExists() также следует использовать только один раз для настройки базы данных. Не стоит выполнять эти операции слишком часто. |
|
| Параллельные запросы | Пакет SDK Azure Cosmos DB поддерживает параллельное выполнение запросов для повышения задержки и пропускной способности в запросах. Рекомендуется задавать для свойства maxDegreeOfParallelism в CosmosQueryRequestsOptions значение, равное числу разделов. Если вы не знаете количество секций, установите значение -1, которое обеспечит оптимальную задержку. Кроме того, задайте для параметра maxBufferedItemCount значение ожидаемого числа возвращаемых результатов, чтобы ограничить число предварительно выбираемых результирующих записей. |
|
| Задержки при тестировании производительности | При тестировании в приложении следует реализовать задержки с интервалом RetryAfter. Соблюдение пауз между попытками помогает минимизировать время ожидания между повторными попытками. |
|
| Индексирование | Политика индексирования Azure Cosmos DB также позволяет добавлять пути к документам или исключать их из индексирования с помощью путей индексирования IndexingPolicy#getIncludedPaths() и IndexingPolicy#getExcludedPaths(). Исключите из индексирования неиспользуемые пути, чтобы ускорить выполнение операций записи. Пример создания индексов с помощью пакета SDK см. здесь. |
|
| Размер документа | Плата за запрос (т. е. затраты на обработку запросов) указанной операции напрямую зависит от размера документа. Рекомендуется уменьшить размер документов, так как операции с большими документами стоят больше, чем с меньшими. | |
| Размер страницы | По умолчанию результаты запроса возвращаются в блоках из 100 элементов или 4 МБ, в зависимости от того, какое ограничение сначала достигается. Если запрос вернет более 100 элементов, увеличьте размер страницы, чтобы уменьшить количество необходимых круговых путей. Потребление памяти увеличивается по мере увеличения размера страницы. | |
| Включение метрик запроса | Чтобы включить дополнительное ведение журнала выполнения серверных запросов, следуйте инструкциям по сбору метрик SQL-запросов с помощью пакета SDK для Java. | |
| Ведение журнала для пакета SDK | Ведение журнала пакета SDK позволяет фиксировать дополнительные диагностические сведения и помогает устранять проблемы с задержкой. Зайдите в журнал CosmosDiagnostics в пакете SDK java для получения более подробных диагностических сведений об Azure Cosmos DB для текущего запроса в службу. В качестве примерного варианта использования сохраняйте диагностические сведения обо всех исключениях и завершенных операциях, если значение CosmosDiagnostics#getDuration() больше заданного порога (т. е. при наличии соглашения об уровне обслуживания с указанным значением 10 секунд сохраняйте диагностические данные, если getDuration()> 10 секунд). Эти средства диагностики рекомендуется использовать только на этапе тестирования производительности. Для получения дополнительной информации следуйте инструкциям по сбору диагностических данных в Java SDK. |
|
| Избегайте использования специальных символов в идентификаторах | Некоторые символы ограничены и не могут использоваться в некоторых идентификаторах: "/", "\", "?", "#". Общая рекомендация заключается в том, чтобы не использовать специальные символы в идентификаторах, таких как имя базы данных, имя коллекции, идентификатор элемента или ключ секции, чтобы избежать непредвиденного поведения. |
Рекомендации по использованию режима шлюза
При использовании режима шлюза запросы Azure Cosmos DB выполняются по протоколу HTTPS/REST. К ним применяются ограничения на количество подключений по умолчанию для каждого имени узла или IP-адреса. Возможно, вам придется настроить для maxConnectionPoolSize другое значение (от 100 до 1000), чтобы клиентская библиотека могла использовать несколько одновременных подключений к Azure Cosmos DB. В пакете SDK для Java версии 4 значение по умолчанию для GatewayConnectionConfig#maxConnectionPoolSize равно 1000. Чтобы изменить значение, можно задать для GatewayConnectionConfig#maxConnectionPoolSize другое значение.
Лучшие практики для нагрузок с высокой интенсивностью записи
Для рабочих нагрузок, создающих большие объемы данных, установите для параметра запроса CosmosClientBuilder#contentResponseOnWriteEnabled() значение false. Служба больше не будет возвращать созданный или обновленный ресурс пакету SDK. Как правило, поскольку приложение имеет создаваемый объект, служба не должна его возвращать. Значения заголовков по-прежнему доступны, как, например, плата за запрос. Отключение реагирования на содержимое может помочь повысить производительность, поскольку пакету SDK больше не требуется выделять память или сериализовать текст ответа. Это также сокращает использование пропускной способности сети для еще большего повышения производительности.
Дальнейшие действия
Дополнительные сведения см. в статье Советы по обеспечению производительности для пакета SDK Azure Cosmos DB для Java версии 4.
Дополнительные сведения о разработке приложения для масштабируемости и высокой производительности см. статью Разбиение на разделы и масштабирование в Azure Cosmos DB.
Пытаетесь составить план мощностей для миграции в Azure Cosmos DB? Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.
- Если вам известно только количество виртуальных ядер и серверов в существующем кластере баз данных, ознакомьтесь с информацией об оценке единиц запросов на основе виртуальных ядер или виртуальных процессоров.
- Если вы знаете типичные частоты запросов для текущей рабочей нагрузки базы данных, ознакомьтесь с оценкой единиц запросов с помощью планировщика емкости Azure Cosmos DB.