Новый элемент, вставленный в Azure Хранение таблицы, не доступен немедленно - PullRequest
Новая
       61

Новый элемент, вставленный в Azure Хранение таблицы, не доступен немедленно

1 голос
/ 16 марта 2020

У меня есть

  • конечная точка в Azure функции с именем "INSERT", которая вставляет запись в хранилище таблиц с помощью пакетной операции .
  • конечная точка в другой Azure функции с именем "GET", которая получает запись в хранилище таблиц.

Если я вставлю элемент, а затем сразу получу его тот же предмет, тогда предмет еще не появился!

Если я задержу на одну секунду после сохранения, то Я найду предмет.

Если я задерживаюсь на 10 мс после сохранения, тогда Я не нахожу элемент.

При обновлении элемента появляется тот же симптом. Я установил поле даты на элементе. Если я получаю сразу после удаления, то иногда поле даты еще не установлено.

Это известное поведение в Azure Хранении таблиц? Я знаю об ETags, как описано здесь , но я не могу понять, как это относится к этой проблеме.

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

Ответы [ 2 ]

2 голосов
/ 20 марта 2020

Как уже упоминалось в комментариях, Azure Хранилище таблиц Сильно согласовано . Данные доступны вам, как только они записаны в хранилище.

В отличие от Cosmos DB Table Storage, где имеется много уровней согласованности, и данные могут быть недоступны для немедленного чтения после записи в зависимости от установленного согласованного уровня.

1 голос
/ 17 марта 2020

Эта проблема была связана с моим кодом и очередями, работающими в фоновом режиме.

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

И ко второй части, почему поле даты, похоже, не устанавливается так быстро, как я его получаю. Что ж, получается, что я отфильтровал по столбцам, например так: 

var operation = TableOperation.Retrieve<Entity>(partitionKey, id, new List<string> { "Content", "IsDeleted" });

И что еще хуже, у класса "Entity", к которому я десериализуюсь, конечно, были значения по умолчанию примитивов (например, "false"). ") так что это не выглядело так, как будто они не были заданы.

Таким образом, ответ не имеет большого отношения к вопросу, так что, в общем, для любого, кто найдет этот вопрос, потому что ему интересно то же самое :

Ответ: ДА - Хранилище таблиц на самом деле строго согласовано, и не имеет значения, используете ли вы «очень быстро» или подключаетесь из другого места.

...