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

Статья
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.

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

Одна база данных 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-объектов.

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

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

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

Поделиться через

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