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

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

  • Статья

Политика секционирования определяет, следует ли и как секционировать экстенты (сегменты данных) для определенной таблицы или материализованного представления.

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

Основная цель политики секционирования — повысить производительность запросов в определенных поддерживаемых сценариях.

Примечание

По умолчанию, если политика секционирования данных не определена (имеет значение null), экстенты секционируются по времени создания (приема). В большинстве случаев нет необходимости задавать политику секционирования данных.

Поддерживаемые сценарии

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

  • Частые фильтры по средней или высокой кратности string или guid столбцу:
    • Например, мультитенантные решения или таблица метрик, в которой большинство или все запросы фильтруют по столбцу типа string или guid, например TenantId или MetricId.
    • Средняя кратность составляет не менее 10 000 различных значений.
    • Задайте для хэш-ключаstring секции значение или guid столбца и задайте дляPartitionAssigmentMode свойства значение uniform.
  • Частые агрегирования или объединения в столбце с высокой кратностьюstring:guid
    • Например, данные Интернета вещей с различных датчиков или академические записи многих разных учащихся.
    • Высокая кратность составляет не менее 1 000 000 различных значений, где распределение значений в столбце приблизительно равно.
    • В этом случае задайте для ключа хэш-секции значение столбца, который часто группируется или объединяется, и задайте PartitionAssigmentMode для свойства значение ByPartition.
  • Прием неупорядоченных данных:
    • Данные, попадаемые в таблицу, могут быть не упорядочены и секционированы на экстенты (сегменты) в соответствии с конкретным datetime столбцом, который представляет время создания данных и обычно используется для фильтрации данных. Это может быть связано с обратным заполнением разнородных исходных файлов, которые содержат значения datetime в течение большого промежутка времени.
    • В этом случае задайте в качестве столбца ключ секции datetime в универсальном диапазонеdatetime.
    • Если необходимо, чтобы политики хранения и кэширования соответствовали значениям даты и времени в столбце, вместо согласования со временем приема присвойте свойству OverrideCreationTime значение true.

Внимание!

  • Жестко заданные ограничения на количество таблиц с определенной политикой секционирования не установлены. Однако каждая дополнительная таблица добавляет дополнительные затраты на фоновый процесс секционирования данных, который выполняется на узлах кластера. Установка политики для большего объема таблиц приведет к использованию большего объема ресурсов кластера и повышению затрат из-за базовых транзакций хранилища. Дополнительные сведения см. в разделе о емкости.
  • Не рекомендуется задавать политику секционирования, если размер сжатых данных на секцию должен быть меньше 1 ГБ.
  • Процесс секционирования приводит к тому, что артефакты остаточного хранилища для всех экстентов, замененных в процессе секционирования и во время слияния. Ожидается, что большинство артефактов остаточного хранилища будут удалены в процессе автоматической очистки. Увеличение значения MaxPartitionCount свойства увеличивает количество артефактов остаточного хранилища и может снизить производительность очистки.
  • Перед применением политики секционирования к материализованному представлению ознакомьтесь с рекомендациями по политике секционирования материализованных представлений.

Ключи секции

Поддерживаются следующие типы ключей секций.

Kind Тип столбца Свойства раздела Значение секции
Хэш string или guid Function, MaxPartitionCount, Seed, PartitionAssignmentMode Function(ColumnName, MaxPartitionCount, Seed)
Универсальный диапазон datetime RangeSize, Reference, OverrideCreationTime bin_at(ColumnName, RangeSize, Reference)

Хэш-ключ секции

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

Примечание

