Промежуточная память используется для компенсации данных

Обновлено: 22.11.2024

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

Очередь передачи

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

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

Измените QueueFamilyIndices и findQueueFamilies, чтобы явно искать семейство очередей с битом VK_QUEUE_TRANSFER_BIT, но не с битом VK_QUEUE_GRAPHICS_BIT.
Измените createLogicalDevice, чтобы запросить дескриптор очереди передачи.
Создайте второй пул команд для буферов команд, которые отправляются в семейство очередей передачи.
Измените режим совместного использования ресурсов на VK_SHARING_MODE_CONCURRENT и укажите семейства очередей графики и очереди передачи.
Отправьте любые команды передачи, такие как vkCmdCopyBuffer (которую мы будем использовать в этой главе), в очередь передачи, а не в очередь графики.

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

Абстракция создания буфера

Поскольку в этой главе мы собираемся создать несколько буферов, рекомендуется перенести создание буфера во вспомогательную функцию. Создайте новую функцию createBuffer и переместите в нее код из createVertexBuffer (кроме сопоставления).

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

Теперь вы можете удалить код создания буфера и выделения памяти из createVertexBuffer и вместо этого просто вызвать createBuffer:

Запустите программу, чтобы убедиться, что буфер вершин по-прежнему работает правильно.

Использование промежуточного буфера

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

Теперь мы используем новый stagingBuffer с stagingBufferMemory для сопоставления и копирования данных вершин. В этой главе мы собираемся использовать два новых флага использования буфера:

VK_BUFFER_USAGE_TRANSFER_SRC_BIT: буфер может использоваться в качестве источника в операции передачи памяти.
VK_BUFFER_USAGE_TRANSFER_DST_BIT: буфер может использоваться в качестве места назначения в операции передачи памяти.

Теперь vertexBuffer выделяется из памяти локального типа устройства, что обычно означает, что мы не можем использовать vkMapMemory. Однако мы можем скопировать данные из stagingBuffer в vertexBuffer. Мы должны указать, что намерены сделать это, указав флаг источника передачи для stagingBuffer и флаг назначения передачи для vertexBuffer вместе с флагом использования буфера вершин.

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

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

И сразу начать запись командного буфера:

Мы собираемся использовать буфер команд только один раз и ждать с возвратом из функции, пока не завершится выполнение операции копирования. Рекомендуется сообщать водителю о наших намерениях с помощью VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT .

Содержимое буферов переносится с помощью команды vkCmdCopyBuffer. Он принимает буферы источника и назначения в качестве аргументов и массив областей для копирования.Области определяются в структурах VkBufferCopy и состоят из смещения исходного буфера, смещения буфера назначения и размера. Здесь нельзя указать VK_WHOLE_SIZE, в отличие от команды vkMapMemory.

Этот буфер команд содержит только команду копирования, поэтому мы можем остановить запись сразу после этого. Теперь выполните командный буфер, чтобы завершить передачу:

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

Не забудьте очистить буфер команд, используемый для операции передачи.

Теперь мы можем вызвать copyBuffer из функции createVertexBuffer, чтобы переместить данные вершин в локальный буфер устройства:

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

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

Заключение

Следует отметить, что в реальном приложении вы не должны вызывать vkAllocateMemory для каждого отдельного буфера. Максимальное количество одновременных выделений памяти ограничено ограничением физического устройства maxMemoryAllocationCount, которое может достигать 4096 даже на высокопроизводительном оборудовании, таком как NVIDIA GTX 1080. Правильный способ выделения памяти для большого количества объектов одновременно заключается в создании пользовательского распределителя, который разделяет одно выделение между множеством разных объектов, используя параметры смещения, которые мы видели во многих функциях.

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

В этой статье описываются компоненты архитектуры Synapse SQL.

Компоненты архитектуры Synapse SQL

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

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

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

Synapse SQL использует архитектуру на основе узлов. Приложения подключаются и отдают команды T-SQL узлу управления, который является единственной точкой входа для Synapse SQL.

Узел Azure Synapse SQL Control использует механизм распределенных запросов для оптимизации запросов для параллельной обработки, а затем передает операции вычислительным узлам для параллельного выполнения своей работы.

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

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

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

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

Хранилище Azure

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

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

Узел управления

Узел управления — это мозг архитектуры. Это внешний интерфейс, который взаимодействует со всеми приложениями и соединениями.

В Synapse SQL механизм распределенных запросов работает на узле управления для оптимизации и координации параллельных запросов. Когда вы отправляете запрос T-SQL в выделенный пул SQL, узел управления преобразует его в запросы, которые выполняются для каждого распределения параллельно.

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

Вычислительные узлы

Вычислительные узлы обеспечивают вычислительную мощность.

