Выбор ключа секции
Помните, что данные в документах JSON хранятся в базах данных и контейнерах Azure Cosmos DB, которые, в свою очередь, распределены по физическим секциям, где данные направляются в соответствующую физическую секцию в зависимости от значения ключа секции.
Ключ секции — это обязательное свойство документа, которое гарантирует, что документы с одинаковым значением ключа секции направляются в определенную физическую секцию и хранятся в ней. Физическая секция поддерживает фиксированный максимальный объем хранилища и пропускную способность (ЕЗ/с). Azure Cosmos DB автоматически распределяет логические секции по доступным физическим секциям предсказуемым образом благодаря значению ключа секции.
В этом блоке вы узнаете о логических секциях и о том, как избежать использования горячего секционирования. Эта информация поможет нам выбрать соответствующий ключ секции для данных клиента в нашем сценарии.
В Azure Cosmos DB вы увеличиваете объем хранилища и пропускную способность, добавляя дополнительные физические секции для доступа к данным и их хранения. Максимальный размер хранилища физической секции составляет 50 ГБ, а максимальная пропускная способность — 10 000 единиц запроса в секунду.
Логические секции в Azure Cosmos DB
Логическая секция — это абстракция над базовыми физическими секциями. В одной физической секции можно хранить несколько логических секций. Контейнер может иметь неограниченное количество логических секций. Отдельные логические секции перемещаются в новые физические секции по мере увеличения размера, чтобы обеспечить оптимальное использование и рост хранилища. Перемещение логических секций в качестве единого целого гарантирует, что все документы внутри них будут находиться в одной физической секции. Максимальный размер логической секции составляет 20 ГБ. Использование ключа секции с большой кратностью позволяет избежать ограничения в 20 ГБ за счет того, что данные распределяются по большему числу логических секций. Вы также можете использовать иерархические ключи секционирования, которые упорядочивают значения ключей секции в иерархии, чтобы избежать этого ограничения. Они рассматриваются в другой схеме обучения.
Ключ секции предоставляет способ маршрутизации данных для логической секции. Это свойство, которое существует в каждом документе в контейнере, который маршрутизирует ваши данные. Контейнер — это другая абстракция для всех данных, хранящихся с одним ключом секции. Ключ секции определяется при создании контейнера.
В следующем примере контейнер имеет ключ секции /username.
Как избежать горячих разделов
При моделировании данных для Azure Cosmos DB важно, чтобы ключ секции, выбранный вами, приводит к равномерному распределению данных и запросов как по логическому, так и по расширению, физическим секциям в контейнере. Это особенно важно при расширении контейнеров и увеличении числа физических секций.
Если не тестировать проект базы данных под нагрузкой во время разработки, факт неудачного выбора ключа секции может оставаться незамеченным до тех пор, пока приложение не окажется в рабочей среде и в него не будет записано много данных.
Если данные не секционированы должным образом, это может привести к созданию горячих разделов. Горячие секции предотвращают масштабирование рабочей нагрузки приложения и могут возникать как для хранилища, так и для пропускной способности.
Горячие секции хранилища
Горячее секционирование в хранилище происходит при наличии ключа секции, который приводит к высокоасимметричным шаблонам хранения. Например, рассмотрим мультитенантное приложение, которое использует TenantId в качестве ключа секции с шестью клиентами: A to F. Tenants B,C,E и F очень малы, клиент D имеет немного больше данных. Клиент А растет и быстро достигает предела в 20 ГБ для своей секции. В этом случае нам нужен другой ключ секции, который будет распределять объем хранилища по нескольким логическим секциям.
Горячее секционирование пропускной способности
Если большинство или все запросы отправляются на один и тот же логический раздел, пропускная способность может пострадать от горячих разделов.
Важно понимать шаблоны доступа приложения, чтобы обеспечить равномерное распределение запросов по значениям ключа секции. Когда пропускная способность подготавливается для контейнера в Azure Cosmos DB, она распределяется равномерно по всем физическим секциям в контейнере.
Например, если у вас есть контейнер с 30 000 ЕЗ/с, рабочая нагрузка будет распределена между тремя физическими секциями для тех же шести клиентов выше. Таким образом, каждая физическая секция получает 10 000 ЕЗ/с. Если клиент D потребляет все 10 000 ЕЗ/с, его частота запросов будет ограничена, так как он не может пользоваться пропускной способностью, выделенной для других секций. Это приводит к снижению производительности клиентов C и D и неиспользованной емкости вычислений в других физических секциях и оставшихся клиентах. В конечном счете, этот ключ секции приводит к созданию структуры базы данных, в которой рабочая нагрузка приложения не может масштабироваться.
Если данные и запросы распределяются равномерно, это гарантирует, что по мере роста базы данных будет обеспечено полное использование объема хранилища и пропускной способности. Результатом будет максимально возможная производительность и повышенная эффективность. В общем, структура базы данных будет масштабироваться.
Соображения относительно чтения в сравнении с записью
При выборе ключа секции необходимо учитывать, какая операция над данными выполняется особенно интенсивно — чтение или запись. Для запросов с большой нагрузкой операций записи следует использовать ключ секции с большой кратностью.
Для рабочих нагрузок с большим объемом чтения следует убедиться, что запросы обрабатываются одним или ограниченным количеством секций, включая WHERE предложение с фильтром равенства для ключа секции или оператор IN в подмножестве значений ключа секции в запросах.
В сценариях, где рабочая нагрузка приложения активно использует операции и чтения, и записи, тоже есть решение. Мы займемся им в следующем модуле.
На следующем рисунке показан контейнер, секционированный по имени пользователя. Этот запрос работает только с единственным логическим разделом, поэтому его производительность всегда будет оптимальной.
Запрос, который фильтрует по другому свойству, например favoriteColor, вызовет "разброс" по всем секциям в контейнере. Это также называется межсекционным запросом. Такой запрос будет работать нормально, если контейнер невелик и занимает только одну секцию. Однако по мере роста контейнера и увеличения числа физических секций этот запрос будет выполняться медленнее и станет дороже, поскольку ему потребуется проверить каждую секцию, чтобы получить результаты, независимо от того, содержатся ли в физической секции связанные с запросом данные.
Выбор ключа раздела для клиентов
Теперь, когда вы понимаете процесс секционирования в Azure Cosmos DB, можно выбрать ключ секции для наших данных клиента. Как мы обсуждали ранее, для клиентов выполняется три операции: создание клиента, обновление клиента и получение клиента. В этом случае мы получим клиента по его идентификатору. Так как эта операция будет вызываться наиболее часто, имеет смысл сделать идентификатор клиента ключом секции для этого контейнера.
Вы можете беспокоиться, что если сделать этот идентификатор ключом секции, у нас будет столько логических секций, сколько есть клиентов и каждая логическая секция будет содержать только один документ. Миллионы клиентов приведут к миллионам логических секций.
Но это вполне нормально! Логические секции — это виртуальное понятие. Нет верхнего предела на число имеющихся у вас логических секций. Azure Cosmos DB будет совместно размещать несколько логических секций в одной физической секции. По мере увеличения числа или размера логических секций Cosmos DB при необходимости перемещает их в различные физические секции.