Операция секционирования данных увеличивает значительную нагрузку на обработку. Мы рекомендуем применять ключ хэш-секции к таблице только при следующих условиях:

  • Если в большинстве запросов используются фильтры равенства (==, in()).
  • Большинство запросов агрегируют или объединяют для определенного столбца типа string или guid большого размера (кратность 10 М или выше), например device_ID, или user_ID.
  • Шаблон использования секционированных таблиц находится в высокой нагрузке на запросы с параллелизмом, например в приложениях мониторинга или панелей мониторинга.
  • Функция hash-modulo используется для секционирования данных.
  • Данные в однородных (секционированных) экстентах упорядочены по ключу хэш-секции.
  • Ожидается, что запросы, использующие стратегию перетасовки и в которых shuffle key используется в join, summarize или make-series является ключом хэш-секции таблицы, будут работать лучше, так как объем данных, необходимых для перемещения между узлами кластера, сокращается.

Свойства раздела

Свойство Описание Поддерживаемые значения Рекомендуемое значение
Function Имя используемой функции с хэш-модулем. XxHash64
MaxPartitionCount Максимальное число создаваемых секций (аргумент modulo функции hash-modulo) за период времени. В диапазоне (1,2048]. Более высокие значения приводят к большей нагрузке на процесс секционирования данных на узлах кластера и большему числу экстентов за каждый период времени. Мы рекомендуем использовать значение 128. Более высокие значения значительно увеличат затраты на секционирование данных после приема и размер метаданных, поэтому не рекомендуется.
Seed Используется для случайного определения хэш-значения. Положительное целое число. 1, которое также является значением по умолчанию.
PartitionAssignmentMode Режим, используемый для назначения секций узлам в кластере. ByPartition: все однородные (секционированные) экстенты, принадлежащие одной секции, назначаются одному узлу.
Uniform: значения секции экстентов игнорируются. Экстенты равномерно назначаются узлам кластера.		 Если запросы не объединяются или не объединяются по ключу хэш-секции, используйте Uniform. В противном случае используйте коллекцию ByPartition.

Пример ключа хэш-секции

Ключ хэш-секции над типизированным столбцом stringс именем tenant_id. В нем используется XxHash64 хэш-функция с рекомендуемыми значениями 128MaxPartitionCount и значением по умолчанию Seed1.

{
  "ColumnName": "tenant_id",
  "Kind": "Hash",
  "Properties": {
    "Function": "XxHash64",
    "MaxPartitionCount": 128,
    "Seed": 1,
    "PartitionAssignmentMode": "Uniform"
  }
}

Ключ секции даты и времени в универсальном диапазоне

Примечание

Примените ключ datetimeсекции datetime к типизированному столбцу таблицы только в том случае, если данные, полученные в таблицу, вряд ли будут упорядочены в соответствии с этим столбцом.

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

Используемая функция секционирования является bin_at() и не настраивается.

Свойства раздела

Свойство Описание Рекомендуемое значение
RangeSize Скалярная timespan константа, указывающая размер каждой секции datetime. Начните со значения 1.00:00:00 (один день). Не устанавливайте более короткое значение, так как это может привести к тому, что таблица будет иметь большое количество небольших экстентов, которые невозможно объединить.
Reference Скалярная datetime константа, указывающая фиксированную точку во времени, в соответствии с которой выравниваются секции даты и времени. Начните с метода 1970-01-01 00:00:00. Если есть записи, в которых ключ секции datetime имеет null значения, их значение секции устанавливается в значение Reference.
OverrideCreationTime Значение типа , bool указывающее, следует ли переопределять минимальное и максимальное время создания результирующих экстентов диапазоном значений в ключе секции. По умолчанию — false. Задайте значение , true если данные не подается в порядке времени прибытия. Например, один исходный файл может содержать удаленные значения даты и времени, и (или) может потребоваться принудительное хранение или кэширование на основе значений datetime, а не времени приема.

Если OverrideCreationTime для задано значение true, экстенты могут быть пропущены в процессе слияния. Экстенты пропускаются, если время их создания превышает Lookback период действия политики слияния экстентов таблицы. Чтобы убедиться, что экстенты доступны для обнаружения, присвойте свойству Lookback значение HotCache.

Пример секции даты и времени в универсальном диапазоне

В фрагменте кода показан универсальный ключ секции диапазона даты и времени для типизированного datetime столбца с именем timestamp. Он использует datetime(2021-01-01) в качестве точки отсчета с размером для каждой секции 7d и не переопределяет время создания экстентов.

