Определение ключевых снежинок кластеризации - PullRequest
Новая
       68

Определение ключевых снежинок кластеризации

0 голосов
/ 09 мая 2020

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

Основываясь на o / p, относящемся к моему пониманию. Ниже приведены точки, которые заставляют меня чувствовать, что кластеризация таблицы на основе столбца в теме поможет в увеличении производительности. отношение total_partition_count 20955 к average_depth: 16142.2524

1. Исправьте меня, если я неправильно понимаю. (на основе приведенных ниже фактов, является ли эта таблица хорошим кандидатом для кластеризации или нет)?

Пожалуйста, также помогите с другими пунктами ниже

2. Если я выберу кластеризацию таблицы, потребуется ли какое-либо время простоя (или) добавит ли кластеризация моего счета?

3. Влияет ли эта кластеризация на будущие операции DML?

4. Я вижу, что запрос выбора возвращает 23 строки после сканирования 37 ГБ данных, что было бы лучшим решением для повышения производительности запроса, кроме выбора кластеризации в качестве опции.

Дайте мне знать, если потребуется 

select SYSTEM$CLUSTERING_INFORMATION('tablename','(columnname)');
{
  "cluster_by_keys" : "LINEAR(column used in join condition)",
  "total_partition_count" : 20955,
  "total_constant_partition_count" : 2702,
  "average_overlaps" : 17151.4681,
  "average_depth" : 16142.2524,
  "partition_depth_histogram" : {
    "00000" : 0,
    "00001" : 1933,
    "00002" : 0,
    "00003" : 0,
    "00004" : 0,
    "00005" : 0,
    "00006" : 0,
    "00007" : 0,
    "00008" : 0,
    "00009" : 0,
    "00010" : 0,
    "00011" : 0,
    "00012" : 0,
    "00013" : 0,
    "00014" : 0,
    "00015" : 0,
    "00016" : 0,
    "08192" : 2,
    "16384" : 3,
    "32768" : 19017
  }
}

Ответы [ 2 ]

0 голосов
/ 09 мая 2020

Анализ данных SYSTEM $ CLUSTERING_INFORMATION.

"average_overlaps": 17151.4681> Среднее количество перекрывающихся микро-разделов для каждого микро-раздела в таблице. Большое число указывает на то, что таблица плохо сгруппирована.

"average_depth": 16142.2524> Средняя глубина перекрытия каждого микро-раздела в таблице. Большое число указывает на то, что таблица плохо кластеризована.

Сегменты с 00000 по 32768 описывают, на сколько микро-разделов (по концепции аналогично файлам) разделены ваши ключи кластера.

«00000»: 0> Ноль (0) константных микроразделов из 20955 микроразделов.

«32768»: 19017> 32768 означает, что 32768 микроразделов содержат ключ кластера. 19017 микро-разделов содержат ключи кластера, которые также находятся в 19017 других микро-разделах, что плохо, потому что нам нужно будет полностью просканировать все эти микро-разделы, чтобы найти один из этих ключей кластера.

https://docs.snowflake.com/en/sql-reference/functions/system_clustering_information.html

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

https://docs.snowflake.com/en/user-guide/tables-clustering-keys.html#strategies -for-selection-clustering-keys

2. Автоматическая кластеризация c работает в фоновом режиме и не требует простоя. Что касается биллинга, то будет взиматься дополнительная плата.

3. Кластеризация не влияет на будущую работу DML как таковую, но если в этой таблице существует постоянная операция DML, то, как только количество новых микро-разделов достигнет определенного порога. Автоматически c Кластеризация начнет работу, чтобы таблица была хорошо кластеризована.

Как упоминал Симеон, вы можете выбрать переписывание таблицы с помощью ORDER BY и выполнить кластеризацию самостоятельно.
0 голосов
/ 09 мая 2020
  1. ТАБЛИЦА является хорошим кандидатом для кластеризации, если операция, которая вам важна «больше всего», использует только небольшое количество строк, чем общее количество прочитанных разделов, многие из которых отбрасываются в результате фильтрации, по которой вы выполняете кластеризацию. Также вы тратите $ на чтение данных, которые вам не нужны.

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

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

кластеризация не влияет на будущее DML, если вы имеете в виду, что будущая вставка будет в N раз медленнее потому что у вас включена кластеризация. Но, учитывая, что вы изменяете данные, есть два способа, которыми DML multi повлияет на вашу кластеризацию: если вы вставляете данные случайным образом (по отношению к вашей кластеризации), эти данные необходимо будет отсортировать. Также вы делаете высокочастотные вставки, это может помешать фоновым операциям кластеризации. Также из-за того, что вы вставляете новые данные в новые разделы, больший набор требует повторной кластеризации.

Вы можете переписать таблицу с помощью ORDER BY и выполнить кластеризацию самостоятельно.

...