Почему Redshift не нуждается в материализованных представлениях или индексах?
В Redshift FAQ под
Вопрос: как производительность Amazon Redshift сравнивается с большинством традиционных баз данных для хранения данных и аналитики?
Он говорит следующее:
Расширенное сжатие: столбчатые хранилища данных могут быть сжаты гораздо сильнее, чем строковые, поскольку аналогичные данные хранятся последовательно на диске. Amazon Redshift использует несколько методов сжатия и часто может добиться значительного сжатия относительно традиционных реляционных хранилищ данных. Кроме того, Amazon Redshift не требует индексов или материализованных представлений и поэтому занимает меньше места, чем традиционные реляционные системы баз данных. При загрузке данных в пустую таблицу Amazon Redshift автоматически производит выборку данных и выбирает наиболее подходящую схему сжатия.
Почему это так?
3 ответа:
Это немного неискренне, чтобы быть честным (на мой взгляд). Хотя у RedShift нет ни того, ни другого, я не уверен, что это то же самое, что сказать, что оно не выиграет от них.
Материализованные Взгляды
Я понятия не имею, почему они делают это заявление. Возможно, потому, что они считают двигатель настолько производительным, что выгоды от его использования минимальны. Я бы оспорил это, и продукт, над которым я работаю, поддерживает свои собственные материализованные взгляды и может показать значительные результаты. от этого повышается производительность. Может быть, вы считаете, что я вообще делаю что-то не так?Индексы
Красное смещение не имеет индексов.
У него есть
SORT ORDER, который исключительно похож на кластеризованный индекс. Это просто список полей, по которым упорядочиваются данные (например, составной кластеризованный индекс).Он даже недавно ввел
INTERLEAVED SORT KEYS. Это прямая попытка иметь несколько независимых порядков сортировки. Вместо того, чтобы заказывать поa THEN b THEN cонэффективно распоряжается каждым из ниходновременно .Это становится отчасти возможным из-за того, как RedShift реализует свое хранилище столбцов.
- Каждый столбец хранится отдельно от каждого другого столбца
- Каждый столбец хранится в блоках размером 1 мб
- Каждый блок размером 1 МБ имеет сводную статистикуПомимо того, что это шаблон хранения, он фактически становится набором псевдо-индексов.
- Если данные отсортированы поa then b then x
- Но ты же хочешь ...z = 1234
- RedShift сначала просматривает статистику блока (для столбца z)
- Эти статистики будут говорить минимальные и максимальные значения, сохраненные этим блоком
- Это позволяет Redshift пропустить многие из этих блоков в определенных условиях
- Этот интерн позволяет RedShift определять, какие блоки читать из других столбцов
Это слишком долго для комментария.
Простой ответ: потому что он может считывать необходимые данные очень, очень быстро и параллельно.
Одним из основных видов использования индексов являются запросы типа "иголка в стоге сена". Это запросы, в которых требуется только относительно небольшое число строк, и они соответствуют предложениюWHERE. Столбчатые хранилища данных обрабатывают их по-разному. Весь столбец считывается в память - но только столбец, а не остальные данные строки. Это своего рода ... аналогично тому, как иметь индекс для каждого столбца, за исключением того, что значения должны быть проверены на соответствие (вот где параллелизм пригодится).Другие виды использования индексов предназначены для сопоставления пар ключей для объединения или для агрегирования. Они могут быть обработаны альтернативными алгоритмами на основе хэша.
Что касается материализованных представлений, сила красного смещения не обновляет данные. Многие такие запросы достаточно быстры и без материализации. И, материализация берет на себя много накладных расходов для поддержание данных в среде с высоким уровнем транзакций. Если у вас нет высокой среды транзакций, то вы можете увеличить временные таблицы после пакетной загрузки.
Индексы в основном используются в системах OLTP для извлечения определенной или небольшой группы значений. Напротив, OLAP-системы извлекают большой набор значений и выполняют агрегацию по большому набору значений. Индексы не подходят для OLAP-систем. Вместо этого он использует вторичную структуру под названием карты зон с ключами сортировки.
Индексы работают на деревьях B. Раздел "жизнь без btree" в блоге ниже объясняет на примерах, как влияет индекс, основанный на btree Рабочие нагрузки OLAP.
Https://blog.chartio.com/blog/understanding-interleaved-sort-keys-in-amazon-redshift-part-1
Сочетание столбцового хранения, кодирования сжатия, распределения данных, сжатия, компиляции запросов, оптимизации и т. д. обеспечивает мощность для красного смещения, чтобы быть быстрее.
Реализация вышеперечисленных факторов уменьшает операции ввода-вывода на Redshift и в конечном итоге обеспечивает лучшую производительность. Чтобы реализовать эффективное решение, требуется очень многое. знаний по вышеприведенным разделам, а также по запросам, которые вы будете запускать на Amazon Redshift.
Например. Redshift поддерживает ключи сортировки, ключи сортировки смеси и ключи чередуются рода. Если структура таблицы lineitem(orderid, linenumber, supplier, quantity, price, discount, tax, returnflat, shipdate). Если вы выбрали orderid в качестве ключа сортировки, но ваши запросы основаны на shipdate, Redshift будет работать эффективно. Если у вас есть составной sortkey on (orderid, shipdate) и если ваш запрос только на дату отгрузки, Redshift не будет работать эффективно. Если у вас есть перемежающаяся программная клавиша on (orderid, shipdate) и если ваш запрос
Redshift не поддерживает материализованные представления, но он легко позволяет создавать (временные/постоянные) таблицы, выполняя запросы select к существующим таблицам. Он в конечном итоге дублирует данные, но в требуемом формате, который будет выполняться для запросов (аналогично материализованному представлению), ниже блог дает вам некоторую информацию о вышеизложенном подход.
Красное смещение хорошо сочетается с другими системами, такими как Hive, Impala, Spark, BQ и т. д. во время одной из наших недавних контрольных рамок