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

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

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

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

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

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

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

Дополнительные сведения о целевых показателях масштабируемости для службы таблиц см. в статье Целевые показатели масштабируемости и производительности для хранилища таблиц.

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

Если количество учетных записей хранения приближается к максимальному разрешенному количеству для вашего сочетания подписки и региона, используете ли вы несколько учетных записей хранения на каждый сегмент, чтобы повысить скорость приема, передачи, количество операций ввода-вывода в секунду (IOPS) или емкость хранилища? Для такой ситуации корпорация Майкрософт рекомендует увеличить ограничения по учетным записям хранения, если это возможно, чтобы сократить количество учетных записей хранения для рабочей нагрузки. Запрос на увеличение ограничений на количество учетных записей хранения следует направлять в службу поддержки Azure.

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

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

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

Целевые объекты для операций с данными

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

Масштабирование сущностей в секунду (учетная запись хранения)

Ограничение масштабируемости для доступа к таблицам составляет до 20 000 сущностей (каждая по 1 КБ) в секунду для одной учетной записи. Обычно каждая сущность, которая вставляется, обновляется, удаляется или сканируется, идет в счет этой цели. Так, пакетная вставка, которая содержит 100 сущностей, будет считаться за 100 сущностей. Запрос, который сканирует 1000 сущностей и возвращает 5 из них, будет считаться за 1000 сущностей.

Масштабирование сущностей в секунду (раздел)

В одном разделе целевой показатель масштабируемости для доступа к таблицам составляет 2000 сущностей (каждая по 1 КБ) в секунду. Тут используется тот же принцип подсчета, что и описанный в предыдущем разделе.

Сеть

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

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

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

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

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

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

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

Местонахождение

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

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

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 помогают избавиться от лишней нагрузки на веб-приложения.

Пакетные транзакции

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

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

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

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

Для проектов, использующих платформа .NET Framework, можно использовать следующий код, чтобы увеличить ограничение подключения по умолчанию (обычно 2 в клиентской среде или 10 в серверной среде) до 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. Корпорация Майкрософт активно развивает эти клиентские библиотеки и средства, оптимизируя их производительность, поддерживая их согласованность с последними версиями служб и реализуя внутреннюю поддержку для многих проверенных методов повышения производительности.

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

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

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

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

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

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

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

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

Настройка

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

Использовать JSON

Начиная со службы хранилища версии 2013-08-15, для передачи данных таблицы Хранилище таблиц поддерживает формат JSON вместо формата AtomPub на базе XML. Использование JSON может уменьшить размеры полезной нагрузки на 75 %, а следовательно сильно увеличить производительность приложения.

Дополнительные сведения см. в статьях Microsoft Azure Tables: Introducing JSON (Таблицы Microsoft Azure: введение в JSON) и Payload Format for Table Service Operations (Формат полезных данных для операций службы таблиц).

Отключение алгоритма Нейгла

Алгоритм Нейгла широко применяется во всех TCP/IP-сетях в качестве средства повышения производительности сети. Однако это не оптимально во всех обстоятельствах (например, высокоактивные среды). Алгоритм Нейгла оказывает негативное влияние на производительность запросов к службе таблиц Azure, поэтому при возможности его следует отключать.

Схема

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

• конструктору таблиц;
• эффективным запросам;
• эффективным обновлениям данных.

Таблицы и секции

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

• Преимущества: можно обновить сущности в одной секции в рамках одной неделимой пакетной транзакции, содержащей до 100 отдельных операций хранения (общий размер ограничен 4 МБ). Предполагая некоторое количество сущностей, которые будут получены, также можно более эффективно запросить данные, хранящиеся внутри одного раздела, чем данные, охватывающие несколько разделов (в то время как чтение по дальнейшим рекомендациям необходимо проводить по запрашиваемым табличным данным).
• Ограничение масштабируемости. Доступ к сущностям, хранящимся в одной секции, нельзя сбалансировать нагрузку, так как секции поддерживают атомарные пакетные транзакции. По этой причине целевой показатель масштабируемости для отдельного раздела таблицы ниже, чем для службы таблиц в целом.

Учитывая эти характеристики таблиц и разделов, следует принять следующие принципы проектирования:

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

Горячие секции

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

Инкрементируемые и декрементируемые шаблоны

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

Данные с интенсивным трафиком

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

Выполнение запроса

В этом разделе описываются проверенные подходы, касающиеся выполнения запросов Хранилища таблиц.

Область запроса

Существует несколько способов для определения диапазона сущностей для запросов. В следующем списке описаны все варианты для области действия запроса.

• Точечные запросы извлекают ровно одну сущность, указывая одновременно ключ секции и ключ строки нужной сущности. Эти запросы являются эффективными, и их следует использовать везде, где это возможно.
• Запросы разделов. Это запрос, который извлекает набор данных, совместно использующих общий ключ раздела. Как правило, в запросе указывается диапазон значений ключа строки или — в дополнение к ключу раздела — диапазон значений для свойства некоторой сущности. Такие запросы менее эффективны, чем точечные запросы, и их следует использовать с осторожностью.
• Запросы к таблицам: запрос таблицы — это запрос, который получает набор сущностей, которые не используют общий ключ секции. Эти запросы не эффективны, и их следует избегать, если это возможно.

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

Плотность запросов

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

Ограничение объема возвращаемых данных

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

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

Денормализация

В отличие от работы с реляционными базами данных, проверенные подходы для осуществления эффективного запроса данных таблицы ведут к денормализации данных. Таким образом, дедупликация одинаковых данных в нескольких сущностях (по одному для каждого ключа, который можно использовать для поиска данных), чтобы свести к минимуму количество сущностей, которые запрос должен сканировать, чтобы найти данные, необходимые клиенту, а не проверять большое количество сущностей для поиска данных, необходимых приложению. Например, на веб-сайте электронной коммерции может потребоваться найти заказ как по идентификатору клиента (дать мне заказы этого клиента), так и по дате (дать мне заказы на дату). В таблице служба хранилища лучше хранить сущность (или ссылку на нее) дважды — один раз с именем таблицы, PK и RK для упрощения поиска по идентификатору клиента, чтобы упростить поиск по дате.

Вставка, обновление и удаление

В этом разделе описываются проверенные методики для изменения сущностей, хранящихся в Хранилище таблиц.

Пакетная обработка

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

Upsert

Используйте табличные операции Upsert как можно чаще. Существует два типа операций Upsert. Оба они могут быть более эффективными, чем обычные операции Insert и Update:

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

Хранение ряда данных в одной сущности

Иногда приложение хранит ряд данных, которые часто бывают необходимыми для их единовременного получения: например, приложение может отслеживать загрузку ЦП в течение долгого времени для того, чтобы построить волнообразный график из данных за последние 24 часа. Один подход заключается в том, чтобы для каждого часа иметь одну табличную сущность, при этом каждая сущность представляет определенный час и хранит значение загрузки ЦП для этого часа. Для построения этих данных приложению необходимо извлечь сущности, в которых хранятся данные за последние 24 часа.

Кроме того, приложение может хранить данные о загрузке ЦП для каждого часа в виде отдельного свойства одной сущности: для ежечасного обновления приложение может использовать один вызов InsertOrMerge Upsert, чтобы обновить значение за последний час. Для построения этих данных приложению необходимо получить только одну сущность, а не 24, что означает повышение эффективности запроса. Дополнительные сведения об эффективности запросов см. в разделе "Запрос область".

Хранение структурированных данных в BLOB-объектах

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

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

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