HAWQ распределяет случайным образом, а дисковое пространство для каждого сегмента почти заполнено. добавить новый datanode

Question

Я читаю спецификацию HAWQ. Возникает вопрос: я создаю таблицу (например, «table_random») с распределением случайным образом в 3 кластерах узлов данных, а дисковое пространство для каждого сегмента почти недостаточно. Затем я добавляю новую дату-узел в кластер, а затем, когда я вставить данные в таблицу «table_random»,

- Does HAWQ will distribute data to the old data-nodes ? What will happen actually? 
- Does HQWQ will redistribute the data of table 'table_random' overall the cluster? 

благодаря

Answer 1

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

create table foo (id int, bar text) distributed by (id); 

В HAWQ есть концепция ковшей для распределенных таблиц хэша. В принципе, есть файл в hdfs, который соответствует каждому ведру. С секционированной таблицей есть файл для каждого раздела и для каждого ведра, но давайте просто сосредоточимся на моей таблице foo выше.

Когда вы запускаете свою базу данных, устанавливается GUC default_hash_table_bucket_number. Он рассчитывается на основе количества узлов * 6. (Кластеры с 85 - 102 узлами представляют собой 5 * количество узлов и т. Д.) Таким образом, кластер из 10 узлов будет иметь значение по умолчанию_hash_table_bucket_number = 60. Поэтому в моей HD-таблице будет 60 файлов в HDFS.

• Когда вы выполняете запрос против foo, для этой таблицы будет 60 виртуальных сегментов (по одному для каждого файла).
• При развертывании кластера количество ведер для моей таблицы фиксировано. 60 ковшей по-прежнему будут работать, но они будут распределены по всем узлам.
• После расширения и использования распределения хешей вы должны настроить default_hash_table_bucket_number на основе количества узлов в кластере, а затем воссоздать хеш-распределенные таблицы, чтобы он имел правильное количество ковшей.

Вы также можете задать количество ковшей для за столом, как это:

create table foo (id int, bar text) with (bucketnum=10) distributed by (id); 

Теперь я принуждая базу данных, чтобы иметь 10 ведер для моего стола, а не использовать значение из default_hash_table_bucket_number.

Но беспорядочно распределенные таблицы рекомендуются по хешу. Зачем? Из-за эластичности.

create table foo_random (id int, bar text) distributed randomly; 

Теперь эта таблица создаст только один файл в hdfs. Количество vsegs определяется во время выполнения на основе оптимизатора запросов. Для небольшой таблицы оптимизатор может выполнять только один виртуальный сегмент, в то время как очень большая таблица может использовать 6 виртуальных сегментов для каждого хоста.

При развертывании кластера вам не нужно будет перераспределять данные. В случае необходимости база данных автоматически увеличит общее количество виртуальных сегментов.

hawq_rm_nvseg_perquery_perseg_limit - это GUC, который определяет, сколько возможных виртуальных сегментов будет создано для каждого запроса на сегмент. По умолчанию это значение равно 6, но вы можете увеличить или уменьшить его. hawq_rm_nvseg_perquery_limit - это еще один GUC, который здесь очень важен. По умолчанию он равен 512 и управляет общим количеством виртуальных сегментов, которые могут выполняться для широкого круга запросов.

Таким образом, в целом, в HAWQ со случайным распределением:

• Рекомендуемый метод хранения
• Добавление узлов не требует перераспределения данных
• Удаление узлов не требует перераспределения данных
• hawq_rm_nvseg_perquery_perseg_limit может быть увеличено с 6 до более высоких значений, чтобы увеличить параллизм.
• hawq_rm_nvseg_perquery_limit может потребоваться увеличить с 512 до более высокого значения. Он определяет общее количество виртуальных сегментов по всему кластеру для каждого запроса.