Здравствуйте, v6, Вы писали:

v6>Здравствуйте, VladCore, Вы писали:

VC>>
v6>>>Почему некорректные? Есть пул воркеров, которые могут обновлять запись в одном партишене. Самый примитивный и просто вариант разрулить — это optimistic concurrency: если случилась ошибка, попробовать еще раз.
v6>>>Если интенсивность запросов невысокая, то нормально будет работать. Если запросы слишком частые, то будут мешать друг другу, надо синхронизировать через очередь тасок. Мой вопрос в том, где примерно можно провести границу между этими двумя случаями. Т.е. асколько может масштабироваться optimistic concurrency. Про UI тут вообще ничего нет.
VC>>

VC>>Ну ты правильно написал. Только если архитектура и UI позволяет и все воркеры пишут разные hash keys.

VC>>optimistic concurrency может нужна а может и нет. она тут ортогональная.

v6>Я, наверно, плохо описал ситуацию. Упрощенно такой пример: есть множество воркеров, каждый инкрементит общий счетчик, допустим, выполненных заданий. Счетчик в Azure table. Чтобы заинкрементить читаем и пишем обратно. Если отвалились с ошибкой "уже изменено", то пробуем еще раз, прикручиваем exponential backoff. Вопрос: насколько этот подход масштабируем в условиях azure. Может сразу очередь с заданиями на инкремент счетчика делать?

Аааа. Ну так бы стразу и описал. Да. Но из очереди можно вычитывать за раз атомарно по моему всего 10 сообщений.

И если "уже изменено" по моему не нужен exponential backoff

Попробуйте все инкременты заданного ID разбить на 100-1000-10000 строчек продублировав ID в RowKey и PartitionKey. Там до 1К лимит размера каждого поля. Приклеивайте к ID GetHashCode(IP адрес или логин клиента)/N

Тогда сможете инкрементировать не по 10 инкрементов за цикл воркера, а по 100-1000-10000 инкрементов.

Здравствуйте, v6, Вы писали:

v6>Здравствуйте, VladCore, Вы писали:

VC>>
v6>>>Почему некорректные? Есть пул воркеров, которые могут обновлять запись в одном партишене. Самый примитивный и просто вариант разрулить — это optimistic concurrency: если случилась ошибка, попробовать еще раз.
v6>>>Если интенсивность запросов невысокая, то нормально будет работать. Если запросы слишком частые, то будут мешать друг другу, надо синхронизировать через очередь тасок. Мой вопрос в том, где примерно можно провести границу между этими двумя случаями. Т.е. асколько может масштабироваться optimistic concurrency. Про UI тут вообще ничего нет.
VC>>

VC>>Ну ты правильно написал. Только если архитектура и UI позволяет и все воркеры пишут разные hash keys.

VC>>optimistic concurrency может нужна а может и нет. она тут ортогональная.

v6>Я, наверно, плохо описал ситуацию. Упрощенно такой пример: есть множество воркеров, каждый инкрементит общий счетчик, допустим, выполненных заданий. Счетчик в Azure table. Чтобы заинкрементить читаем и пишем обратно. Если отвалились с ошибкой "уже изменено", то пробуем еще раз, прикручиваем exponential backoff. Вопрос: насколько этот подход масштабируем в условиях azure. Может сразу очередь с заданиями на инкремент счетчика делать?

Аааа. Ну так бы стразу и описал. Да. Но из очереди можно вычитывать за раз атомарно по моему всего 10 сообщений.

И если "уже изменено" по моему не нужен exponential backoff

Если по 10 инкрементов обновлять — мало. Можно обойтись без очереди.

Попробуйте все инкременты заданного ID разбить на 100-1000-10000 строчек в Table продублировав ID в RowKey и PartitionKey. Там до 1К лимит размера каждого поля. Приклеивайте к ID GetHashCode(IP адрес или логин клиента)/N

Тогда сможете инкрементировать не по 10 инкрементов за цикл воркера, а по 100-1000-10000 инкрементов.