Контрольный список для обеспечения производительности и масштабируемости для Хранилища блобов

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

Служба хранилища Azure имеет целевые показатели по масштабируемости и производительности, выраженные в объемах, скорости транзакций и пропускной способности. Дополнительные сведения о целевых показателях масштабируемости в службе хранилища Microsoft Azure см. в статьях Целевые показатели масштабируемости и производительности для стандартных учетных записей хранения и Целевые показатели масштабируемости и производительности для хранилища BLOB-объектов.

Контрольный список

В этой статье проверенные методы повышения производительности собраны в контрольный список, полезный при разработке приложений хранилища BLOB-объектов.

Целевые показатели масштабируемости

Если приложение приближается к одному из целевых показателей масштабируемости или превышает его, оно может столкнуться с увеличением задержек транзакций или с ограничением скорости обработки запросов. Когда Azure Storage ограничивает работу вашего приложения, сервис начинает возвращать коды ошибок 503 (сервер занят) или 500 (время ожидания операции истекло). Этих ошибок можно избежать, строго соблюдая ограничения для целевых показателей масштабируемости. Это важная часть стратегии по повышению производительности приложения.

Для получения дополнительной информации о целевых показателях масштабируемости для Службы очередей см. Масштабируемость и производительность хранилища Azure.

Максимальное количество учетных записей хранения

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

• Вы используете учетные записи хранения для хранения неуправляемых дисков и добавления этих дисков в виртуальные машины (ВМ)? Корпорация Майкрософт рекомендует использовать управляемые диски для этого сценария. Масштабирование управляемых дисков выполняется автоматически, без необходимости в создании отдельных учетных записей хранения и управлении ими. Дополнительные сведения см. в статье Общие сведения об управляемых дисках Azure.
• Вы используете одну учетную запись хранения для каждого клиента в целях изоляции данных? В этом сценарии Microsoft рекомендует использовать контейнер BLOB для каждого клиента, а не всю учетную запись хранения. Теперь служба хранилища Microsoft Azure позволяет назначать роли Azure для каждого контейнера. Дополнительные сведения см. в статье Назначение роли Azure для доступа к данным BLOB-объектов.
• Вы используете несколько учетных записей хранения для сегментирования, чтобы увеличить количество исходящих и входящих операций, операций ввода-вывода в секунду (IOPS) или емкость? В этой ситуации корпорация Майкрософт рекомендует использовать увеличенные лимиты для учетных записей хранения, чтобы, если возможно, сократить количество учетных записей хранения для ваших рабочих процессов. Запрос на увеличение ограничений на количество учетных записей хранения следует направлять в службу поддержки Azure.

Целевые показатели емкости и транзакций

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

• Если ваше приложение достигает целевого количества транзакций, рассмотрите возможность использования учетных записей для хранения блочных BLOB-объектов, которые оптимизированы для работы с высокими скоростями транзакций и обеспечивают низкую и стабильную задержку. Дополнительные сведения см. в статье Общие сведения об учетной записи хранения Azure.
• Пересмотрите рабочую нагрузку, которая приводит к достижению приложением целевого показателя масштабируемости или его превышению. Вы можете спроектировать его по-другому, чтобы использовать меньшую полосу пропускания или производительность, или меньшее количество транзакций?
• Если приложение должно превышать какой-то из целевых показателей масштабируемости, создайте несколько учетных записей хранения и сегментируйте между ними данные приложения. При использовании этого подхода необходимо разработать приложение таким образом, чтобы в будущем для балансировки нагрузки в него можно было добавлять другие учетные записи хранения. Плата взимается только за потребление, то есть объем хранимых и передаваемых данных и совершенные транзакции, но не за сами учетные записи хранения.
• Если приложение приближается к целевым показателям пропускной способности, попробуйте применить сжатие данных на стороне клиента, чтобы снизить пропускную способность, требуемую для отправки данных в службу хранилища Azure. Этот способ снижает нагрузку на пропускную способность и повышает производительность сети, но может ухудшать общую производительность. Оцените, как дополнительная работа по сжатию и распаковке данных на стороне клиента влияет на производительность. Не забывайте также, что хранение данных в сжатом виде может усложнить устранение неполадок, так как затрудняет просмотр данных с помощью стандартных инструментов.
• Если приложение приближается к целевым показателям масштабируемости, убедитесь, что вы используете экспоненциальный обратный выход для повторных попыток. Лучше всего сделать так, чтобы приложение не приближалось к целевым показателям масштабируемости. Для этого примените описанные в этой статье рекомендации. Однако использование экспоненциального отката для повторных попыток подключения предотвращает частые повторные попытки приложения, что может привести к усугублению троттлинга. Дополнительные сведения см. в разделе о превышении времени ожидания и ошибках занятости сервера.

