Космическая проблема с БД (т. Е. RU Charge, Throughput, Http 429) - PullRequest
Новая
       43

Космическая проблема с БД (т. Е. RU Charge, Throughput, Http 429)

0 голосов
/ 06 мая 2019

  1. Моя производительность API постоянно снижалась, что использовалось для подключения к Cosmos db collection X.

  2. Большинство предложений в Интернете заключалось в том, что ваша база данных должна иметьPartitionKey, который должен быть определен правильно, например, страна, город и т. Д.

  3. На основе такого предложения создан отдельный БД с коллекцией 'Y' с partitionkey в качестве DocumentType, значение которогодиапазон от 1 до 30. Преобразует всю хранимую процедуру, запрос и код на основе partitionedkey.

  4. Меня беспокоит даже после использования ключа секционирования, что дает такую ​​же пропускную способность для новой секционированной БДкак и раньше, и при запуске одного и того же запроса в обоих космических БД не вижу никакой разницы в производительности.

Ниже приведены сомнения:

  1. Хотелось бы узнать, какой должен быть средний набор пропускной способности для космоса в дБ с размером: 4 ГБ и 15 разработчиков, которые обращаются к нему постоянно.

  2. Даже после разбиения базы данных не вижу большой разницы в RU при выполнении запроса или хранимой процедуры в обоих космосах. БД.

1 Ответ

0 голосов
/ 07 мая 2019

Невозможно предсказать идеальный RU на основе памяти или количества соединений. Вы можете проверить метрики Cosmos DB вашей базы данных.

Если вы настроили меньше RU, запрос займет время (Query выдаст ошибку 429, а Cosmos SQL-API имеет встроенную логику повторения.) Вы можете увеличить количество попыток повторения в своем подключении Cosmos. 

new RetryOptions() { MaxRetryAttemptsOnThrottledRequests = 30, MaxRetryWaitTimeInSeconds = 30  }

Понимание логического и физического раздела в Cosmos DB . Всегда старайтесь избегать перекрестных запросов.

Увеличение RU напрямую влияет на стоимость. Как правило, я придерживаюсь нижеприведенной практики, чтобы оптимизировать документ и запрос

  1. Размер документа должен быть как можно меньше.

  2. Оптимизация запроса (проверка использования RU и времени с помощью портала Azure / Rest-API / SDK)

  3. Никогда не запускать перекрестный запрос.

Вы можете проверить эту статью для получения дополнительной информации.

...