Рекомендации по секционированию данных

Статья
11/15/2023

Применяется к этой рекомендации по контрольным спискам надежности Платформы Azure Well-Architected Framework:

RE:06	Реализуйте своевременную и надежную стратегию масштабирования на уровне приложений, данных и инфраструктуры.

Связанное руководство.Масштабирование

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

Ключевые стратегии проектирования

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

Примечание

Термин секционирование в этом руководстве обозначает процесс физического разделения данных на отдельные хранилища. Он отличается от SQL Server секционирования таблиц.

Зачем секционировать данные?

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

Проектирование секций

Ниже представлены три распространенных стратегии секционирования данных:

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

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

Горизонтальное секционирование (сегментирование)

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

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

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

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

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

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

Дополнительные сведения см. в статье о шаблоне сегментирования.

Вертикальное секционирование

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

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

Ознакомьтесь со следующими преимуществами вертикального секционирования:

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

Вертикальное секционирование выполняется на уровне сущности в хранилище данных, частично нормализуя сущность и преобразуя ее из широкого элемента в набор узких элементов. Он идеально подходит для хранилищ данных, ориентированных на столбцы, таких как HBase и Cassandra. Если данные в коллекции столбцов вряд ли изменятся, рассмотрите возможность использования хранилищ столбцов в SQL Server.

Функциональное секционирование

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

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

Проектирование секций для масштабируемости

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

При проектировании секций для масштабируемости выполните следующие действия.

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

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

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

Проектирование секций для повышения производительности запросов

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

При проектировании секций для повышения производительности запросов выполните следующие действия.

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

Проектирование секций для обеспечения доступности

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

Учитывайте следующие факторы, влияющие на доступность:

Определите важность данных. Определите критически важные бизнес-данные, такие как транзакции, и менее важные операционные данные, такие как файлы журналов.

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

Управление отдельными секциями. Проектирование секций для поддержки независимого управления и обслуживания. Эта практика предоставляет несколько преимуществ, например:

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

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

Рекомендации по проектированию приложений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Учитывайте следующие факторы, влияющие на оперативное управление.

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

Перераспределение секций

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

Некоторые хранилища данных, такие как Azure Cosmos DB, могут автоматически перебалансировать секции. В других случаях можно перераспределировать секции в два этапа:

Определение новой стратегии секционирования.
- Какие секции необходимо разделить или объединить?
- Что такое новый ключ секции?
Перенос данных из старой схемы секционирования в новый набор секций.

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

Автономная миграция

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

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

Миграция по сети

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

Упрощение azure

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

Секционирование в базе данных Azure SQL

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

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

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

Приложения отвечают за связывание набора данных с ключом шардлета. Отдельная база данных SQL выступает в роли глобального диспетчера сопоставления сегментов. Эта база данных содержит список всех сегментов и шардлетов в системе. Приложение подключается к базе данных диспетчера карты сегментов для получения копии карты сегментов. Он кэширует карту сегментов локально и использует карту для маршрутизации запросов данных в соответствующий сегмент. Эта функция скрыта за рядом API- интерфейсов, содержащихся в клиентской библиотеке компонента эластичной базы данных База данных SQL, доступного для Java и .NET.

Дополнительные сведения об эластичных пулах см. в статье Масштабирование с помощью База данных SQL.

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

Кроме того, используйте Синхронизация данных SQL для База данных SQL или Фабрика данных Azure для репликации базы данных диспетчера карт сегментов между регионами. Эта форма репликации выполняется периодически и более подходит, если карта сегментов меняется редко и не требует уровня "Премиум".

Эластичная база данных предоставляет две схемы для сопоставления данных и шардлетов и их хранения в сегментах.

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

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

Скачивание файла Visio этой схемы

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

Скачайте файл Visio этой схемы.

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

Если приложению требуется разбить сегмент на два отдельных сегмента или объединить их, можно использовать средство разделения и объединения. Это средство выполняется как веб-служба Azure и безопасно переносит данные между сегментами.

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

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

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

Секционирование в Хранилище BLOB-объектов Azure

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

Каждый блочный или страничный BLOB-объект хранится в контейнере в учетной записи хранения Azure. Используйте контейнеры для группирования связанных BLOB-объектов с одинаковыми требованиями к безопасности. Это группирование на логическом, а не на физическом уровне. Внутри контейнера каждый BLOB-объект имеет уникальное имя.

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

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

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

Контрольный список надежности

Ознакомьтесь с полным набором рекомендаций.

Контрольный список надежности

Рекомендации по секционированию данных