Частота запросов велика

Я использую Azure documentdb и получаю к нему доступ через мой node.js на экспресс-сервере, когда я делаю циклический запрос, небольшой объем в несколько сотен проблем не вызывает. Но когда запрос в цикле немного больше, скажем, около тысячи плюс

Я получаю частичные результаты (непоследовательные, каждый раз, когда я запускаю, значения результатов не совпадают. Возможно, из-за асинхронного характера Node.js) после нескольких результатов происходит сбой с этой ошибкой.

body: '{"код":"429","сообщение":"Сообщение: {\"Ошибки\":[\"Высокая частота запросов\"]}\r\nActivityId: 1fecee65-0bb7-4991-a984- 292c0d06693d, Request URI: /apps/cce94097-e5b2-42ab-9232-6abd12f53528/services/70926718-b021-45ee-ba2f-46c4669d952e/partitions/dd46d670-ab6f-4dca-bbbb-937647b03d97/replicas/130845018837894542p"}' }

Это означает, что DocumentDb не может обрабатывать более 1000 запросов в секунду? Все вместе создает у меня плохое впечатление о методах NoSQL ... неужели это недостаток DocumentDB?


person Shreyz    schedule 26.08.2015    source источник
comment
Можете ли вы проверить, какую ценовую категорию вы установили для своей коллекции? Это Standard S2 (1000 единиц запроса) или Standard S3 (2500 единиц запроса)?   -  person Gaurav Mantri    schedule 26.08.2015
comment
Гаурав, это то, что я вижу в колонке свойств DocumentDB, СТАТУС УРОВЕНЬ УЧЕТНОЙ ЗАПИСИ В сети Стандартный РАСПОЛОЖЕНИЕ Юго-Восточная Азия   -  person Shreyz    schedule 26.08.2015
comment
В любом случае я могу перейти на S3 сейчас?   -  person Shreyz    schedule 26.08.2015
comment
Вы должны быть. Щелкните коллекцию на портале, а затем щелкните поле Ценовая категория. Вы должны иметь возможность изменить ценовую категорию с S2 на S3. ХТН.   -  person Gaurav Mantri    schedule 26.08.2015


Ответы (1)


Как предполагает Гаурав, вы можете избежать проблемы, повысив ценовой уровень, но даже если вы перейдете на самый высокий уровень, вы сможете справиться с ошибками 429. Когда вы получаете ошибку 429, ответ будет включать заголовок «x-ms-retry-after-ms». Он будет содержать число, представляющее количество миллисекунд, которое вы должны подождать, прежде чем повторить запрос, вызвавший ошибку.

Я написал логику для обработки этого в моем пакете documentdb-utils node.js. Вы можете либо попробовать использовать documentdb-utils, либо продублировать его самостоятельно. Вот пример.

createDocument = function() {
   client.createDocument(colLink, document, function(err, response, header) {
        if (err != null) {
            if (err.code === 429) {
                var retryAfterHeader = header['x-ms-retry-after-ms'] || 1;
                var retryAfter = Number(retryAfterHeader);
                return setTimeout(toRetryIf429, retryAfter);
            } else {
                throw new Error(JSON.stringify(err));
            }
        } else {
            log('document saved successfully');
        }
    });
};

Обратите внимание, что в приведенном выше примере document находится в области действия createDocument. Это делает логику повтора немного проще, но если вам не нравится использовать переменные с широкой областью действия, вы можете передать document в createDocument, а затем передать его в лямбда-функцию в вызове setTimeout.

person Larry Maccherone    schedule 26.08.2015
comment
Я только что перечитал ваш вопрос, и у меня есть еще одна мысль. Способ, которым DocumentDB обрабатывает масштабирование, — это количество коллекций. Таким образом, если вам требуется более 2500 ЕЗ/с, вам следует разбить свои данные и использовать вторую коллекцию... даже если вы не приближаетесь к емкости хранилища одной коллекции. С другой стороны, если ваше устойчивое состояние значительно ниже 2500 RU/сек, но у вас есть редкие всплески превышения этого значения, тогда описанный выше подход к обработке 429 должен быть вполне приемлемым. - person Larry Maccherone; 26.08.2015