Teradata

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 16:28, 21 января 2019.
Teradata
Teradata.png
Разработчики: teradata.ru
Выпущена: 1984; 36 years ago (1984)
Состояние разработки: Активный
Написана на: SQL
Операционная система: MP-RAS UNIX, Microsoft Windows 2000/2003 Server,SUSE Linux
Тип ПО: реляционная СУБД
Веб-сайт Teradata-database

Teradata – это параллельная реляционная СУБД, которая работает на операционных системах MP-RAS UNIX, Microsoft Windows 2000/2003 Server и SUSE Linux. Разнообразие поддерживаемых ОС — одна из причин, почему Teradata имеет открытую архитектуру. Фактически Teradata является большим сервером баз данных, который взаимодействует со множеством клиентов посредством протокола TCP/IP или через соединение с каналом универсальной вычислительной машины (mainframe) IBM.[Источник 1] Разнообразие поддерживаемых ОС — одна из причин, почему Teradata имеет открытую архитектуру.

Высокую скорость доступа к данным Teradata обеспечивает за счет MPP (Massive Parallel Processing) – массивно-параллельной архитектуры. Ее особенность заключается в том, что память физически разделена. Teradata предлагает серверы Intel, соединённые в частную сеть BYNET для обмена сообщениями. Системы Teradata предлагаются с фирменными дисковыми массивами для хранения баз данных производства либо LSI, либо EMC.

Исторические сведения

СУБД Teradata была создана в 1976 году и многие концепции, заложенные в ее фундамент, актуальны и по сей день. Teradata реализовала дизайн, отличный от главенствующей на тот момент архитектуры мэйнфреймов. Это была идея объединения в сеть вычислительных модулей, работающих параллельно. Приятным дополнением к такой архитектуре стало значительное удешевление систем. Идея параллельной обработки дала Teradata возможность линейно масштабировать производительность, объемы обрабатываемых данных и количество пользователей.

Преимущества

Teradata обладает следующими преимуществами:

  • Поддержка больших объемов информации – более 400 Тб в одной области;
  • Поддержка модульного наращивания от маленьких баз данных (10Гб) до больших (100+ Тб);
  • Обеспечение параллельно-осведомленным оптимизатором, который исключает выполнение сложных настроек для получения запроса;
  • Автоматическое распределение данных исключает сложные схемы индексации и трудоемкие реорганизации;
  • База данных спроектирована и построена на параллельной архитектуре с самого начала;
  • Поддержка нерегламентированных запросов, использующих ANSI-стандарт SQL и включающих в себя информацию управления базами данных SQL (log-файлы), что позволяет представлять запросы других систем управления базами данных в Teradata;
  • Единая точка управления для администрирования базы данных (Teradata Manager).
  • Высокую скорость доступа к данным Teradata обеспечивает за счет MPP (Massive Parallel Processing) – массивно-параллельной архитектуры. Ее особенность заключается в том, что память физически разделена.
  • Teradata предлагает серверы Intel, соединённые в частную сеть BYNET для обмена сообщениями. Системы Teradata предлагаются с фирменными дисковыми массивами для хранения баз данных производства либо LSI, либо EMC.

Архитектура

Основная структура

Рисунок 1 - Логическаю архитектура Teradata

Teradata относится к классу систем, называемых MPP (англ. Massively parallel processing), и имеет архитектуру Shared nothing, в рамках которой отдельные узлы системы не имеют общих ресурсов. А сама СУБД является реляционной.

Основное назначение компонентов, представленных на рисунке 1: PE – Parsing Engine, отвечает за контроль сессии и обработку запросов пользователя; AMP – Access Module Processor, отвечает за извлечение данных с ассоциированного с ним диска; BYNET – Среда обмена сообщениями между компонентами системы.

