Хранение и обработка данных с Windows Azure Storage и Windows Azure SQL Databases

Размер партиции

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

Суть и цели масштабирования по партициям

Цель масштабирования, показатели, которые определяют, сколько может "выдержать" одна партиция, равно 500 сущностей в секунду. Партиции переносятся между серверами хранилища для обеспечения высокой степени эластичности и максимальной производительности. "Горячие", то есть испытывающие высокую степень нагрузки, партиции могут быть вертикально масштабированы - Windows Azure Fabric Controller способен выделить больше ресурсов для партиций с большим количеством транзакций. Таким образом, если на одном сервере расположены три партиции, то, если одна из партиций начинает испытывать высокие нагрузки и большое количество запросов, она может быть перемещена на второй сервер. После того, как нагрузка на нее спадёт, она может быть возвращена на исходный сервер.

Каждый тип хранилища определяет свою партицию:

Очередь->Одна очередь = Одна партиция. Сервис очереди использует имя очереди в качестве ключа партиции, и все сообщения для данной конкретной очереди будут находиться в одной партиции, что означает, что каждая очередь имеет собственную цель масштабирования. Необходимо, однако, учитывать виртуальное ограничение в 500 сущностей в секунду, поэтому, если очередь испытывает нагрузку более 500 сущностей в секунду, необходимо определить, каким образом можно разделить систему на несколько очередей для реализации высокопроизводительного механизма обмена сообщениями.

Таблица -> Одна партиция таблицы = Одна партиция. В сервисе таблиц разработчик сам определяет, как будет партиционироваться таблица, с помощью определения системного свойства PartitionKey. Рекомендуется создавать маленькие многочисленные партиции, так как именно в этом случае будет организована наиболее эффективная масштабируемость на уровне платформы, а вместе с этим и скорость обращения к данным. Каждая сущность будет принадлежать партиции, определенной в ее PartitionKey. Если разработчик использует распространенную практику инкрементирования (или декрементирования) значения PartitionKey, он можете столкнуться с характерным поведением платформы Windows Azure – созданием партиций-диапазонов. Это необходимо для повышения эффективности запросов на диапазоны, которые без партиций-диапазонов должны были бы выходить за пределы партиции или сервера, что понизило бы производительность. Рассмотрим это на примере таблицы ниже.

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

Блоб -> Один блоб = Одна партиция.

При записи в партицию операция считается завершённой по записи на все три реплики.

Избыточность хранилища Windows Azure Storage

В Windows Azure Storage доступно две опции избыточности: Locally Redundant Storage и Geo Redundant Storage.

Locally Redundant Storage (LRS) предоставляет хранилище с высокой степенью долговечности и доступности внутри одной географической локации (региона). Платформа хранит три реплики каждого элемента данных в одной первичной географической локации, что гарантирует, что эти данные можно будет восстановить после сбоя, несущего общий характер (например, выхода из строя диска, узла, корзины и так далее, что является нормальным событием в центре обработки данных) без потери функциональности для аккаунта хранилища и, соответственно, не влияя на доступность и долговечность хранилища. Все операции записи в хранилище выполняются синхронно в три реплики в трех различных доменах ошибок (fault domain), код об успешном завершении транзакции возвращается после успешного завершения всех трех операций. В случае использования локального избыточного хранилища, если центра обработки данных, в котором размещены реплики данных, подвергнется сбою, несущему характер катастрофы (стихийной, техногенной или любой другой, которая приведет к потере подключения к центру обработки данных либо потере самого центра), Microsoft свяжется с клиентом и сообщит о возможной потере информации и данных, используя контакты, приведенные в подписке клиента.

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

Когда осуществляются операции создания, удаления, обновления, транзакция полностью реплицируется в три узла хранилища в трех доменах ошибок и обновлений в первичной географической локации, после чего клиенту возвращается код успешного завершения операции и в асинхронном режиме подтвержденная транзакция реплицируется во вторичную локацию, где полностью реплицируется в три узла хранилища в разных доменах ошибок и обновлений. Общая производительность при этом не падает, так как всё совершается асинхронно. Если происходит серьезный сбой в первичной географической локации, применяются правила географической отказоустойчивости, то клиент оповещается о возникшей катастрофе в первичной локации, после чего соответствующие ресурсные DNS-записи изменяются и начинают вести не на первичную локацию, но на вторую (DNS-запись account.service.core.windows.net). В процессе перевода DNS-записей могут наблюдаться сбои в работе, но по его завершению существующие блобы и таблицы становятся доступными по их прежним URL-ам. После завершения процесса перевода вторичная локация повышается в статусе до первичной; по завершению процесса повышения статуса центра обработки данных инициируется процесс создания новой вторичной географической локации в этом же регионе и дальнейшей репликации данных.

Рассмотрим реальный пример, взятый из блога разработчиков Windows Azure Storage. В аккаунте хранилища размещено несколько блобов, foo и bar. Для блобов полное имя блоба равно значению PartitionKey. Разработчик выполняет две транзакции A и B на блобе foo, после чего выполняет две транзакции X и Y на блобе bar. Система гарантирует, что транзакция А будет географически реплицирована перед транзакцией B, и, соответственно, транзакция X будет географически реплицирована перед транзакцией Y.

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

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