Разработка стратегии организации хранилища
При разработке приложения, которое должно хранить данные, важно подумать о том, как приложение будет упорядочивать данные между учетными записями хранения, контейнерами и большими двоичными объектами.
Учетные записи хранения
Одна учетная запись хранения достаточно гибка для организации больших двоичных объектов. Однако при необходимости следует использовать дополнительные учетные записи хранения для логического разделения затрат и контроля доступа к данным.
Контейнеры и BLOB-объекты
Выбор стратегии для именования и упорядочивания контейнеров и BLOB-объектов должен зависеть от характера вашего приложения и данных, которые в нем хранятся.
Приложения, использующие большие двоичные объекты в рамках схемы хранения, включающую базу данных, часто не должны полагаться на организацию, именование или метаданные, чтобы указать что-либо о своих данных. Такие приложения часто используют в качестве имен BLOB-объектов идентификаторы, такие как идентификаторы GUID, и ссылаются на эти идентификаторы в записях базы данных. Для определения местонахождения BLOB-объектов и типа данных, которые в них содержатся, приложение будет использовать базу данных.
Другие приложения используют Хранилище BLOB-объектов Azure больше как личная файловая система. Имена контейнеров и BLOB-объектов указывают значение и структуру. Имена BLOB-объектов в таких приложениях часто выглядят как традиционные имена файлов. Они могут включать расширения имени файла, такие как JPG , чтобы указать, какой тип данных они содержат. Такие приложения используют виртуальные каталоги для упорядочивания больших двоичных объектов. Они часто используют теги метаданных для хранения сведений о больших двоичных объектах и контейнерах.
Выбирая способ упорядочивания и хранения BLOB-объектов и контейнеров, следует учитывать несколько важных моментов.
Ограничения именования
Имена контейнеров и BLOB-объектов должны соответствовать ряду правил, включая ограничения на длину и символы. Более подробные сведения о правилах именования см. в разделе Дополнительные материалы в конце этого модуля.
Общий доступ и контейнеры как границы безопасности
По умолчанию для доступа ко всем BLOB-объектам требуется проверка подлинности. При этом отдельные контейнеры можно настроить так, чтобы BLOB-объекты из этих контейнеров можно было загружать в открытом доступе без проверки подлинности. Открытая загрузка поддерживает самые разные варианты применения, включая размещение статических ресурсов для веб-сайтов и совместное использование файлов. Этот подход работает, так как скачивание содержимого БОЛЬШОго двоичного объекта работает так же, как считывание других данных через Интернет. Вы просто указываете браузер или все, что может сделать запрос GET по URL-адресу БОЛЬШОго двоичного объекта.
Включение общедоступного доступа важно для масштабируемости. Данные, скачанные непосредственно из служба хранилища BLOB-объектов, не создают трафик в серверном приложении. Планируйте использовать отдельные контейнеры для данных, которые вы хотите быть общедоступными, даже если вы не сразу разрешаете общедоступный доступ или используете базу данных для управления доступом к данным.
Внимание
Любой, кто знает URL-адреса хранилища, может скачать большие двоичные объекты в контейнере, настроенный для общедоступного доступа без какой-либо проверки подлинности или аудита. Не размещайте в общедоступном контейнере BLOB-объекты, не предназначенные для открытого доступа.
Помимо открытого доступа, в Azure есть функция подписанного URL-адреса, позволяющая управлять детальными разрешениями для контейнеров. Контроль точности доступа позволяет сценариям, которые еще больше повышают масштабируемость, поэтому полезно рассматривать контейнеры как границы безопасности.
Префиксы имен BLOB-объектов (виртуальные каталоги)
Контейнеры являются неструктурированными. Они не поддерживают какое-либо вложение или иерархию. Если вы предоставляете иерархические имена больших двоичных объектов, которые выглядят как пути к файлам, например finance/budgets/2017/q1.xls, операция перечисления API может фильтровать результаты по определенным префиксам. Этот подход позволяет перемещаться по списку, как если бы это была иерархическая система файлов и папок.
Некоторые средства и клиентские библиотеки используют этот подход для визуализации и навигации служба хранилища BLOB-объектов, как если бы это была файловая система. Любое перемещение по папкам запускает отдельный вызов списка BLOB-объектов в этой папке. Эта функция часто называется виртуальными каталогами.
Примечание.
Если включить функцию пространства имен иерархии учетной записи, каталоги больше не являются виртуальными. Вместо этого они становятся конкретными, независимыми объектами, с которыми можно работать напрямую. Каталог может существовать без каких-либо файлов. В этом модуле описываются только учетные записи, которые не включают функцию иерархического пространства имен.
Типы BLOB-объектов
Существуют три типа BLOB-объектов для хранения данных:
- Блочные BLOB-объекты состоят из блоков разного размера, которые можно передавать по отдельности и параллельно. Запись в блочный BLOB-объект подразумевает передачу данных в блоки и фиксирование в BLOB-объекте.
- Добавление больших двоичных объектов — это специализированные блочные BLOB-объекты , поддерживающие только добавление новых данных, а не обновление или удаление существующих данных. Они эффективны для этой цели. Добавочные BLOB-объекты идеально подходят для таких сценариев, как хранение журналов или запись потоковой передачи данных.
- Страничные BLOB-объекты поддерживают сценарии, в которых используются операции чтения и записи случайным доступом. Страничные BLOB-объекты используются для хранения файлов виртуального жесткого диска (VHD), используемых azure Виртуальные машины. Они отлично подходят для любого сценария, включающего случайный доступ.
Блочные BLOB-объекты — оптимальный вариант для большинства сценариев, которые не требуют добавочных или страничных BLOB-объектов. Их структура на основе блоков поддерживает быстрые отправки и загрузки и эффективный доступ к отдельным частям большого двоичного объекта. Большинство клиентских библиотек автоматически управляют и фиксируют блоки. Некоторые также обрабатывают параллельные отправки и загрузки, чтобы повысить производительность.