какой смысл принудительных продолжений в хранимых процедурах CosmosDB, если вам нужна транзакция ACID

#azure-cosmosdb

#azure-cosmosdb

Вопрос:

Все примеры javascript, приведенные MS / Azure для хранимых процедур CosmosDB, заставляют использовать механизм продолжения, который должен обрабатываться и контролироваться вызывающим клиентом. Не противоречит ли это цели создания атомарных транзакций ACID?

Стремясь создать набор обновлений на основе транзакции ACID, я написал эту гораздо более упрощенную хранимую процедуру :

 function replace(updates) {
    var container = getContext().getCollection();
    var containerLink = container.getSelfLink();
    if (typeof updates === "string") updates = JSON.parse(updates);

    updates.forEach(
        function(doc) {
            var isAccepted = container.replaceDocument(doc._self, doc,
                function (err) {
                    if (err) throw err;
                }
            );
            if (!isAccepted) throw new Error("Execution bounds exceeded for a replace.");
        }
    );
}
  

Казалось бы, это принудительно передает все, что я даю, в SP, чтобы оно было атомарным, или сбой. Но после просмотра всех примеров, предоставленных поставщиком, я просто должен спросить, хорошая ли это идея?? Теперь, с тем, что я делаю, я действительно никогда не ожидаю, что достигну 5-секундного предела, хотя, возможно, в некоторые моменты я могу максимально использовать RU, так что в этом случае, пока я создаю клиент Cosmos в своем фоновом коде, чтобы иметь возможность работать с этим, я буду в порядке?

Кстати, где находится документ MS, в котором описывается ограничение в 5 секунд? Существует ли ограничение на размер данных, которые могут быть переданы в сохраненную процедуру? (Методом проб / ошибок я обнаружил, что существует ограничение на размер, которым может быть сам SP, я полагаю, что это около 1 МБ или около того IIRC)

Ответ №1:

Казалось бы, это принудительно передает все, что я даю, в SP, чтобы оно было атомарным, или сбой. Но после просмотра всех примеров, предоставленных поставщиком, я просто должен спросить, хорошая ли это идея??

На мой взгляд, ваш текущий план требует много времени и дорог для RUs. Вам нужно передать данные, которые необходимо обновить, перед этим вам нужно подготовить такие данные (запросить из базы данных или собрать в вашем собственном приложении).

Я предлагаю вам использовать пример массового обновления хранимой процедуры.На основе документа компонент database engine в Azure Cosmos DB поддерживает транзакции, полностью совместимые с ACID (атомарность, согласованность, изоляция, долговечность), с изоляцией моментальных снимков.

введите описание изображения здесь

где находится документ MS, в котором описывается ограничение в 5 секунд? Существует ли ограничение на размер данных, которые могут быть переданы в сохраненную процедуру?

Не нашел таких заявлений об ограничении в официальном документе, но все еще есть много подсказок в этом блоге. В любом случае, у SP есть ситуация с тайм-аутом, вы не можете это игнорировать. Как вы упомянули в своем вопросе, вам необходимо управлять токеном продолжения, если данные обновления огромны.Все еще мог бы найти пример в блоге.