Контрольный список для обеспечения масштабируемости и производительности для Хранилища таблиц
Корпорация Майкрософт создала ряд проверенных методов для разработки высокопроизводительных приложений, использующих хранилище BLOB-объектов. Этот контрольный список определяет основные методики, которые помогут разработчикам оптимизировать производительность. Имейте в виду эти методики при разработке приложения и на протяжении всего процесса.
Служба хранилища Azure имеет целевые показатели по масштабируемости и производительности, выраженные в объемах, скорости транзакций и пропускной способности. Дополнительные сведения о целевых показателях масштабируемости в службе хранилища Microsoft Azure см. в статьях Целевые показатели масштабируемости и производительности для стандартных учетных записей хранения и Целевые показатели масштабируемости и производительности для хранилища BLOB-объектов.
Контрольный список
В этой статье проверенные методы повышения производительности собраны в контрольный список, полезный при разработке приложений хранилища BLOB-объектов.
Целевые показатели масштабируемости
Если приложение достигает одного из целевых показателей масштабируемости или превышает его, оно может столкнуться с увеличением задержки транзакций или запуском механизма регулировки количества запросов. Когда служба хранилища Azure применяет регулирование для приложения, она начинает возвращать коды ошибки 503 — Server busy (сервер занят) или 500 — Operation timeout (время ожидания операции истекло). Этих ошибок можно избежать, строго соблюдая ограничения для целевых показателей масштабируемости. Это важная часть стратегии по повышению производительности приложения.
См. сведения о целевых показателях масштабируемости службы хранилища Azure для Службы очередей.
Максимальное количество учетных записей хранения
Если количество учетных записей хранения приближается к максимальному значению, разрешенному для определенной комбинации подписки и региона, оцените свой сценарий и определите, применяется ли какое-либо из нижеуказанных условий.
- Вы используете учетные записи хранения для хранения неуправляемых дисков и добавления этих дисков в виртуальные машины (ВМ)? Корпорация Майкрософт рекомендует использовать управляемые диски для этого сценария. Масштабирование управляемых дисков выполняется автоматически, без необходимости в создании отдельных учетных записей хранения и управлении ими. Дополнительные сведения см. в статье Общие сведения об управляемых дисках Azure.
- Вы используете одну учетную запись хранения для каждого клиента в целях изоляции данных? В этом сценарии корпорация Майкрософт рекомендует использовать контейнер BLOB-объектов для каждого клиента, а не всю учетную запись хранения. Теперь служба хранилища Microsoft Azure позволяет назначать роли Azure для каждого контейнера. Дополнительные сведения см. в статье Назначение роли Azure для доступа к данным BLOB-объектов.
- Вы используете несколько учетных записей хранения для сегментирования, чтобы увеличить количество исходящих и входящих операций, операций ввода-вывода в секунду (IOPS) или емкость? Для такой ситуации корпорация Майкрософт рекомендует увеличить ограничения по учетным записям хранения, если это возможно, чтобы сократить количество учетных записей хранения для рабочей нагрузки. Запрос на увеличение ограничений на количество учетных записей хранения следует направлять в службу поддержки Azure.
Целевые показатели емкости и транзакций
Если приложение достигает целевых показателей масштабируемости, когда речь идет об одной учетной записи хранения, рассмотрите вопрос об использовании одного из следующих подходов:
- Если приложение достигает цели транзакции, рассмотрите возможность использования учетных записей хранения блочных BLOB-объектов, оптимизированных для высоких скоростей транзакций, а также низкой постоянной задержки. Дополнительные сведения см. в статье Общие сведения об учетной записи хранения Azure.
- Пересмотрите рабочую нагрузку, которая приводит к достижению приложением целевого показателя масштабируемости или его превышению. Вы можете спроектировать его по-другому, чтобы использовать меньшую полосу пропускания или производительность, или меньшее количество транзакций?
- Если приложение должно превышать какой-то из целевых показателей масштабируемости, создайте несколько учетных записей хранения и сегментируйте между ними данные приложения. При использовании этого подхода необходимо разработать приложение таким образом, чтобы в будущем для балансировки нагрузки в него можно было добавлять другие учетные записи хранения. Плата взимается только за потребление, то есть объем хранимых и передаваемых данных и совершенные транзакции, но не за сами учетные записи хранения.
- Если приложение приближается к целевым показателям пропускной способности, попробуйте применить сжатие данных на стороне клиента, чтобы снизить пропускную способность, требуемую для отправки данных в службу хранилища Azure. Этот способ снижает нагрузку на пропускную способность и повышает производительность сети, но может ухудшать общую производительность. Оцените, как дополнительная работа по сжатию и распаковке данных на стороне клиента влияет на производительность. Не забывайте также, что хранение данных в сжатом виде может усложнить устранение неполадок, так как затрудняет просмотр данных с помощью стандартных инструментов.
- Если приложение приближается к целевым показателям масштабируемости, убедитесь, что вы используете экспоненциальный обратный выход для повторных попыток. Лучше всего сделать так, чтобы приложение не приближалось к целевым показателям масштабируемости. Для этого примените описанные в этой статье рекомендации. Однако использование экспоненциальной обратной передачи для повторных попыток предотвращает быстрое повторение приложения, что может привести к более плохому регулированию. Дополнительные сведения см. в разделе о превышении времени ожидания и ошибках занятости сервера.
Несколько клиентов, которые одновременно обращаются к одному BLOB-объекту
Если у вас есть большое количество клиентов, обращаюющихся к одному большому двоичному объекту одновременно, необходимо рассмотреть как один большой двоичный объект, так и целевые показатели масштабируемости учетной записи хранения. Точное количество клиентов, которые могут получить доступ к одному большому двоичному объекту, зависит от таких факторов, как число клиентов, запрашивающих большой двоичный объект одновременно, размер большого двоичного объекта и сетевых условий.
Если BLOB-объект можно распространить по CDN (например, если это изображения или видео с веб-сайта), то можно использовать CDN. Дополнительные сведения см. в разделе Распространение содержимого.
В других сценариях, например в научном моделировании, где данные являются конфиденциальными, предусмотрены два варианта. Первый состоит в том, чтобы распределить доступ к рабочей нагрузки таким образом, чтобы доступ к BLOB-объекту осуществлялся в течение определенного периода времени, а не одновременно. Кроме того, можно временно скопировать BLOB-объект в несколько учетных записей хранения, чтобы увеличить общее число операций ввода-вывода в секунду для BLOB-объекта и учетных записей хранения. Результаты зависят от поведения приложения, поэтому обязательно тестируйте шаблоны параллелизма во время разработки.
Пропускная способность и операции с BLOB-объектом
Один BLOB-объект поддерживает до 500 запросов в секунду. Если у вас несколько клиентов, которым необходимо считывать один BLOB-объект, и это ограничение может быть превышено, рассмотрите возможность использования учетной записи хранения блочных BLOB-объектов. Учетная запись хранения блочных BLOB-объектов обеспечивает более высокую частоту или операций ввода-вывода в секунду.
Также можно использовать сеть доставки содержимого (CDN), например Azure CDN, для распределения операций в BLOB-объекте. Дополнительные сведения об Azure CDN см. в статье Общие сведения о сети Azure CDN.
Секционирование
Общие сведения о секционировании данных BLOB-объектов в службе хранилища Azure будут полезны для повышения производительности. Служба хранилища Azure может обслуживать данные, размещенные в одной секции, быстрее, чем данные, занимающие несколько секций. Если присвоить BLOB-объектам соответствующие имена, можно повысить эффективность запросов на чтение.
Для масштабирования и распределения нагрузки в хранилище BLOB-объектов используется схема секционирования на основе диапазонов. Каждый BLOB-объект имеет ключ секции, состоящий из полного имени BLOB-объекта (учетная запись + контейнер + BLOB-объект). Ключ секции используется для секционирования данных BLOB-объектов по диапазонам. Затем диапазоны распределяются с балансировкой нагрузки по хранилищу BLOB-объектов.
Секционирование на основе диапазона означает, что соглашения об именовании, использующие лексическое упорядочение (например, mypayroll, myperformance, myemployees и т. д.) или метки времени (log20160101, log2010102, log20160102 и т. д.) скорее всего, приводят к совместному расположению секций на одном сервере секций, пока не требуется, чтобы они были разделены на меньшие диапазоны. Совместное размещение BLOB-объектов на одном сервере секционирования повышает производительность, поэтому важным фактором повышения производительности будет наименование BLOB-объектов способом, который наиболее эффективно организует их.
Например, все BLOB-объекты в контейнере могут обрабатываться одним и тем же сервером, пока нагрузка на эти BLOB-объекты не потребует дополнительного перераспределения диапазонов секций. Точно так же группу незначительно нагруженных учетных записей с именами, упорядоченными в лексическом порядке, может обслуживать один и тот же сервер, пока нагрузка на одну или несколько из этих учетных записей не потребует их разделения между несколькими серверами секционирования.
Каждая операция балансировки нагрузки может вызывать задержку вызовов хранилища во время ее выполнения. Способность службы справляться с внезапным всплеском трафика в секции ограничивается масштабированием единственного сервера секционирования, пока не будет запущена операция балансировки нагрузки, которая перераспределит диапазон ключей секций.
Частоту выполнения таких операций можно уменьшить.
Если возможно, используйте BLOB-объекты или размеры блоков, превышающие 256 КиБ для стандартных учетных записей хранения и для учетных записей хранения класса "Премиум". BLOB-объекты или блоки большего размера автоматически активируют блочные BLOB-объекты с высокой пропускной способностью. Большие двоичные объекты блока с высокой пропускной способностью обеспечивают высокопроизводительную приемку, которая не влияет на именование секций.
Изучите используемое соглашение об именовании учетных записей, контейнеров, BLOB-объектов, таблиц и очередей. К именам учетных записей, контейнеров или BLOB-объектов можно добавить трехзначный хэш в виде префикса, используя функцию хэширования, наиболее соответствующую вашим задачам.
Если вы упорядочиваете данные с помощью меток времени или числовых идентификаторов, убедитесь, что вы не используете шаблон трафика только для добавления (или только предварительной версии). Эти шаблоны не подходят для системы секционирования на основе диапазона. Использование этих шаблонов может привести к тому, что весь трафик попадет в один раздел и ограничит эффективную балансировку нагрузки в системе.
Например, если выполняются ежедневные операции, использующие BLOB-объект с меткой времени в формате ггггммдд, весь трафик ежедневной операции направляется в один BLOB-объект, который обслуживается одним сервером секционирования. Проверьте, соответствуют ли ограничения по BLOB-объектам и ограничения по секциям вашим потребностям и, при необходимости, разбейте эту операцию на несколько BLOB-объектов. Подобным образом, если в таблицах хранятся данные временных рядов, весь трафик может направляться в последнюю часть ключевого пространства имен. Если вы используете числовые идентификаторы, префикс идентификатора с тремя цифрами хэша. Если вы используете метки времени, префикс метки времени со значением секунд, например ssyyymmdd. Если приложение обычно выполняет перечисление и запросы, выберите хэш-функцию, которая ограничивает количество запросов. В некоторых случаях достаточно добавить случайный префикс.
Дополнительные сведения о схеме секционирования, используемой в службе хранилища Azure, см. в статье Служба хранилища Azure: высокодоступная служба облачного хранения со строгой согласованностью.
Сеть
Физические ограничения сети, в которой работает приложение, оказывают существенное влияние на производительность. В следующих разделах описаны некоторые ограничения, с которыми могут столкнуться пользователи.
Возможности клиентской сети
Пропускная способность и качество сетевого подключения являются важными факторами, влияющими на производительность приложения, как описано в следующих разделах.
Пропускная способность
Что касается полосы пропускания, частой проблемой являются возможности клиента. Очень крупные экземпляры Azure имеют сетевые карты, обладающие большими возможностями, поэтому если необходимы более высокие сетевые ограничения от одной машины, следует рассмотреть возможность использования более крупного экземпляра или большего количества виртуальных машин. Если вы обращаетесь к служба хранилища Azure из локального приложения, то применяется то же правило: понять сетевые возможности клиентского устройства и сетевое подключение к расположению служба хранилища Azure и улучшить их по мере необходимости или разработать приложение для работы в рамках своих возможностей.
Качество связи
Как и при любом использовании сети, следует помнить, что сетевые условия приводят к ошибкам и потере пакетов замедляет эффективную пропускную способность. Использование инструмента WireShark или NetMon может помочь в диагностике этой проблемы.
Расположение
В любой распределенной среде наилучшее быстродействие достигается при нахождении клиента рядом с сервером. Для доступа к хранилищу Azure с наименьшей задержкой лучшим местом для клиента будет его нахождение в том же регионе Azure. Например, если ваше веб-приложение Azure использует службу хранилища Azure, обе службы лучше разместить в пределах одного региона (западная часть США, Юго-Восточная Азия и т. д.). Совместное размещение ресурсов уменьшает задержку и снижает стоимость, так как трафик в пределах одного региона остается бесплатным.
Если клиентские приложения получают доступ к служба хранилища Azure, но не размещаются в Azure, например приложения для мобильных устройств или локальных корпоративных служб, то поиск учетной записи хранения в регионе рядом с этими клиентами может снизить задержку. Если клиенты разбросаны по всему миру (например, часть в Северной Америке, а остальные в Европе), обдумайте вариант с несколькими учетными записями хранения, по одной в каждом регионе. Этот подход проще реализовать, если данные хранилища приложений относятся к отдельным пользователям и не требуют репликации данных между учетными записями хранения.
Для широкого распространения содержимого BLOB-объектов используйте сеть доставки содержимого, например Azure CDN. Для получения дополнительной информации о сети Azure CDN см. статью Сеть кэширующих серверов.
SAS и CORS
Предположим, что вам нужно создать код JavaScript, который выполняется в веб-браузере пользователя или приложении на мобильном телефоне и обращается к данным в службе хранилища Azure. Один из вариантов — создать приложение-службу, которое выполнит роль прокси-сервера. Устройство пользователя проходит проверку подлинности в этой службе, которая, в свою очередь, предоставляет доступ к ресурсам службы хранилища Azure. Таким образом, на небезопасных устройствах можно не сообщать ключи своей учетной записи хранения. Но такой подход создает значительную нагрузку на приложение-службу, через которое проходят все данные, передаваемые между пользовательским устройством и службой хранилища Azure.
Вы можете обойтись без приложения-службы прокси-сервера, обращаясь к службе хранилища Azure с использованием подписанных URL-адресов (SAS). С технологией SAS вы можете разрешить пользовательскому устройству напрямую обращаться к службе хранилища Azure с маркером ограниченного доступа. Например, если пользователь хочет отправить фотографию в приложение, приложение-служба создаст SAS и отправит его на устройство пользователя. Маркер SAS может предоставлять разрешение на запись в ресурс службы хранилища Azure в течение указанного интервала времени. По истечении этого времени маркер SAS становится недействительным. Дополнительные сведения о подписанных URL-адресах см. в статье об использование подписанных URL-адресов SAS в службе хранилища Azure.
Как правило, веб-браузер не разрешает JavaScript на странице, размещенной веб-сайтом на одном домене, выполнять определенные операции, такие как операции записи, в другой домен. Эта политика использования одного источника не позволяет вредоносному коду с любой веб-страницы получить доступ к данным, размещенным на другой странице. Но при создании облачного решения политика использования одного источника становится неудобным ограничением. Реализуемая на уровне браузера технология CORS (общий доступ к ресурсам независимо от источника) позволяет целевому домену сообщать браузеру, что он доверяет запросам, поступающим из определенных исходных доменов.
Предположим, что выполняемое в Azure веб-приложение обращается к ресурсу в учетной записи хранения Azure. В этом сценарии веб-приложение выполняет роль исходного домена, а учетная запись хранения является целевым доменом. Вы можете настроить CORS для любой из служб хранилища Azure, чтобы она сообщала веб-браузеру о том, что служба хранилища Azure доверяет запросам, поступающим из исходного домена. Дополнительные сведения о технологии CORS см. в статье Cross-Origin Resource Sharing (CORS) support for Azure Storage (Поддержка общего доступа к ресурсам независимо от источника (CORS) для службы хранилища Azure).
Технологии SAS и CORS помогают избавиться от лишней нагрузки на веб-приложения.
Кэширование
Кэширование играет важную роль в обеспечении производительности. В следующих разделах рассматриваются рекомендации по кэшированию.
Чтение данных
Как правило, однократное чтение данных лучше, чем двукратное. Рассмотрим пример веб-приложения, которое получило BLOB-объект размером 50 МиБ из службы хранилища Azure для использования в качестве содержимого для пользователя. В идеале приложение локально кэширует BLOB-объект на диск, а затем извлекает кэшированную версию для последующих запросов пользователей.
Одним из способов избежать получения BLOB-объекта (если он не был изменен с момента кэширования) является определение операции GET с условным заголовком для времени изменения. Если время последнего изменения наступает позже момента кэширования BLOB-объекта, BLOB-объект извлекается и повторно кэшируется. В ином случае кэшированный BLOB-объект извлекается для оптимизации производительности.
Кроме того, можно разработать собственное приложение, предполагая, что BLOB-объект остается неизменным в течение короткого периода после его получения. В этом случае приложению не нужно проверять, был ли большой двоичный объект изменен в течение этого интервала.
Прекрасными кандидатами на кэширование являются данные конфигурации, поиска, а также другие данные, которые часто используются приложением.
Дополнительные сведения об использовании условных заголовков см. в статье Определение условных заголовков для операций службы BLOB-объектов.
Передача данных в пакетах
В некоторых сценариях можно объединять данные локально, а затем периодически отправлять их в пакете вместо немедленной отправки каждого фрагмента данных. Например, предположим, что веб-приложение сохраняет файл журнала действий. Приложение может отправлять сведения о каждом действии по мере его выполнения в таблицу (при этом выполняется большое количество операций с хранилищем), либо сохранять сведения о действиях в локальном файле журнала и периодически отправлять все сведения о действиях в виде файла с разделителями в BLOB-объект. Если размер каждой записи журнала составляет 1 КБ, за одну операцию можно отправлять тысячи записей. Одна транзакция поддерживает передачу BLOB-объекта размером до 64 МиБ. Разработчик приложения должен учитывать возможность сбоя клиентского устройства или отправки. Если данные о действиях необходимо загружать в течение определенного временного интервала, а не после одного действия, то рекомендуется использовать хранилище BLOB-объектов вместо хранилища таблиц.
Конфигурация .NET
Для проектов, использующих платформа .NET Framework, в этом разделе перечислены некоторые быстрые параметры конфигурации, которые можно использовать для повышения производительности. Если вы используете язык, отличный от .NET, проверьте, применяются ли аналогичные понятия на выбранном языке.
Увеличение стандартного ограничения на количество подключений
Примечание.
Этот раздел применяется к проектам с помощью платформа .NET Framework, так как пул подключений управляется классом ServicePointManager. .NET Core представила значительное изменение управления пулом подключений, где пул подключений происходит на уровне HttpClient, а размер пула по умолчанию не ограничен. Это означает, что HTTP-подключения автоматически масштабируются для удовлетворения рабочей нагрузки. По возможности рекомендуется использовать последнюю версию .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 доступны для многих языков. Обозреватель службы хранилища также поддерживает PowerShell и Azure CLI. Корпорация Майкрософт активно развивает эти клиентские библиотеки и средства, оптимизируя их производительность, поддерживая их согласованность с последними версиями служб и реализуя внутреннюю поддержку для многих проверенных методов повышения производительности.
Совет
Драйвер ABFS разработан для преодоления присущих WASB недостатков. Корпорация Майкрософт рекомендует использовать драйвер ABFS, а не драйвер WASB, так как драйвер ABFS оптимизирован специально для аналитики больших данных.
Обработка ошибок службы
служба хранилища Azure возвращает ошибку, когда служба не может обработать запрос. Понимание ошибок, которые возвращает служба хранилища Azure, и соответствующих сценариев, помогает оптимизировать производительность. Список распространенных кодов ошибок см. в разделе Распространенные коды ошибок REST API.
Ошибки времени ожидания и занятости сервера
Служба хранилища Azure может применять регулирование к приложению, когда его загрузка приближается к ограничениям масштабируемости. В некоторых случаях служба хранилища Azure не может обработать запрос из-за некоторого временного состояния. В обоих случаях служба может вернуть ошибку 503 — Server Busy (сервер занят) или 500 — Timeout (время ожидания истекло). Эти же ошибки могут возникать, когда служба перераспределяет сегменты данных для повышения пропускной способности. В большинстве случаев при получении таких ошибок приложению следует повторить операцию, которая их вызвала. Однако если служба хранилища Azure регулирует приложение, так как оно превышает целевые показатели масштабируемости, или даже если служба не смогла обслуживать запрос по какой-либо другой причине, агрессивные повторные попытки могут привести к проблеме хуже. Мы рекомендуем использовать экспоненциальную задержку для политики повтора. Во всех клиентских библиотеках именно такое поведение является вариантом по умолчанию. Например, приложение может повторить действие через 2 секунды, затем через 4 секунды, затем через 10 секунд, затем через 30 секунд, а затем полностью отказаться от повторения. Это позволяет приложению значительно снизить нагрузку на службу и не усугублять проблемы, связанные с регулированием.
Ошибки подключения могут быть возвращены немедленно, так как они не являются результатом регулирования и, как ожидается, будут временными.
Ошибки без возможности повтора
Клиентские библиотеки обрабатывают повторные попытки с пониманием того, какие ошибки могут быть извлечены и которые не могут быть извлечены. Однако если вы вызываете служба хранилища Azure REST API напрямую, возникают некоторые ошибки, которые не следует повторить. Например, ошибка 400 (недопустимый запрос) указывает, что клиентское приложение отправило запрос, который не удалось обработать, так как он не был в ожидаемой форме. Повторное выполнение этого запроса приводит к тому же ответу каждый раз, поэтому нет смысла повторять его. Если вы вызываете служба хранилища Azure REST API напрямую, помните о потенциальных ошибках и о необходимости их извлечения.
Дополнительные сведения о кодах ошибок в службе хранилища Azure вы найдете в статье Status and Error Codes (Коды ошибок и состояний).
Копирование и перемещение BLOB-объектов
Служба хранилища Azure предоставляет ряд решений для копирования и перемещения BLOB-объектов в учетной записи хранения, между учетными записями хранения и между локальными системами и облаком. В этом разделе описаны некоторые из этих вариантов с точки зрения их влияния на производительность. Сведения об эффективной передаче данных в хранилище BLOB-объектов и из него см. в статье Выбор решения Azure для передачи данных.
API копирования BLOB-объектов
Чтобы копировать BLOB-объекты в учетных записях хранения, используйте операцию Вставка блока по URL-адресу. Эта операция синхронно копирует данные из любого URL-источника в блочный BLOB-объект. Put Block from URL Использование операции может значительно сократить необходимую пропускную способность при переносе данных между учетными записями хранения. Так как операция копирования выполняется на стороне службы, вам не нужно скачивать и повторно отправлять данные.
Чтобы скопировать данные в одной и той же учетной записи хранения, используйте операцию Копирование BLOB-объектов. Как правило, копирование данных в рамках одной учетной записи хранения выполняется быстро.
Использование AzCopy
Служебная программа командной строки AzCopy — это простой и эффективный вариант для группового перемещения BLOB-объектов в учетные записи хранения, из них и между ними. Инструмент AzCopy оптимизирован для этого сценария и может развивать высокую скорость передачи данных. AzCopy версии 10 использует операцию Put Block From URL для копирования данных BLOB-объектов между учетными записями хранения. Дополнительные сведения см. в статье Копирование или перемещение данных в службу хранилища 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-объектов с помощью глобальной пограничной сети Майкрософт сотнями глобальных и локальных точек присутствия (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 для передачи данных, см. инструкции по настройке производительности для передачи данных.
Быстрая отправка одного BLOB-объекта
Чтобы быстро отправить один большой BLOB-объект, клиентское приложение может параллельно отправлять его блоки или страницы с учетом о целевых показателей для отдельных BLOB-объектов и учетной записи хранения в целом. Клиентские библиотеки службы хранилища Azure поддерживают отправку в параллельном режиме. Клиентские библиотеки для других поддерживаемых языков предоставляют аналогичные возможности.
Быстрая отправка множества BLOB-объектов
Чтобы быстро отправить множество BLOB-объектов, отправьте их параллельно. Параллельная отправка выполняется быстрее, чем отправка отдельных BLOB-объектов с параллельной отправкой блоков, поскольку в данном случае отправка распределяется по нескольким разделам службы хранилища. AzCopy выполняет параллельную отправку по умолчанию, как и рекомендуется для данного случая. Дополнительные сведения см. в статье Начало работы с AzCopy.
Выбор правильного типа BLOB-объекта
Служба хранилища Azure поддерживает блочные, добавочные и страничные BLOB-объекты. В данном сценарии использования выбор типа BLOB-объектов влияет на производительность и масштабируемость решения.
Блочные BLOB-объекты подходят, если надо эффективно передавать большие объемы данных. Например, клиентское приложение, которое отправляет фотографии или видео в хранилище BLOB-объектов, будет ориентироваться на блочные BLOB-объекты.
Добавление больших двоичных объектов аналогично блочных BLOB-объектов в том, что они состоят из блоков. При изменении добавочного BLOB-объекта блоки добавляются только в конец BLOB-объекта. Добавочные BLOB-объекты удобно использовать для таких сценариев, как ведение журналов, если приложению необходимо добавлять данные в существующий BLOB-объект.
Страничные BLOB-объекты подходят в том случае, если приложение должно выполнять случайные операции записи данных. Например, диски виртуальной машины Azure хранятся как страничные BLOB-объекты. Дополнительные сведения см. в статье Основные сведения о блочных, добавочных и страничных BLOB-объектах.