В выделенном пуле SQL распределения сопоставляются с вычислительными узлами для обработки. По мере того как вы платите за дополнительные вычислительные ресурсы, пул повторно сопоставляет распределения с доступными вычислительными узлами. Количество вычислительных узлов варьируется от 1 до 60 и определяется уровнем обслуживания для выделенного пула SQL. Каждый вычислительный узел имеет идентификатор узла, который отображается в системных представлениях. Вы можете увидеть идентификатор вычислительного узла, найдя столбец node_id в системных представлениях, имена которых начинаются с sys.pdw_nodes. Список этих системных представлений см. в разделе Системные представления Synapse SQL.

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

Служба перемещения данных

Служба перемещения данных (DMS) – это технология передачи данных в выделенном пуле SQL, которая координирует перемещение данных между вычислительными узлами. Для некоторых запросов требуется перемещение данных, чтобы параллельные запросы возвращали точные результаты. Когда требуется перемещение данных, DMS гарантирует, что нужные данные попадут в нужное место.

Распространения

Распределение — это базовая единица хранения и обработки параллельных запросов, которые выполняются с распределенными данными в выделенном пуле SQL. Когда выделенный пул SQL выполняет запрос, работа делится на 60 меньших запросов, которые выполняются параллельно.

Каждый из 60 небольших запросов выполняется в одном из распределений данных. Каждый вычислительный узел управляет одним или несколькими из 60 дистрибутивов. Выделенный пул SQL с максимальным количеством вычислительных ресурсов имеет одно распределение на вычислительный узел. Выделенный пул SQL с минимальными вычислительными ресурсами содержит все дистрибутивы на одном вычислительном узле.

Таблицы с распределенным хэшем

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

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

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

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

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

Циклические распределенные таблицы

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

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

Реплицированные таблицы

Реплицированная таблица обеспечивает максимальную производительность запросов для небольших таблиц.

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

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

Дальнейшие шаги

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

Интеграция гибридных данных в корпоративном масштабе стала проще

Изучите ряд возможностей интеграции данных в соответствии с вашими потребностями в масштабе, инфраструктуре, совместимости, производительности и бюджете — от управляемых служб SQL Server Integration Services для беспрепятственного переноса проектов SQL Server в облако до крупномасштабных бессерверных конвейеров данных. для интеграции данных всех форм и размеров.

Изучите варианты цен

Применяйте фильтры, чтобы настроить параметры ценообразования в соответствии с вашими потребностями.

Цены являются ориентировочными и не являются фактическими котировками. Фактические цены могут различаться в зависимости от типа соглашения, заключенного с Microsoft, даты покупки и курса обмена валюты. Цены рассчитываются в долларах США и конвертируются с использованием эталонных курсов Thomson Reuters, обновляемых в первый день каждого календарного месяца. Войдите в калькулятор цен Azure, чтобы увидеть цены на основе вашей текущей программы/предложения от Microsoft. Свяжитесь со специалистом по продажам Azure, чтобы получить дополнительные сведения о ценах или запросить ценовое предложение. Ознакомьтесь с часто задаваемыми вопросами о ценах на Azure.

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

Важно! Цена в реалах является ориентировочной; это международная сделка, и окончательная цена зависит от обменного курса и включает налоги IOF. eNF выдаваться не будет.

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

Фабрика данных Azure версии 2
Фабрика данных Azure, версия 1

Стоимость конвейера данных рассчитывается на основе:

Конвейерная координация и выполнение
Выполнение потока данных и отладка
Количество операций фабрики данных, таких как создание конвейеров и мониторинг конвейеров.

Оркестровка и выполнение конвейера фабрики данных

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

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

(До 50 одновременных действий конвейера)

(До 800 одновременных действий в конвейере)

Под оркестровкой понимаются запуски действий, запуски триггеров и запуски отладки.
Использование действия копирования для вывода данных из центра обработки данных Azure повлечет за собой дополнительную плату за пропускную способность сети, которая будет отображаться отдельной строкой в вашем счете за передачу исходящих данных. Узнайте больше о ценах на передачу исходящих данных.
Операции конвейера выполняются во время выполнения интеграции. Действия конвейера включают операции поиска, получения метаданных, удаления и схемы во время разработки (проверка соединения, просмотр списка папок и списка таблиц, получение схемы и предварительный просмотр данных).
Действия внешнего конвейера управляются во время выполнения интеграции, но выполняются в связанных службах. К внешним действиям относятся блоки данных, хранимые процедуры, действия HDInsight и многое другое. Полный список внешних мероприятий см. здесь. Информацию о сопоставлении потока данных см. в разделе «Выполнение и отладка потока данных фабрики данных» ниже.

Выполнение потока данных и отладка

Потоки данных — это визуально разработанные компоненты внутри фабрики данных, которые позволяют преобразовывать данные в нужном масштабе. Вы платите за время выполнения и отладки кластера Data Flow за каждый час виртуального ядра. Минимальный размер кластера для запуска потока данных — 8 виртуальных ядер. Стоимость выполнения и отладки рассчитывается пропорционально поминутно и округляется в большую сторону.

