Redshift DISTKEY / SORTKEY - PullRequest
       32

Redshift DISTKEY / SORTKEY

0 голосов
/ 19 октября 2018

У меня очень технический вопрос о том, как Redshift работает с DISTKEY и SORTKEY внутри, чтобы выполнить уровень хранения и требования выполнения запроса.Я прочитал этот удивительный пост , который очень хорошо объясняет, что означает каждый из них относительно дизайна таблицы.

Мой вопрос, давайте предположим, что у меня есть таблица A с тремяколонки:

CREATE TABLE (
orderdate timestamp distkey,
product_id varchar(50),
product_name varchar(250)
) SORTKEY (product_id)

Теперь мы знаем, что Redshift - это колоночная база данных, оптимизированная для хранилищ данных.В моем примере ясно, что, вероятно, способ, которым данные будут распределены по срезами для вычислительных узлов, основан на дате заказа DISTKEY.Но что происходит с колонками product_id и product_name?Распределяются ли они вместе с orderdate в одном и том же срезе, а затем, когда я выполняю запрос, Redshift использует карты зон, основанные на моем SORTKEY, чтобы указать зону столбца, в котором есть данные, и извлечь их?

Если Redshift - это колоночный подход, то не должен ли каждый столбец храниться по-разному?или это на самом деле означает то, что: на основе правильно выбранного столбца среди всех целые столбцы будут храниться в одном и том же срезе вместе с DISTKEY, а затем, чтобы гарантировать производительность, на которую пользователь может даже сфокусировать запросконкретная зона для получения необходимых данных.Таким образом, я мог бы в целом что-то вроде:

DISTKEY уровень хранения и SORTKEY выполнение запроса ведут себя

Теперь, если я использую DISTKEY, мои данные сохраняютсяна основе этого точечного порядка столбцов, так что если позже я использую SORTKEY, то другой для моего DISTKEY не может быть изменен или изменен так, как это работает?

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

Обновление

На основании сообщения @JoeHarris, отвечающего на этот вопрос, я попытался представить, как данные могут выглядеть сохраненными.

первый уровень распределения - мой DISTKEY (даты не очень хорошие, но я просто следую тому же примеру), а затем внутренние сортировки красного смещения по моим SORTKEY, что-то вроде:

enter image description here

спасибо за отзыв

1 Ответ

0 голосов
/ 19 октября 2018

DISTKEY распределяет строк среди срезов.

В вашем примере все строки с данным orderdate будут расположены в одном срезе.Это означает, что все столбцы для этих строк находятся в этом срезе.

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

Кстати, даты и временные метки не являются подходящими кандидатами для DISTKEY, потому что они очень редко используются в JOIN.Уникальные идентификаторы, такие как product_id, сделают лучше DISTKEY.Общее правило заключается в использовании столбца, который появляется в большинстве / самых больших JOIN.

SORTKEY определяет порядок расположения строк в таблице.Для строк, хранящихся в каждом срезе, они хранятся в порядке SORTKEY.Данные для каждого столбца хранятся в отдельных блоках (и, скорее всего, в каждом столбце используется много блоков), но внутри блоков столбцов строки располагаются в одном и том же порядке.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...