Почему Redshift не нужны материализованные представления или индексы?

Честно говоря, это немного лукавит (на мой взгляд). Хотя RedShift не имеет ни того, ни другого, я не уверен, что это то же самое, что сказать, что они не принесут пользы.

Материализованные просмотры

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

Я бы поспорил с этим, потому что продукт, над которым я работаю, поддерживает собственные материализованные представления и может показать значительный прирост производительности от этого. Может быть, AWS считает, что я вообще что-то делаю не так?

Индексы

RedShift не имеет индексов.

У него есть SORT ORDER, который исключительно похож на кластерный индекс. Это просто список полей, по которым упорядочены данные (например, составной кластерный индекс).

Он даже недавно представил INTERLEAVED SORT KEYS. Это прямая попытка иметь несколько независимых порядков сортировки. Вместо того, чтобы упорядочивать по a THEN b THEN c, он эффективно заказывает по каждому из них одновременно.

Это стало возможным благодаря тому, как RedShift реализует хранилище столбцов.
- Каждый столбец хранится отдельно от другого столбца
- Каждый столбец хранится в блоках по 1 МБ
- Каждый блок размером 1 МБ имеет сводную статистику

Это не только шаблон хранения, но и набор псевдоиндексов.
- Если данные отсортированы по a then b then x
- Но вы хотите z = 1234
- RedShift просматривает статистику блоков (для столбца z) first
- В этой статистике будут указаны минимальные и максимальные значения, хранящиеся в этом блоке
- Это позволяет Redshift пропускать многие из этих блоков при определенных условиях
- Этот стажер позволяет RedShift определять, какие блоки читать из другие столбцы

по состоянию на декабрь 2019 года Redshift имеет предварительную версию материализованных представлений: Объявление

из документации: Материализованное представление содержит предварительно вычисленный набор результатов, основанный на запросе SQL по одной или нескольким базовым таблицам. Вы можете использовать операторы SELECT для запроса материализованного представления точно так же, как вы можете запрашивать другие таблицы или представления в базе данных. Amazon Redshift возвращает предварительно вычисленные результаты из материализованного представления без необходимости доступа к базовым таблицам. С точки зрения пользователя результаты запроса возвращаются намного быстрее, чем при извлечении тех же данных из базовых таблиц.

Это слишком долго для комментария.

Ответ прост: потому что он может читать необходимые данные очень, очень быстро и параллельно.

Одно из основных применений индексов - это запросы «иголка в стоге сена». Это запросы, в которых требуется только относительно небольшое количество строк, и они соответствуют предложению WHERE. Столбчатые хранилища данных обрабатывают это по-разному. В память считывается весь столбец, но только столбец, а не остальные данные строки. Это похоже на наличие индекса для каждого столбца, за исключением того, что значения необходимо сканировать на предмет совпадения (здесь пригодится параллелизм).

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

Что касается материализованных представлений, сила RedShift не в обновлении данных. Многие такие запросы достаточно быстры и без материализации. Кроме того, материализация влечет за собой большие накладные расходы на поддержание данных в среде с большим количеством транзакций. Если у вас нет среды с большим количеством транзакций, вы можете увеличивать временные таблицы после пакетной загрузки.

Индексы в основном используются в системах OLTP для извлечения определенной или небольшой группы значений. Напротив, системы OLAP извлекают большой набор значений и выполняют агрегирование для большого набора значений. Индексы не подходят для систем OLAP. Вместо этого он использует вторичную структуру, называемую зонными картами с ключами сортировки.

Индексы работают с B-деревьями. В разделе «Жизнь без btree» в блоге ниже на примерах объясняется, как индекс, основанный на btree, влияет на рабочие нагрузки OLAP.

https://blog.chartio.com/blog/understanding-interleaved-sort-keys-in-amazon-redshift-part-1

Комбинация хранения по столбцам, кодирования сжатия, распределения данных, сжатия, компиляции запросов, оптимизации и т. Д. Обеспечивает Redshift возможность работать быстрее.

Реализация вышеуказанных факторов сокращает количество операций ввода-вывода в Redshift и, в конечном итоге, обеспечивает лучшую производительность. Чтобы реализовать эффективное решение, требуются обширные знания в перечисленных выше разделах, а также в запросах, которые вы будете выполнять в Amazon Redshift.

например, для Redshift поддерживает ключи сортировки, составные ключи сортировки и ключи сортировки с чередованием. Если структура вашей таблицы - строковый элемент (заказ, номер полотна, поставщик, количество, цена, скидка, налог, возврат квартиры, дата отгрузки). Если вы выберете orderid в качестве ключа сортировки, но если ваши запросы основаны на дате отгрузки, Redshift будет работать эффективно. Если у вас есть составной ключ сортировки (порядковый номер, дата отправки) и если ваш запрос только на дату отгрузки, Redshift не будет работать эффективно. Если у вас включена программная клавиша с чередованием (orderid, shipdate) и ваш запрос

Redshift не поддерживает материализованные представления, но легко позволяет создавать (временные / постоянные) таблицы, выполняя запросы выбора к существующим таблицам. В конечном итоге он дублирует данные, но в необходимом формате для выполнения для запросов (аналогично материализованному представлению). В приведенном ниже блоге вы найдете некоторую информацию о вышеупомянутом подходе.

https://www.periscopedata.com/blog/faster-redshift-queries-with-materialized-views-lifetime-daily-arpu.html.

Redshift хорошо справляется с другими системами, такими как Hive, Impala, Spark, BQ и т. Д., Во время одного из наших недавних тестовых фреймворков.

Недавно они добавили поддержку материализованных представлений в Redshift: https://aws.amazon.com/about-aws/whats-new/2019/11/amazon-redshift-introduces-support-for-materialized-views-preview/ < / а>

CREATE MATERIALIZED VIEW mv_name
[ BACKUP { YES | NO } ]
[ table_attributes ]   
AS query 

REFRESH MATERIALIZED VIEW mv_name