Несколько клиентов, которые одновременно обращаются к одному BLOB-объекту

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

Если объект можно распространить через CDN, например, в виде изображений или видео с веб-сайта, то можно использовать CDN. Дополнительные сведения см. в разделе Распространение содержимого.

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

Пропускная способность и операции с BLOB-объектом

Один BLOB-объект поддерживает до 500 запросов в секунду. Если у вас несколько клиентов, которым необходимо считывать один BLOB-объект, и это ограничение может быть превышено, рассмотрите возможность использования учетной записи хранения блочных BLOB-объектов. Учетная запись хранения блобов обеспечивает более высокий уровень запроса или операций ввода/вывода в секунду (IOPS).

Также можно использовать сеть доставки содержимого (CDN), например Azure CDN, для распределения операций в BLOB-объекте. Дополнительные сведения об Azure CDN см. в статье Общие сведения о сети Azure CDN.

Секционирование

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

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

Секционирование на основе диапазона означает, что соглашения об именовании, использующие лексическое упорядочение (например, mypayroll, myperformance, myemployees и т. д.) или метки времени (log20160101, log20160102, log20160102 и т. д.) скорее всего, приведут к совместному размещению разделов на одном сервере сегментов, пока не потребуется, чтобы они были разбиты на меньшие диапазоны. Совместное размещение больших двоичных объектов на одном сервере секционирования влияет на производительность, поэтому важная часть улучшения производительности включает именование больших двоичных объектов таким образом, чтобы упорядочивать их наиболее эффективно.

Например, все BLOB-объекты в контейнере могут обрабатываться одним и тем же сервером, пока нагрузка на эти BLOB-объекты не потребует дополнительного перераспределения диапазонов секций. Точно так же группу незначительно нагруженных учетных записей с именами, упорядоченными в лексическом порядке, может обслуживать один и тот же сервер, пока нагрузка на одну или несколько из этих учетных записей не потребует их разделения между несколькими серверами секционирования.

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

Можно следовать некоторым лучшим практикам, чтобы уменьшить частоту выполнения таких операций.

• Если возможно, используйте BLOB-объекты или размеры блоков, превышающие 256 КиБ для стандартных учетных записей хранения и для учетных записей хранения класса "Премиум". Объекты или блоки увеличенного размера автоматически активируют блоки с высокой пропускной способностью. Блочные двоичные объекты с высокой пропускной способностью обеспечивают высокоэффективное считывание данных, не зависящее от именования разделов.

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

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

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

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

Сеть

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

Возможности клиентской сети

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

Пропускная способность

Что касается полосы пропускания, частой проблемой являются возможности клиента. Более крупные экземпляры Azure имеют сетевые карты с большей ёмкостью, поэтому если вам нужно увеличить сетевые ограничения от одной машины, следует рассмотреть возможность использования более крупного экземпляра или большего количества виртуальных машин. Если вы обращаетесь к службам хранилища Azure из локальной среды, то применяется то же правило: понять сетевые возможности клиентского устройства и подключения к Azure Storage и улучшить их по мере необходимости или разработать приложение для работы в рамках их возможностей.

