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

Статья
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 Data Factory для репликации базы данных управляющего картами сегментов в разных регионах. Этот вид репликации выполняется периодически и более подходит, если карта сегментов изменяется нечасто и не требует премиум-уровня.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соображения

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

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

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

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

список проверки надежности

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

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

Основные стратегии проектирования