Хранить более 500 тыс. Изображений + в виде varbinaryblob на Azure BLOB или CosmosDB?

Question

Я работаю над приложением UWP, которое загружает изображения из Azure.Хотя размер изображения <2 МБ, их количество превышает 500 кб.В настоящее время изображения хранятся в Azure SQL как varbinary. Это потребляет 250 ГБ на экземпляре базы данных. Нам нужно переместить его в нереляционное хранилище данных, которое имеет меньшую задержку, потребляет меньше места в хранилище.Какой вариант здесь (Azure BLOB или Cosmos DB) подходит лучше.?Мы загружаем изображения из REST API, подключаясь к Azure SQL прямо сейчас, используя уникальный ключ, и хотим использовать аналогичный подход и с новым хранилищем данных. Было бы здорово услышать мнение кого-то, кто использовал эти хранилища для обработки большого количества изображений.</p>

Answer 1

«Лучше» - это вопрос мнения.Но учтите, что изображения - это не метаданные, а просто двоичные файлы, которые обычно являются доменом хранилища Azure (BLOB-объектов).Как база данных SQL, так и база данных Cosmos имеют определенные ограничения, и вы можете выйти за эти пределы, пытаясь сохранить такое количество двоичных данных.

Далее: после того, как вы храните двоичные данные (например, изображения) в базе данных SQL илиCosmos DB, у вас нет выбора, кроме как программно получить указанное содержимое (и быть связанным с ограничениями производительности, которые вы установили в базе данных / коллекции).В отличие от этого, хранилище Azure имеет свои собственные независимые цели масштабирования, и к объектам можно обращаться напрямую (будь то общедоступный или частный + SAS) и кэшировать их через CDN.

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

Answer 2

Еще одна вещь, о которой следует помнить при не столь очевидной стоимости в Cosmos DB: в настоящее время в космосе существует минимум 40RU / s на ГБ памяти, поэтому, если вы храните большое количество изображений, вы найдете минимум настройка масштабирования может быть довольно высокой, что может быстро стать дорогим.

Как предложил Дэвид, я буду хранить файлы в хранилище BLOB-объектов, а затем URL-адрес файла вместе с идентификаторами в виде пар ключ-значение в Cosmos. Это должно сделать Cosmos достаточно маленьким, эффективным и дешевым, но все же даст вам доступ к индексации.