Качество связи

Как и при любом использовании сети, следует помнить, что сетевые условия приводят к ошибкам и потере пакетов замедляет эффективную пропускную способность. Использование инструмента WireShark или NetMon может помочь в диагностике этой проблемы.

Расположение

В любой распределенной среде наилучшее быстродействие достигается при нахождении клиента рядом с сервером. Для доступа к хранилищу Azure с наименьшей задержкой лучшим местом для клиента будет его нахождение в том же регионе Azure. Например, если ваше веб-приложение Azure использует службу хранилища Azure, обе службы лучше разместить в пределах одного региона (западная часть США, Юго-Восточная Азия и т. д.). Совместное размещение ресурсов уменьшает задержку и снижает стоимость, так как трафик в пределах одного региона остается бесплатным.

Если клиентские приложения получают доступ к хранилищу Azure, но не размещаются в Azure, например, приложения для мобильных устройств или локальные корпоративные службы, то размещение учетной записи хранилища в регионе рядом с этими клиентами может снизить задержку. Если клиенты разбросаны по всему миру (например, часть в Северной Америке, а остальные в Европе), обдумайте вариант с несколькими учетными записями хранения, по одной в каждом регионе. Этот подход проще реализовать, если данные хранилища приложений относятся к отдельным пользователям и не требуют репликации данных между учетными записями хранения.

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

SAS и CORS

Предположим, что вам нужно авторизовать код JavaScript, который выполняется в веб-браузере пользователя или в приложении на мобильном телефоне, чтобы получить доступ к данным в Azure Storage. Один из вариантов — создать приложение-службу, которое выполнит роль прокси-сервера. Устройство пользователя проходит проверку подлинности в этой службе, которая, в свою очередь, предоставляет доступ к ресурсам службы хранилища Azure. Таким образом, можно избежать раскрытия ключей учетной записи хранения на ненадежных устройствах. Но такой подход создает значительную нагрузку на приложение-службу, через которое проходят все данные, передаваемые между пользовательским устройством и службой хранилища Azure.

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

Как правило, веб-браузер не разрешает JavaScript на странице, размещенной веб-сайтом на одном домене, выполнять определенные операции, такие как операции записи, в другой домен. Эта политика использования одного источника не позволяет вредоносному коду с любой веб-страницы получить доступ к данным, размещенным на другой странице. Однако политика одного источника может стать ограничением при создании облачного решения. Реализуемая на уровне браузера технология CORS (общий доступ к ресурсам независимо от источника) позволяет целевому домену сообщать браузеру, что он доверяет запросам, поступающим из определенных исходных доменов.

Предположим, что выполняемое в Azure веб-приложение обращается к ресурсу в учетной записи хранения Azure. В этом сценарии веб-приложение выполняет роль исходного домена, а учетная запись хранения является целевым доменом. Вы можете настроить CORS для любой из служб хранилища Azure, чтобы она сообщала веб-браузеру о том, что служба хранилища Azure доверяет запросам, поступающим из исходного домена. Дополнительные сведения о технологии CORS см. в статье Cross-Origin Resource Sharing (CORS) support for Azure Storage (Поддержка общего доступа к ресурсам независимо от источника (CORS) для службы хранилища Azure).

Технологии SAS и CORS помогают избавиться от лишней нагрузки на веб-приложения.

Кэширование

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

Чтение данных

Как правило, однократное чтение данных лучше, чем двукратное. Рассмотрим пример веб-приложения, которое получило BLOB-объект размером 50 МиБ из Azure Storage для использования в качестве содержимого для пользователя. В идеале приложение локально кэширует BLOB-объект на диск, а затем извлекает кэшированную версию для последующих запросов пользователей.

Одним из способов избежать получения BLOB-объекта (если он не был изменен с момента кэширования) является определение операции GET с условным заголовком для времени изменения. Если время последнего изменения наступает позже момента кэширования BLOB-объекта, BLOB-объект извлекается и повторно кэшируется. В ином случае кэшированный BLOB-объект извлекается для оптимизации производительности.

Кроме того, можно разработать приложение, исходя из предположения, что blob-объект остается неизменным в течение короткого периода после его получения. В этом случае приложению не нужно проверять, был ли BLOB изменён за этот интервал.

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

Дополнительные сведения об использовании условных заголовков см. Определение условных заголовков для операций службы Blob.

Передача данных в пакетах

В некоторых сценариях можно объединять данные локально, а затем периодически отправлять их в пакете вместо немедленной отправки каждого фрагмента данных. Например, предположим, что веб-приложение сохраняет файл журнала действий. Приложение может отправлять сведения о каждом действии по мере его выполнения в таблицу (при этом выполняется большое количество операций с хранилищем), либо сохранять сведения о действиях в локальном файле журнала и периодически отправлять все сведения о действиях в виде файла с разделителями в BLOB-объект. Если размер каждой записи журнала составляет 1 КБ, за одну операцию можно отправлять тысячи записей. Одна транзакция поддерживает загрузку блоба размером до 64 МиБ. Разработчик приложения должен учитывать возможность сбоя клиентского устройства или сбоя во время загрузки. Если данные о действиях необходимо скачивать в течение определенного временного интервала, а не для одного действия, то рекомендуется использовать хранилище BLOB-объектов вместо хранилища таблиц.

Конфигурация .NET

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

Увеличение стандартного ограничения на количество подключений

Для проектов, использующих платформа .NET Framework, можно использовать следующий код, чтобы увеличить ограничение подключения по умолчанию (обычно это два в клиентской среде или десять в серверной среде) до 100. В обычном случае следует установить значение, приблизительно соответствующее количеству потоков, используемых приложением. Ограничение количества подключений должно быть установлено до открытия каких-либо подключений.

ServicePointManager.DefaultConnectionLimit = 100; //(Or More)  

Дополнительные сведения об ограничениях пула подключений в платформе .NET Framework см. в статье Ограничения пула подключений в .NET Framework и новый пакет SDK Azure для .NET.

Что касается других языков программирования, то для определения механизма установки ограничения количества подключений см. документацию.

Увеличить минимальное количество потоков

Если вы используете синхронные вызовы вместе с асинхронными задачами, может потребоваться увеличить количество потоков в пуле потоков:

ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)  

См. описание метода ThreadPool.SetMinThreads.

Неограниченный параллелизм

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

Клиентские библиотеки и средства

Для повышения производительности всегда используйте самые последние версии клиентских библиотек и средств, предоставляемых корпорацией Майкрософт. Клиентские библиотеки службы хранилища Azure доступны для многих языков. Azure Storage также поддерживает PowerShell и Azure CLI. Корпорация Майкрософт активно развивает эти клиентские библиотеки и средства, оптимизируя их производительность, поддерживая их согласованность с последними версиями служб и реализуя внутреннюю поддержку для многих проверенных методов повышения производительности.

Обработка ошибок службы

служба хранилища Azure возвращает ошибку, когда служба не может обработать запрос. Понимание ошибок, которые возвращает служба хранилища Azure, и соответствующих сценариев, помогает оптимизировать производительность. Список распространенных кодов ошибок см. в разделе Распространенные коды ошибок REST API.

Ошибки времени ожидания и ошибки занятого сервера

