Хранимая процедура DocumentDB заблокирована

Я использую хранимую процедуру для массовой вставки документов, взятых из образец документации.

Документы вставляются каждую минуту пачками, уровень сбора - S2. После того, как в течение нескольких дней было вставлено около 15000 документов, моя хранимая процедура постоянно блокируется, и я получаю следующее исключение:

Microsoft.Azure.Documents.ForbiddenException, сообщение: {"Ошибки": ["Сценарий с идентификатором 'xxx' заблокирован для выполнения, так как он несколько раз нарушил допустимый предел ресурсов."]}

Однако совершенно непонятно, что именно я нарушаю - количество запросов? Общее количество документов? Размер документа? Глядя на ограничения DocumentDB и описание уровней производительности, я не могу понять, какое ограничение я нахожу и что я могу сделать, чтобы его исправить. Я также не получаю никаких предупреждений или предупреждений на портале Azure ...

Что мне делать в этой ситуации? Перейти к циклическому перебору с несколькими хранимыми процедурами;)?


azure azure-cosmosdb
person dennis    schedule 30.04.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я тоже сталкивался с этим, поэтому я придумал обходной путь. Всякий раз, когда я получаю ответ о нехватке ресурсов, я фактически удаляю и воссоздаю хранимую процедуру. Я создал библиотеку, которая позаботится об этом автоматически на основе ответа. Он также заботится об автоматической задержке отклика на дросселирование и включает в себя множество других удобств.

Видеть:

person Larry Maccherone    schedule 05.05.2015

arrow_upward
3
arrow_downward

Сценарии на стороне сервера управляются ресурсами с точки зрения ЦП, памяти и ввода-вывода, чтобы предотвратить злоупотребления и избежать проблем с шумными соседями.

Логический флаг, возвращаемый операциями CRUD документа, предназначен для того, чтобы сигнализировать, когда ресурсы исчерпаны и пришло время для корректного завершения скрипта.

В этом случае сценарий правильно уступает место документу CRUD Boolean ... Похоже, это ошибка на стороне DocumentDB; сценарий никогда не должен попадать в черный список. Я вызову шум и исправлю это для вас в кратчайшие сроки.

Обновление (05.05.15): мы считаем, что обнаружили ошибку; попытается развернуть исправление позже на этой неделе. А пока есть два обходных пути (выберите любой) ... 1) Вы можете воссоздавать sproc при каждом запуске. Это позволяет вам полностью обходить черный список. 2) В частности, для массового импорта документов вы можете ограничить количество документов, создаваемых за один прогон, до ‹= 100 документов для коллекции S1 и‹ = 1000 документов для коллекции S3. Это должно снизить потребление ресурсов скриптом ниже текущих пороговых значений для внесения в черный список.

Обновление (04.06.15): мы развернули исправление; пожалуйста, свяжитесь со мной, если вы столкнулись с блокировкой скриптов: askcosmosdb {at} microsoft.com

person Andrew Liu    schedule 01.05.2015
comment
Спасибо :) Сообщите мне, если вам понадобится дополнительная информация о моей настройке. - person dennis; 01.05.2015
comment
Я тоже испытываю эту проблему. Пожалуйста, дайте мне знать, если вам понадобится мой пример. - person Larry Maccherone; 04.05.2015
comment
@aliuy, см. мой ответ ниже, чтобы найти ссылки на новую библиотеку, которую я создал, которая, среди прочего, решает эту проблему. - person Larry Maccherone; 05.05.2015
comment
Замечательная библиотека! Я люблю это. Не могли бы вы прислать мне по электронной почте ваши примеры sprocs в andrl {at} microsoft? - person Andrew Liu; 05.05.2015
comment
@Larry Maccherone Спасибо, отметив ваше предложение как ответ, так как оно решает проблему. Надеюсь, что ms не заблокирует все наши учетные записи documentdb из-за чрезмерного нарушения :) aliuy, было бы очень хорошо исправить эту ошибку, иначе это одна забавная база данных, которая в какой-то момент отказывается принимать больше данных без причины ... - person dennis; 08.05.2015