{
  "ColumnName": "timestamp",
  "Kind": "UniformRange",
  "Properties": {
    "Reference": "2021-01-01T00:00:00",
    "RangeSize": "7.00:00:00",
    "OverrideCreationTime": false
  }
}

Объект политики

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

Политика секционирования данных имеет следующие свойства main:

  • PartitionKeys:

  • EffectiveDateTime:

    • Дата и время в формате UTC, с которого действует политика.
    • Это необязательное свойство. Если она не указана, политика вступит в силу для данных, которые будут приниматься после применения политики.

Внимание!

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

Пример секционирования данных

Объект политики секционирования данных с двумя ключами секционирования.

  1. Ключ хэш-секции над типизированным столбцом stringс именем tenant_id.
    • В нем используется XxHash64 хэш-функция с рекомендуемыми значениями 128MaxPartitionCount и значением по умолчанию Seed1.
  2. Универсальный ключ секции диапазона даты и времени для столбца datetime типа с именем timestamp.
    • В качестве точки отсчета используется datetime(2021-01-01) размер для каждой секции 7d .
{
  "PartitionKeys": [
    {
      "ColumnName": "tenant_id",
      "Kind": "Hash",
      "Properties": {
        "Function": "XxHash64",
        "MaxPartitionCount": 128,
        "Seed": 1,
        "PartitionAssignmentMode": "Uniform"
      }
    },
    {
      "ColumnName": "timestamp",
      "Kind": "UniformRange",
      "Properties": {
        "Reference": "2021-01-01T00:00:00",
        "RangeSize": "7.00:00:00",
        "OverrideCreationTime": false
      }
    }
  ]
}

Дополнительные свойства

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

Свойство Описание Рекомендуемое значение Значение по умолчанию
MinRowCountPerOperation Минимальное целевое значение для суммы количества строк исходных экстентов одной операции секционирования данных. 0
MaxRowCountPerOperation Максимальный целевой объект для суммы количества строк исходных экстентов одной операции секционирования данных. Задайте значение ниже 5M, если вы видите, что операции секционирования потребляют большой объем памяти или ЦП на каждую операцию. 0с целевым значением по умолчанию 5 000 000 записей.
MaxOriginalSizePerOperation Максимальное целевое значение для суммы исходного размера (в байтах) исходных экстентов одной операции секционирования данных. Если операции секционирования потребляют большой объем памяти или ЦП для каждой операции, задайте значение ниже 5 ГБ. 0с целевым значением по умолчанию 5 368 709 120 байт (5 ГБ).

Процесс секционирования данных

  • Секционирование данных выполняется в кластере в фоновом режиме после приема.
    • Ожидается, что таблица, которая постоянно попадает в, всегда будет содержать "хвост" данных, которые еще не секционированы (неоднородные экстенты).
  • Секционирование данных выполняется только в горячих экстентах, независимо от значения EffectiveDateTime свойства в политике.
    • Если требуется секционирование холодных экстентов, необходимо временно настроить политику кэширования.

Вы можете отслеживать состояние секционирования таблиц с определенными политиками в базе данных с помощью команды .show database extents partitioning statistics .

Емкость секционирования

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

Ограничения

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

Выбросы в секционированных столбцах

  • Следующие ситуации могут привести к несбалансированному распределению данных по узлам кластера и снижению производительности запросов.
    • Если ключ хэш-секции содержит значения, которые гораздо более распространены, чем другие, например пустая строка или универсальное значение (например null , или N/A).
    • Значения представляют сущность (например tenant_id, ), которая является более распространенной в наборе данных.
  • Если ключ секции даты и времени в равномерном диапазоне имеет достаточно большой процент значений, которые находятся "далеко" от большинства значений в столбце, затраты на процесс секционирования данных увеличиваются и могут привести к множеству небольших областей, которые кластеру потребуется отслеживать. Примером такой ситуации являются значения datetime из далекого прошлого или будущего.

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

См. также