Тип	Цена	Зарезервировано на один год (% экономии)	Зарезервировано на три года (% экономии)
Общего назначения	$- за виртуальное ядро- час	$- за час виртуального ядра	$- за час виртуального ядра
Оптимизация памяти	$- за час виртуального ядра	$- за час виртуального ядра	$- за час виртуального ядра

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

Операции с фабрикой данных

< /tbody>

Тип	Цена	Примеры
Чтение/запись*	$- за 50 000 измененных/связанных сущностей	Чтение/запись сущностей в Фабрике данных Azure*
Мониторинг	$- за 50 000 извлеченных записей о прогонах	Мониторинг конвейера, активности, триггеров и отладочных прогонов**

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

** Операции мониторинга включают в себя получение и список для конвейера, активности, триггера и отладки.

Цены на использование Фабрики данных рассчитываются на основе следующих факторов:

Частота действий (высокая или низкая). Низкочастотная активность не выполняется чаще одного раза в день (например, ежедневно, еженедельно, ежемесячно); высокочастотная активность выполняется более одного раза в день (например, ежечасно, каждые 15 минут). Подробнее см. в разделе "Организация действий" ниже.
Где выполняются действия (в облаке или локально). См. раздел "Перемещение данных" ниже.
Независимо от того, активен конвейер или нет. См. раздел «Неактивные конвейеры» ниже.
Выполняете ли вы операцию повторно. См. раздел «Повторное выполнение действий» ниже.

Организация действий

При использовании более 100 действий в месяц предоставляется скидка 20 % как для сценариев с низкой, так и с высокой частотой.
Первые 5 низкочастотных действий в месяц предоставляются бесплатно как в облачном, так и в локальном вариантах.

Перемещение данных

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

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

Перемещение данных между облачными хранилищами данных	$- в час
Перемещение данных при локальном хранилище задействовано	$- в час

Неактивные конвейеры

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

За неактивный конвейер взимается плата в размере – долл. США в месяц.

Конвейеры, которые неактивны в течение всего месяца, оплачиваются по применимой месячной ставке для неактивных конвейеров. Конвейеры, которые неактивны в течение части месяца, оплачиваются за периоды их неактивности пропорционально количеству часов, в течение которых они неактивны в этом месяце. Например, если конвейер имеет дату и время начала 01.01.2016 в 00:00 и дату и время окончания 20 января 2016 в 00:00, конвейер считается активным в течение этих 20 дней. и неактивен 11 дней. Плата за неактивный конвейер ( $- ) распределяется пропорционально за 11 дней.

Если для конвейера не указан активный период обработки данных (время начала и окончания), он считается неактивным.

Повторное выполнение действий

При необходимости действия можно запустить повторно (например, если источник данных был недоступен во время запланированного запуска). Стоимость повторного выполнения действий варьируется в зависимости от места, где выполняется действие. Стоимость повторного запуска действий в облаке составляет $- за 1000 повторных запусков. Стоимость повторного выполнения действий в локальной среде — $ за 1000 повторных запусков.

Пример

Предположим, у вас есть конвейер данных со следующими двумя действиями, которые выполняются один раз в день (низкочастотно):

Действие копирования, которое копирует данные из локальной базы данных SQL Server в большой двоичный объект Azure.
Действие Hive, запускающее сценарий куста в кластере Azure HDInsight.

Предположим, что перемещение данных из локальной базы данных SQL Server в хранилище BLOB-объектов Azure занимает 2 часа в день. В следующей таблице показаны расходы, связанные с этим конвейером:

< /tr>

Первое действие (копирование данных из локальной среды в Azure)
Стоимость перемещения данных (в месяц)	30 дней в месяц
2 часа в день
$-
$-
Стоимость организации мероприятий (в месяц)	$-
Промежуточный итог (в месяц)	$-
Второе действие (скрипт Hive, запущенный в Azure HDInsight)
Стоимость перемещения данных (в месяц)	$-
Стоимость организации действий (в месяц) месяц)	$-
Промежуточный итог (в месяц)	$-
Общая активность (в месяц)	$-

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

Примечания:

За первые пять облачных и локальных действий плата не взимается. Упомянутые выше платежи предполагают, что вы уже использовали пять облачных и пять локальных действий в месяц (в других конвейерах).
Сервисы Azure Storage и HDInsight оплачиваются отдельно по расценкам за обслуживание.

Цены на Azure и варианты приобретения

Свяжитесь с нами напрямую

Познакомьтесь с ценами на Azure. Узнайте о ценах на свое облачное решение, узнайте об оптимизации затрат и запросите индивидуальное предложение.

Способы покупки

Приобретайте службы Azure через веб-сайт Azure, у представителя Microsoft или у партнера Azure.

Читайте также: