Azure cosmos db против хранилища BLOB-объектов для промежуточного / временного хранения

Question

У нас в WebAPI есть требование извлекать полезную нагрузку из внешнего API в форме JSON, очищать и публиковать ее в Azure Sql. Для этого требования мы в настоящее время полагаемся на хранилище больших двоичных объектов, где мы сохраняем полезную нагрузку json в большой двоичный объект Azure и извлекаем ее в пользовательский интерфейс для очистки данных. Пользователь может потратить много времени на проверку данных и их изменение по мере необходимости. Пользователь может набросать его на несколько дней и нажать кнопку «Импорт», когда все чистки будут выполнены. Теперь я заметил, что во время этих черновиков блоб просто извлекается и десериализуется в список объектов, чтобы найти соответствующие свойства для обновления. Когда обновления выполняются, когда пользователь нажимает Черновик, тот же список сериализуется как json и сохраняется обратно в BLOB-объект. Процесс сериализации / десериализации кажется дорогим. Вместо этого я думаю о замене BLOB-объекта на Cosmos DB. Это действительно импровизирует представление? Предположите, что поддержка Azure Sql Json более осуществима, чем все эти варианты? Я даже думаю о Redis Cache? Основным фактором принятия решения будет также экономическая эффективность.

Answer 1

У вас будет большое преимущество в производительности при использовании Cosmos DB, если вы хотите осуществлять поиск по объектам JSON, а результаты поиска значительно меньше по размеру, чем весь список объектов. В любом случае вы заплатите цену сериализации / десериализации за объекты, возвращаемые запросом, так как они должны быть отправлены по сети вашему приложению.

Цена на Cosmos DB намного выше, чем у стандартного хранилища BLOB-объектов, но это очень простой инструмент для работы с рабочими нагрузками JSON. У вас есть API-интерфейсы запросов SQL и MongoDB, так что вы сможете разрабатывать независимое от базы данных приложение (по крайней мере, на уровнях запросов).

Я думаю, что имеет смысл использовать Redis Cache, если у вас есть списки объектов JSON, к которым обращаются чаще, чем к другим, поэтому вы можете предварительно загрузить их в кэш, чтобы воспользоваться преимуществами более эффективных операций поиска и позже загрузить их на постоянное хранилище BLOB-объектов.