Служба хранилища Azure может ограничить ваше приложение, если оно приближается к ограничениям масштабируемости. В некоторых случаях служба хранилища Azure не может обработать запрос из-за некоторого временного состояния. В обоих случаях служба может вернуть ошибку 503 — Server Busy (сервер занят) или 500 — Timeout (время ожидания истекло). Эти же ошибки могут возникать, когда служба перераспределяет сегменты данных для повышения пропускной способности. В большинстве случаев при получении таких ошибок приложению следует повторить операцию, которая их вызвала. Однако если служба хранилища Azure ограничивает приложение, так как оно превышает целевые показатели масштабируемости, или даже если служба не смогла обслужить запрос по какой-либо другой причине, агрессивные повторные попытки могут ухудшить проблему. Мы рекомендуем использовать экспоненциальную задержку для политики повтора. Во всех клиентских библиотеках именно такое поведение является вариантом по умолчанию. Например, приложение может повторить действие через 2 секунды, затем через 4 секунды, затем через 10 секунд, затем через 30 секунд, а затем полностью отказаться от повторения. Это позволяет приложению значительно снизить нагрузку на службу и не усугублять проблемы, связанные с регулированием.

Ошибки подключения могут быть возвращены немедленно, так как они не являются результатом регулирования и, как ожидается, будут временными.

Ошибки без возможности повтора

Клиентские библиотеки обрабатывают повторные попытки с пониманием того, какие ошибки могут быть извлечены и которые не могут быть извлечены. Однако, если вы напрямую вызываете REST API хранилища Azure, существуют некоторые ошибки, которые не следует повторять. Например, ошибка 400 (недопустимый запрос) указывает, что клиентское приложение отправило запрос, который не удалось обработать, так как он не был в ожидаемой форме. Повторное выполнение этого запроса приводит к тому же ответу каждый раз, поэтому нет смысла повторять его. Если вы напрямую вызываете REST API хранилища Azure, помните о потенциальных ошибках и необходимости их повтора.

Дополнительные сведения о кодах ошибок в службе хранилища Azure вы найдете в статье Status and Error Codes (Коды ошибок и состояний).

Копирование и перемещение BLOB-объектов

Azure-хранилище предлагает несколько решений для копирования и перемещения объектов blob внутри одной учетной записи хранения, между учетными записями хранения, а также между локальными системами и облаком. В этом разделе описаны некоторые из этих вариантов с точки зрения их влияния на производительность. Сведения об эффективной передаче данных в хранилище BLOB-объектов и из него см. в статье Выбор решения Azure для передачи данных.

API копирования BLOB-объектов

Чтобы копировать объекты BLOB в учетных записях хранилища, используйте операцию Put Block From URL. Эта операция синхронно копирует данные из любого URL-источника в блочный BLOB-объект. Put Block from URL Использование операции может значительно сократить необходимую пропускную способность при переносе данных между учетными записями хранения. Так как операция копирования выполняется на стороне службы, вам не нужно скачивать и повторно отправлять данные.

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

Использование AzCopy

Служебная программа командной строки AzCopy — это простой и эффективный вариант для группового перемещения BLOB-объектов в учетные записи хранения, из них и между ними. Инструмент AzCopy оптимизирован для этого сценария и может развивать высокую скорость передачи данных. AzCopy версии 10 использует операцию Put Block From URL для копирования данных блоб-объектов между учетными записями хранения. Дополнительные сведения см. в статье Копирование или перемещение данных в службу хранилища Azure с помощью AzCopy версии 10.

Использование Azure Data Box

Для импорта больших объемов данных в хранилище Blob рассмотрите возможность использования семейства Azure Data Box для передачи данных без подключения к интернету. Устройства Data Box, предоставляемые корпорацией Майкрософт, удобны для перемещения больших объемов данных в Azure, если имеются ограничения по времени, доступности сети или стоимости. Дополнительные сведения см. в документации по Azure DataBox.

Распространение содержимого

Иногда приложению необходимо предоставить одинаковое содержимое множеству пользователей (например, демонстрационный видеоролик для продукта, используемый на главной странице веб-сайта), которые находятся в одном или в нескольких регионах. В этом сценарии используйте сеть доставки содержимого (CDN), например Azure Front Door. Azure Front Door — это современная облачная сеть CDN Майкрософт, которая обеспечивает быстрый, надежный и безопасный доступ между пользователями и статическим и динамическим веб-контентом приложений по всему миру. Azure Front Door доставляет содержимое вашего хранилища Blob с помощью глобальной сети периферийных ресурсов Microsoft, имеющей сотни глобальных и локальных точек присутствия (PoPs). CdN обычно поддерживает гораздо более высокие ограничения исходящего трафика, чем отдельная учетная запись хранения и обеспечивает улучшенную задержку доставки содержимого в другие регионы.