На верхнем уровне процесс выполнения запроса в Teradata выглядит следующим образом:

  1. Пользователь, подключаясь к системе Teradata, устанавливает соединение с Parsing Engine (PE). После того как соединение установлено, он может выполнять запросы SQL.
  2. PE проверяет синтаксис полученного SQL-запроса, права пользователя на доступ к информации и создает план выполнения запроса для выполнения компонентом Access Module Processor (AMP).
  3. PE через BYNET направляет шаги плана AMP-ам на выполнение.
  4. AMP-ы извлекают необходимую информацию с ассоциированных с ними дисков и возвращают ее PE через BYNET. AMP-ы выполняют свою работу параллельно.
  5. PE возвращает результат пользователю.

PE и AMP объединяются термином VPROC, или виртуальный процессор.[Источник 2]

Таким образом основное понятие в архитектуре Teradata Database — это AMP, отдельная «нода», содержащая и самостоятельно обрабатывающая свои данные, малозависимая от других AMP-ов. При условии соответствующей архитектуры базы данных, позволяющей малозависимые логические хранения и обработки внутри частей базы данных, достигается массовый параллелизм обработки данных на AMP-ах. То есть каждый AMP занят обработкой и хранением лишь своей части базы данных. В этом Teradata Database похожа на Hadoop.

Для того чтобы запросы обрабатывались максимально эффективно, данные должны быть распределены между AMP-ами максимально равномерно. Данные распределяются на основании собственного hash-алгоритма обработки полей, входящих в Primary index таблицы. Причем алгоритм хэширования реализован так, что на основании значения хэша можно понять номер AMP-а, на котором находится строка. Помимо основной цели, это также очень ускоряет поиски по значению.

Однако массивно-параллельная архитектура с неверно спроектированной базой данных за счет перегрузки сетевых каналов между AMP-ами может давать даже худшие результаты, чем монолитный «однопотоковый» и мощный сервер баз данных, такой каким изначально создан сервер СУБД Oracle.

Для балансировки нагрузки между AMP-ами и других административных задач используются средства Teradata Manager, DBSConsole и Teradata Administrator. В частности эти средства позволяют задавать «фильтры» и приоритеты для выполняющихся на AMP-ах, либо сервере в целом, пользовательских процессов.[Источник 3]

Гибридное хранение данных

Долгое время СУБД Teradata относилась к группе БД, хранящей записи в построчном формате, но с выходом 14-й версии представилась возможность определять, как хранить данные конкретной таблицы – в виде колонок или строк. Таким образом, появилось гибридное хранение. Teradata Columnar – это метод хранения данных в СУБД Teradata, который позволяет таблицам одновременно использовать два метода партиционирования:

  • Горизонтальные партиции – по строкам;
  • Вертикальные партиции – по колонкам.

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

Преимущества Teradata Columnar:

  • Увеличение производительности запросов – за счет чтения только отдельных партиций по колонкам, исключая необходимость считывать все данные в строках таблицы.
  • Эффективное автоматическое сжатие данных с использованием механизма автоматической компрессии. Это дополнительная возможность, которая открывается при хранении данных по колонкам: в этом случае данные намного удобнее сжимать.

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

Снижение нагрузки на дисковую систему уменьшает время отклика в приложениях, поскольку запросы выполняются быстрее. А также увеличивается производительность работы системы Teradata в целом – отдельные запросы потребляют меньший процент от емкости системы по операциям ввода-вывода, поэтому система может выполнять большее количество таких запросов.[Источник 4]

Оптимизация запросов через сбор статистики

Статистическая информация о данных нужна, в первую очередь, для обеспечения работы оптимизатора запросов. Зная статистические характеристики данных и то, по каким критериям пользователь их запрашивает, оптимизатор может выбирать те или иные способы извлечения этих данных

В СУБД Teradata оптимизатор запросов принимает все решения, основываясь на объективной информации, которая ему доступна. В расчет берется: количество AMP-ов в системе, количество узлов, количество и типы процессоров, доступная в данный момент память, типы дисков и многое другое, включая демографию данных. Демографическая информация, которую мы и называем статистикой, включает в себя количество строк в таблице, средний размер строки, количество строк с одним и тем же значением колонки, количество NULL'ов и прочее. Знание этих параметров также позволяет оптимизатору правильно рассчитывать размеры временной памяти (spool), выделяемой запросу для проведения преобразований данных.

