До недавнего времени все СУБД, работающие со структурированными данными (и не только они), можно было разделить на 2 категории: те, которые хранят записи в построчном формате, и те, которые хранят записи в столбчатом формате.
Это фундаментальное отличие, влияющее на то, как выглядят строки таблицы на уровне внутренних механизмов хранения СУБД.
Долгое время СУБД Teradata относилась к первой группе, но с выходом 14 версии появилась возможность определять, как хранить данные из конкретной таблицы — в виде столбцов или строк.
Так родилось гибридное хранилище.
В этой статье мы хотим поговорить о том, зачем это нужно, как это реализуется и какие преимущества дает.
Что такое столбец Teradata?
Прежде чем говорить о столбчатом формате хранения, скажем несколько слов о том, как мы обычно храним данные по строкам.
Давайте возьмем реляционную таблицу, в которой есть столбцы и строки: 
Как нам записать данные этой таблицы на диск, если они в строковом формате? Сначала пишем первую строку, затем вторую, третью и так далее: 
Как минимизировать нагрузку на дисковую систему при чтении этой таблицы? Для доступа к нему можно использовать разные методы:
- Доступ по индексу — если вам нужно прочитать всего несколько строк.
- Доступ к отдельным ее разделам (разделам) – если таблица очень большая (например, показаны транзакции за несколько лет, а вам нужно прочитать данные только за последние несколько недель).
Это разделение по строкам .
- Полное чтение таблицы — если вам нужно прочитать большой процент ее строк.
А что насчет динамиков? Что делать, если SQL-запрос использует не все столбцы таблицы, а только некоторые из них? При чтении строк мы читаем каждую строку полностью с диска.
Если в таблице 100 столбцов, а конкретному SQL-запросу нужно только 5 из них, то мы вынуждены читать с диска 95 столбцов, которые SQL-запрос не использует. Вот тут-то и приходит на ум идея хранить данные не в строках, а в столбцах.
В случае столбцового формата хранения — columnsar — подход следующий: сначала записываем на диск первый столбец, затем второй, третий и так далее: 
Такое разделение таблицы на столбцы создает перегородки по столбцам .
Если запросу нужны только отдельные столбцы, то мы читаем с диска только необходимые разделы по столбцам, значительно уменьшая количество операций ввода-вывода при чтении данных, которые нужны SQL-запросу.
Интересной особенностью этого подхода является то, что в одной таблице можно одновременно использовать разделы строк и разделы столбцов, другими словами, разделы внутри разделов.
Сначала заходим в нужные разделы по столбцам, затем внутри них читаем только нужные разделы по строкам.
Подводя итог вышесказанному, Teradata Columnar — это метод хранения данных в СУБД Teradata, который позволяет таблицам одновременно использовать два метода секционирования:
- Горизонтальные перегородки – построчно
- Вертикальные перегородки – по колоннам
Преимущества столбца Teradata
Преимущества заключаются в следующем:- Улучшена производительность запросов – за счет чтения только отдельных разделов по столбцам, что исключает необходимость чтения всех данных в строках таблицы.
Именно с этого мы начали нашу статью.
- Ээффективное автоматическое сжатие данных с использованием автоматического механизма сжатия.
Но это дополнительная приятная возможность, которая открывается при хранении данных в столбцах: в этом случае сжимать данные гораздо удобнее.
Некоторые даже ставят это преимущество на первое место, и не без оснований.
В первом случае мы читаем меньше данных, поэтому выполняем меньше операций ввода-вывода.
Во втором случае таблица занимает меньше места на диске и, как следствие, для ее чтения требуется меньше операций ввода-вывода.
Уменьшение нагрузки на диск сокращает время ответа приложений, поскольку запросы выполняются быстрее.
Это также увеличивает производительность системы Teradata в целом — отдельные запросы потребляют меньший процент мощности ввода-вывода системы, поэтому система может выполнить большее количество таких запросов.
Чтение данных из таблицы, хранящейся по столбцам
Хранение данных в столбцах существенно меняет механику чтения данных из такой таблицы.Фактически нам необходимо «собрать» данные из отдельных разделов столбцов, чтобы получить строки, которые должен вернуть SQL-запрос.
Это выглядит так.
Если запрос содержит условие WHERE для определенного столбца, то мы сначала сканируем этот столбец.
Фильтруем данные, и по тем строкам, которые удовлетворяют условию WHERE, переходим к соседним разбиениям по столбцам и читаем значения остальных столбцов для этих строк.
Пример: Какие клиенты живут в Сочи? В строковом формате (для сравнения) значения всех столбцов считываются при фильтрации по столбцу «Город» (условие ГДЕ Город=’Сочи’).
В формате столбца считываются только данные из столбцов City и Cust. Число — сначала отфильтруйте по столбцу «Город», затем найдите соответствующие значения Cust. Число.
Если в условии ГДЕ несколько столбцов, то сначала выбирается наиболее избирательный из них, фильтр по которому приведет к наибольшему обрезку строк, затем следующий столбец ГДЕ и т. д. А затем все остальные столбцы, участвующие в условии запрос.
Что касается механики перехода между разделами столбцов для «соборки» одной строки из отдельных столбцов, то такой переход осуществляется «позиционно».
Читая конкретную строку, мы знаем, что в каждом разделе столбца значение нужной нам строки находится на N-й позиции относительно начала таблицы.
Для поиска строки используется специальная структура адреса строки rowid, которая содержит номер раздела и номер строки.
Это позволяет вам переключаться между разделами столбца, заменяя номер раздела в идентификаторе строки на тот же номер строки.
Таким образом, мы собираем значения столбцов для одной строки вместе.
Гибридное хранение данных в одной таблице
Что делать, если в таблице много столбцов? Тогда будет больше накладных расходов на сбор строк из отдельных столбцов.Этого эффекта можно избежать, создав отдельные разделы не для каждого столбца, а для групп столбцов.
Если мы знаем, что какие-то столбцы часто используются вместе и редко используются по отдельности, то помещаем эти столбцы в один раздел.
Тогда внутри такого раздела данные этих столбцов можно хранить построчно, как если бы это была подтаблица.
Такой способ хранения называется гибридным: часть данных таблицы хранится в столбцах, а часть данных в той же таблице — в строках.
Пример (таблица другая, чем раньше): 
Сразу оговоримся, что термин «гибридное хранилище данных» можно использовать не только для описанного выше способа хранения данных, но и для хранения блоков данных на дисках разной скорости, о чем мы говорили на Хабрахабре.
Ээкономия дискового пространства
Об исключении разделов мы говорили чуть подробнее, чем о сжатии данных.Давайте ему тоже уделим должное внимание.
Разделение столбцов означает, что значения отдельного столбца соседствуют друг с другом.
Это очень удобно для сжатия данных.
Например, если в столбце мало разных значений, то можно создать «словарь» часто используемых значений столбца и использовать его для сжатия данных.
Причем для одного столбца таких словарей может быть несколько — отдельно для разных «контейнеров», на которые разбивается столбец при хранении на диске (по аналогии с блоками данных при хранении по строкам).
Что удобно, Teradata выбирает словари автоматически на основе данных, которые загружаются в таблицу, и если данные меняются со временем, то и словари для сжатия данных тоже меняются.
Помимо словарей, существуют и другие методы сжатия данных, такие как кодирование длины серии, обрезка, сжатие нулевых значений, дельта-хранилище, UNICODE в UTF8. Мы не будем вдаваться в подробности каждого из них – скажем лишь, что их можно использовать как по отдельности, так и в сочетании друг с другом для одних и тех же данных.
Teradata может динамически изменять механизм сжатия столбца, если это дает лучшие результаты.
Целью сжатия является уменьшение объема данных (в гигабайтах), занимаемых таблицей на диске.
Это позволяет хранить больше данных (в пересчете на количество строк таблицы) на том же оборудовании, а также больше данных на быстрых SSD-накопителях, если таковые имеются.
Когда использовать Columnar?
Teradata Columnar — отличная функция, позволяющая повысить производительность запросов и сжимать данные.Однако его не следует рассматривать как идеальное решение.
Выгода будет получена только для соответствующих данных и SQL-запросов с определенными характеристиками.
В других случаях эффект может быть даже отрицательным — например, когда все запросы используют все столбцы таблицы и данные сжимаются не очень хорошо.
Хорошими кандидатами на столбчатое хранилище являются таблицы, имеющие много столбцов, но каждый SQL-запрос использует относительно небольшое их количество.
Однако разные запросы могут использовать разные столбцы, если каждый отдельный запрос использует лишь небольшое количество столбцов.
В этих случаях происходит значительное сокращение количества операций ввода-вывода и повышение производительности ввода-вывода.
Разбиение данных строк на отдельные столбцы при вставке данных (вставка) и последующий «сбор» значений столбцов обратно в строки при извлечении данных (выбор) — эти операции потребляют больше ресурсов ЦП для таблиц столбцов, чем для обычных.
Поэтому следует учитывать, что если в системе наблюдается существенная нехватка ресурсов ЦП (так называемые системы с привязкой к ЦП), то Teradata Columnar также следует использовать с осторожностью, так как это может снизить общую производительность системы из-за нехватка ресурсов процессора.
Одним из требований к столбчатым таблицам является то, что данные загружаются в таблицу большими фрагментами INSERT-SELECT. Причина в следующем: если вы вставляете данные «построчно», то для столбчатых таблиц это очень неудобно, т.к.
вместо одной записи строки (одна операция ввода-вывода), как это было бы в случае с обычной таблицей, здесь вы нужно записывать значения столбцов в разные столбцы отдельно — резко увеличивая количество операций ввода-вывода.
Однако это типично для вставки ровно одной строки.
Если вставляется сразу много строк, то запись большого набора строк по трудоемкости сравнима с разбиением того же объема данных на столбцы и записью этих столбцов в нужные разбиения по столбцам.
По этой же причине в столбчатых таблицах операции UPDATE и DELETE являются трудоемкими, поскольку для выполнения этих операций нужно заходить в разные разделы столбцов.
Однако трудоемко не значит невозможно.
Если объем таких изменений сравнительно невелик, то Teradata Columnar вполне подойдет для таких задач.
Еще одна особенность столбчатых таблиц — отсутствие первичного индекса — столбца, обеспечивающего распределение строк по AMP в системе Teradata. Доступ к первичному индексу — это самый быстрый способ получения строк в Teradata. Для столбчатых таблиц такого индекса нет; вместо этого используется механизм No-Primary Index (No-PI) — когда данные равномерно распределяются самой Teradata, но без возможности доступа к этим данным с помощью первичного индекса.
Это означает, что столбчатые таблицы не следует использовать для таблиц, специальное использование которых требует первичного индекса.
Эти правила не однозначны.
Каждую ситуацию следует анализировать отдельно.
Например, вы можете создать дополнительные индексы, чтобы смягчить последствия отсутствия основного индекса.
Или другой пример: вы можете создать таблицу в формате строки, а поверх нее — индекс соединения в формате столбца (индекс соединения — это материализованное представление в Teradata, его также можно хранить в формате столбца).
Тогда запросы, использующие много столбцов, будут обращаться к самой таблице, а запросы, использующие несколько столбцов, будут использовать материализованное представление.
Что удобно, так это то, что вовсе не обязательно объявлять все таблицы столбчатыми.
Вы можете создать только некоторые таблицы в формате столбцов, а остальные таблицы — в формате строк.
Подводя итог вышесказанному, Teradata Columnar используется для таблиц, которые имеют следующие свойства:
- SQL-запросы выполняются для отдельных наборов столбцов таблицы.
ИЛИ SQL-запросы выполняются в отдельном подмножестве строк таблицы.
> Лучший результат — когда у вас есть оба
- Данные можно загружать с помощью больших INSERT-SELECT.
- Нет или мало операций обновления/удаления
Вы хотите, чтобы они занимали меньше места на диске и быстрее выполняли к ним запросы? Тогда на функционал Teradata Columnar стоит обратить внимание.
Чтобы помочь разработчикам физического моделирования определить, какие таблицы следует или не следует создавать в формате столбцов, доступен специальный инструмент — Columnar Analysis Tool. Этот инструмент анализирует использование конкретной таблицы SQL-запросами и дает рекомендации по применимости формата хранения на основе столбцов.
Также, конечно, много полезной информации в документации к Терадата 14 .
Теги: #teradata #teradata #столбцовые базы данных #гибридное хранилище #columnar #sql
-
Людей С Плохим Блогом Не Берут На Работу
19 Oct, 24