Дополнительные сведения о Azure Front Door см. в статье Azure Front Door.

Использование метаданных

Служба BLOB-объектов поддерживает запросы HEAD, которые могут содержать свойства или метаданные BLOB-объектов. Например, если приложению требуются данные из фотографии в формате Exif (сменный формат изображения), можно получить фотографию и извлечь данные. Чтобы сэкономить пропускную способность и повысить производительность, приложение может при отправке фотографии сохранять данные в формате Exif в метаданных BLOB-объекта. После этого можно получить Exif-данные в метаданных, используя только запрос HEAD. Получение только метаданных, а не всего содержимого BLOB-объекта, значительно экономит пропускную способность и сокращает время обработки, необходимое для извлечения Exif-данных. Обратите внимание, что для BLOB-объекта можно хранить 8 КиБ метаданных.

Обновления метаданных учетной записи и контейнера

Учетные записи и метаданные контейнера распространяются в службе хранения в регионе, где находится учетная запись. Полное распространение этих метаданных может занять до 60 секунд в зависимости от операции. Например:

• Если вы быстро создаете, удаляете и повторно создаете учетные записи с тем же именем учетной записи в том же регионе, убедитесь, что вы ожидаете 60 секунд для полного распространения состояния учетной записи или ваши запросы могут завершиться ошибкой.
• При установке политики сохраненного доступа для контейнера, политике может потребоваться до 30 секунд, чтобы вступить в силу.

Настройка производительности для передачи данных

Когда приложение передает данные с помощью клиентской библиотеки служба хранилища Azure, существует несколько факторов, которые могут повлиять на скорость, использование памяти и даже на успех или сбой запроса. Чтобы максимизировать производительность и надежность передачи данных, важно проактивно настраивать параметры передачи клиентской библиотеки в зависимости от среды, в которой работает ваше приложение. Дополнительные сведения см. в разделе "Настройка производительности для отправки и скачивания".

Быстрая загрузка BLOBов

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

Быстрая загрузка одного большого BLOB-объекта

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

Быстрая отправка множества BLOB-объектов

Чтобы быстро отправить множество BLOB-объектов, отправьте их параллельно. Параллельная отправка выполняется быстрее, чем отправка отдельных BLOB-объектов с параллельной отправкой блоков, поскольку в данном случае отправка распределяется по нескольким разделам службы хранилища. AzCopy выполняет параллельную отправку по умолчанию, как и рекомендуется для данного случая. Дополнительные сведения см. в статье Начало работы с AzCopy.

Выберите правильный тип BLOB-объекта

Служба хранилища Azure поддерживает блочные, добавочные и страничные BLOB. В данном сценарии использования выбор типа BLOB-объектов влияет на производительность и масштабируемость решения.

Блочные BLOB-объекты подходят, если надо эффективно передавать большие объемы данных. Например, клиентское приложение, которое отправляет фотографии или видео в хранилище BLOB-объектов, будет ориентироваться на блочные BLOB-объекты.

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

Страничные блобы подходят в том случае, если приложению нужно выполнять произвольные записи данных. Например, диски виртуальной машины Azure хранятся как страничные BLOB-объекты. Дополнительные сведения см. в статье Основные сведения о блочных, добавочных и страничных BLOB-объектах.

Следующие шаги

• Целевые показатели масштабируемости и производительности для хранилища BLOB-объектов
• Целевые показатели масштабируемости и производительности для учетных записей хранения ценовой категории "Стандартный"
• Коды состояний и ошибок