Собранная статистика хранится в словаре (DBC.TVFields, DBC.Indexes и DBC.StatsTbl для 14-й версии) и с точки зрения СУБД представляет собой интервальные гистограммы. Чем больше в последней число интервалов, тем более точно она может отражать распределение данных.

Рисунок 2 - Диаграмма, описывающая процесс оптимизации запроса с учетом статистик

В зависимости от распределения значений используется один из трех видов гистограмм для сохранения статистики:

  • Гистограмма с одинаковым размером интервалов. В каждом интервале сохраняется одинаковое количество значений. Возможно при наличии более-менее равномерного распределения значений, без явных перекосов (skew).
  • Гистограмма со смещенными интервалами. В каждом интервале хранится максимум два значения. Такой вид используется только в тех случаях, когда распределение имеет существенный перекос.
  • Сжатая гистограмма. Диаграмма, в которой комбинируются интервалы как одинаковых значений, так и интервалы лишь с двумя значениями.

Процесс сбора статистик в Teradata, равно как и в СУБД других вендоров, запускается командой COLLECT STATISTICS. Каждая статистика, определенная для таблицы, требует отдельного прохода по таблице. Начиная с 14-й версии, можно объединять сбор нескольких статистик в один проход по таблице.

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

  • Ищет заголовок таблицы в кэше. Если заголовок таблицы обнаружен в кэше, выполняется динамический сэмплированный сбор статистик (Random AMP sampling), если необходимо. Если он в кэше не обнаружен, производится его чтение с диска и выполняется динамический сэмплированный сбор статистик.
  • Ищет статистики для оптимизации запроса. Teradata ищет необходимые статистики в кэше. Если они там не обнаружены, выполняется запрос на чтение статистик с диска и их кэширование.
  • Использует статистики для оптимизации запроса. Если статистики на были собраны или устарели, оптимизатор может использовать статистики, полученные путем динамического сэмплирования. Это справедливо только для индексных колонок, в противном случае используется эвристика.

В описанном выше процессе важное место отводится статистикам, полученным динамическим сэмплированием (Random AMP sampling).[Источник 5]

Распределение строк

Алгоритм распределения строк в Teradata:

  1. Teradata использует алгоритм хэширования для рандомного распределения строк таблицы между AMP-ами (преимущества: распределение одинаково, независимо от объема данных, и зависит от содержания строки, а не демографии данных).
  2. Primary Index определяет, будут ли строки таблицы распределены равномерно или неравномерно между AMP-ами. Равномерное распределение строк таблицы ведет к равномерному распределению нагрузки. Каждый AMP отвечает только за свое подмножество строк каждой таблицы
  3. Строки размещаются неупорядоченно (преимущества: не требуется поддержка сохранения порядка, порядок не зависит от любого представленного запроса).

Primary Key (PK) vs. Primary Index (PI)

Primary Key (первичный ключ) – это условность реляционной модели, которая однозначно определяет каждую строку.

Primary Index – это условность Teradata, которая определяет распределение строк и доступ. Хорошо спроектированная база данных содержит таблицы, в которых PI такой же как и PK, а также таблицы, в которых PI определен в столбцах, отличных от PK, и может влиять на пути доступа.[Источник 6]

Primary Key Primary Index
Логическая концепция моделирования данных Механизм для распределения строк и доступа
Teradata не нуждается в определении PK Таблица должна обязательно иметь один PI
Нет ограничения на количество столбцов Может быть от 1 до 64 столбцов
PK определен в логической модели данных PI определяется при создании таблицы
Значение должно быть уникальным Значение не обязательно должно быть уникальным
Уникальность идентифицирует каждую строку Используется для размещения строки в AMP
Значения не должны меняться Значения могут меняться (обновляться)
Не может принимать значения NULL Может принимать значения NULL
Не относится к пути доступа Определяет наиболее эффективный путь доступа
Выбирается для логической корректности Выбирается для физической производительности соединения значений

