Хранилище BLOB-объектов Azure против файловой службы [закрыто]

130

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

Только API для доступа к ним немного отличается в том, что файловая служба позволяет вам запрашивать источник, используя функции ввода-вывода файлов Win32, а также в дополнение к использованию REST API.

Почему бы вам выбрать один из них, если вы хотите, чтобы в вашем приложении хранились файлы, принадлежащие пользователям вашего приложения?

azure azure-storage azure-storage-blobs Кулер для воды v2
источник
6
Вы читали это сообщение в блоге группы службы хранилища Azure: blogs.msdn.com/b/windowsazurestorage/archive/2014/05/12/… ? Прокрутите вниз до раздела, где объясняется, когда использовать какую услугу.
Перестал
3
Да, я прочитал эту статью перед публикацией. Я нахожусь на очень ранних стадиях обдумывания, и мое понимание еще не сформировалось. Я все еще в замешательстве. Я понимаю все, что написано во всех статьях, которые я читал, но я пытаюсь понять, что лучше всего использовать, если я хочу хранить файлы, принадлежащие пользователям, для разрабатываемого мной приложения.
Water Cooler v2
Я предполагаю, что все сводится к тому, что вы хотите делать с этими пользовательскими файлами? Будут ли они каким-то образом возвращаться обратно (через веб-браузер и т. Д.) Или будут обрабатываться дальше? Если это раньше, то имеет смысл хранилище BLOB-объектов. В последнем случае имеет смысл файловая служба.
Прекращено
1
Дело в том, что я хочу позволить пользователю загружать и скачивать свои собственные файлы, а также делиться некоторыми из них с другими в своей группе контактов (чтобы они могли только скачивать / читать). Для этого я мог бы использовать подписи общего доступа (SAS) с хранилищем BLOB-объектов, но это не позаботилось бы о моем требовании «совместного использования». Я склонялся к решению, в котором мое приложение / служба выполняла всю аутентификацию и не предоставляла пользователю фактический ресурс хранилища. В этом контексте для меня файловая служба и хранилище BLOB-объектов делают одно и то же. Никто не предлагает мне большего комфорта, чем другой.
Кулер для воды v2
@ WaterCoolerv2 Можете ли вы помочь мне выбрать между хранилищем файлов лазурного типа и хранилищем BLOB-
объектов,

Ответы:

110

Несколько пунктов по вашему вопросу:

  1. Вы не можете подключить хранилище BLOB-объектов Azure как собственный общий ресурс на виртуальной машине.
  2. Хранилище BLOB-объектов Azure не является иерархическим за пределами контейнеров. Вы можете добавлять файлы, содержащие символы / или \, которые интерпретируются как папки многими приложениями, которые читают хранилище BLOB-объектов.
  3. Файловая служба Azure предоставляет интерфейс протокола SMB для хранилища BLOB-объектов Azure, который решает проблему с (1).

Если вы разрабатываете новое приложение, используйте собственный API Azure непосредственно в хранилище BLOB-объектов.

Если вы переносите существующее приложение, которому необходимо предоставлять общий доступ к файлам, используйте файловую службу Azure.

Обратите внимание, что есть несколько функций протокола SMB, которые файловая служба Azure не поддерживает .

Саймон В.
источник
1
Большое спасибо, Саймон. Несколько слов о вашем ответе. Понимаете, в конце концов, я хочу конечный результат. С этой точки зрения я разместил этот вопрос. С точки зрения конечного результата аргументы №1 и №3 в вашем списке неуместны. Я с вами вообще не спорю. :-) Ваш ответ очень полезен. Я просто пытаюсь рассказать вам о мыслительном процессе, который заставил меня задать этот вопрос. А аргумент №2 не имеет значения, поскольку он представляет проблему и говорит, что это не проблема. Предположим, я хочу хранить файлы, принадлежащие пользователям, и я подумал, почему я предпочту один другому?
Water Cooler v2
Посмотрите на два пункта после пронумерованного списка - это должно быть вашим ориентиром.
Simon W
1
@SimonW - два пункта после вашего руководства указаны как «способ сделать это». Однако это не абсолют. Они больше похожи на предложения в рамках этого сценария. Бывают случаи, когда вы не хотите использовать API Azure напрямую, даже с новым приложением. Точно так же есть случаи, когда вам может потребоваться переработать существующие приложения для использования API Azure.
Дэвид Макогон
Есть ли между ними разница в производительности IOPS?
LaPuyaLoca 06
@SimonW - не могли бы вы подробнее рассказать о пункте 3 выше? Это способ смонтировать Blob как общий файловый ресурс SBM или каким-то образом получить к нему доступ как к «диску»?
Нил Вейхер
38

Еще несколько вещей, которые следует учитывать:

  • Цены. Хранилище BLOB-объектов намного дешевле, чем хранилище файлов.
  • Переносимость: с хранилищем BLOB-объектов, если вы решите перейти на платформу diff в будущем, вам, возможно, придется изменить код приложения, но с хранилищем файлов вы можете перенести свое приложение на любую другую платформу, поддерживающую SMB (при условии, что вы используете собственные API файловой системы в ваше приложение)
Дхармендар Кумар 'DK'
источник
4
Цена здесь является огромным фактором (в настоящее время разница примерно в 5 раз), а также стоит упомянуть ограничение в 5 ТБ для хранения файлов.
TZHX
Старый пост, но сегодня читаю впервые. По умолчанию для стандартного ценового уровня существует ограничение в 5 ТБ, но его можно изменить, переключившись на ограничение в 100 ТБ. Примечание. * Включение больших общих файловых ресурсов в учетной записи - это необратимый процесс в учетной записи хранилища Azure. docs.microsoft.com/azure/storage/files/…
Рувд,
10

Файловая служба Azure больше ориентирована на внутреннюю обработку файлов. Под внутренним я подразумеваю подключение каталога к виртуальной машине в облаке или локально, чтобы его можно было загрузить в серверную часть (протокол на основе SMB).

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

В этом сообщении содержится более подробная информация о сравнении (внизу): https://blogs.msdn.microsoft.com/windowsazurestorage/2014/05/12/introduction-microsoft-azure-file-service/


источник
Привет, Клеменс Шотте, что имеется в виду под хранилищем BLOB-объектов, позволяющим загружать через URL-адрес. Вы имеете в виду, что файловое хранилище не предоставляет URL-адреса?
Heemanshu Bhalla
1
Некоторые вещи изменились после этих публикаций, но файловая служба поддерживает загрузку через URL-адрес и другие API REST ( docs.microsoft.com/en-us/azure/storage/common/… ). Кроме того, безопасность, похоже, находится на уровне учетной записи хранения, поэтому она должна быть очень похожей между BLOB-объектами и файловой службой ( docs.microsoft.com/en-us/azure/storage/common/… ).
KJ