Разделение для обхода ограничений

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

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

Существует много способов разделения системы, например:

• Разделение базы данных, чтобы избежать ограничений на размер базы данных, ввод-вывод данных и количество одновременных сеансов.

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

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

База данных может быть секционирована горизонтально, вертикально или функционально.

• В горизонтальном секционировании, также называемым сегментированием, каждая секция содержит данные подмножества полного набора данных. Секции используют одну и ту же схему данных. Например, клиенты, имена которых начинаются с A–M, переходят в одну секцию, N–Z — в другую.

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

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

Дополнительные сведения можно найти в статье Data partitioning (Секционирование данных).

Рекомендации

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

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

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

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