Существует два типа PI: UPI (Unique Primary Index) и NUPI (Non-Unique Primary Index). При использовании UPI строки распределяются равномерно между AMP-ами, а при использовании NUPI строки с одинаковыми значениями индекса относятся к одному и тому же AMP-у.

Распределение строк с помощью хеширования

Значение Primary Index передается в алгоритм хеширования, который обеспечивает равномерное распределение уникальных значений среди всех AMP-ов. Алгоритм выдает 32-битное значение хэш-строки. Первые 16 бит (Hash Bucket Number) используются в качестве указателя на хэш-карту (Hash Map). Хэш-значения вычисляются с помощью алгоритма хэширования. Хэш-карта уникально сконфигурирована для каждой системы, это массив, который связывает DSW (ключ статистики) с определенным AMP. Две системы с одинаковым количеством AMP-ов будут иметь одинаковую хэш-карту. Изменение количества AMP-ов в системе требует изменений в хэш-карте.

NoPI Table

NoPI-таблица – это таблица без Primary Index. В этом случае новые строки добавляются всегда в конец таблицы и никогда не добавляются в середину хэш-последовательности. Строки будут так же распределяться между AMP-ами. Новый рандомный код будет определять, какие AMP получит строки или группы строк. В пределах AMP-а, строки просто добавляются в конец таблицы. Они будут иметь уникальный идентификатор, что увеличивает уникальность значения.

Преимущества:

  • Таблица уменьшит смещение в промежуточных таблицах ETL (извлечение, преобразование, загрузка), которые не имеют Primary Index.
  • Загрузки (FastLoad and TPump Array Insert) в NoPI промежуточной таблицы происходят быстрее.

Примеры применения

Финансовая сфера

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

Сфера торговли

Позволяет собрать и проанализировать данные за месяцы и годы, собранные в тысячах розничных магазинов по всему миру. Эта информация помогает в управлении покупкой, ценообразованием, складированием и управлении запасами и принятии решений о конфигурации хранилища.

Производство

Позволяет анализировать данные, чтобы определить наиболее эффективные способы доставки товаров потребителям и определить, сколько продуктов будет продаваться по данной цене и производить товары для доставки точно в срок.[Источник 7]

Источники

  1. Что такое Teradata//Habrahabr. [2006 – 2019]. Дата обновления: 01.11.2017. URL: https://habr.com/post/209078/ (дата обращения: 09.10.2018)
  2. Teradata – СУБД, параллельная от рождения // Habrahabr. [2006 – 2019]. Дата обновления: 07.10.2018. URL: https://habr.com/company/teradata/blog/160821/ (дата обращения: 09.10.2018)
  3. Teradata // Wikipedia. [2006 – 2019]. Дата обновления: 22.06.2018. URL: https://ru.wikipedia.org/wiki/Teradata#Teradata_Database (дата обращения: 09.10.2018)
  4. Поколоночное и гибридное хранение записей в СУБД Teradata // Habrahabr. [2006 – 2019]. Дата обновления: 19.10.2018. URL: https://habr.com/company/teradata/blog/170321/ (дата обращения: 09.10.2018)
  5. Статистика в СУБД Teradata // Habrahabr. [2006 – 2019]. Дата обновления: 26.09.2018 .URL: https://habr.com/company/teradata/blog/167801/ (дата обращения: 09.10.2018)
  6. Распределение строк и доступ в СУБД Teradata (Primary Index) // Habrahabr. [2006 – 2019]. Дата обновления: 20.12.2018. URL: https://habr.com/post/209166/ (дата обращения: 09.10.2018)
  7. Teradata database (Primary Index) // Teradata. [2019]. Дата обновления: 17.09.2018. URL: https://www.teradata.ru/Products/Software/Database (дата обращения: 09.10.2018)