СУБД Teradata для ОС UNIX

Компания Teradata была основана в 1979 году как дочерняя фирма компании Citicorp Advanced Technology Group. Продукт этой фирмы был разработан специально для непрерывной обработки больших объемов данных. В 1984 году фирма Teradata выпустила первые системы массивно-параллельной обработки (massively parallel processing - MPP) - специализированный компьютер для баз данных первой модели (DBC Model 1). Teradata первой вышла на рынок MPP-систем, опередив своих конкурентов более чем на десять лет. Начиная с того времени компания Teradata, а теперь и компания NCR (в 1991 году компания NCR купила компанию Teradata) выпускает один из лучших в мире продуктов для систем поддержки принятия решений и хранилищ данных.

80-ые годы

Первая система Teradata отвечала архитектуре программного обеспечения "ничего не разделяется" ("Shared Nothing") и функционировала на соответствующей аппаратной платформе. В системе были реализованы: интеллектуальная межпроцессорная шина YNET; связующие каналы с мэйнфреймами; механизм защиты данных от сбоев (Fallback); мощный оптимизатор, оценивающий относительную "стоимость" выполнения SQL-запроса, с возможностью выдачи подробных сведений о том, как выполнялся запрос. Все основные операции с данными выполнялись параллельно. Распараллеливались следующие операции и утилиты: INSERT, SELECT; UPDATE, DELETE; Nested Loop Join; Sort Merge Join; Hash Merge Join; архивация/восстановление данных; утилиты по загрузке данных; загрузчик программного обеспечения.

К 90-му в году в СУБД Teradata были реализованы следующие возможности: устоявшиеся типы данных, соединения по локальной сети, кеширование шагов синтаксического разбора SQL- запросов, объявляемые приоритеты, совместимость с базами данных DB2 и 10 уровней блокировок. Дополнительные, полностью распараллеленные возможности включали в себя: соединение операций по удалению записей (Delete Join), соединение операций по обновлению записей (Update Join), журналирование и утилиту параллельного обновления данных с возможностью обновления и вставки (UPSERT). На аппаратных платформах DBC третьего поколения было достигнуто двукратное улучшение соотношения цена/производительность.

В 80-ые годы непрерывное совершенствование СУБД Teradata стало неотъемлемой частью существования нашей компании. Размеры баз данных росли не по дням, а по часам. Первую систему, расчитанную на объем данных в 100Гбайт, Teradata выпустила в 1985, первую СУБД на 500Гбайт - в 1987 году и, наконец, первую СУБД на 700 Гбайт - в 1989 году. Тесты подтвердили, что мощность СУБД практически линейно зависит от числа процессоров, при увеличении числа процессоров до 300.

Начало 90-х годов

Постоянное совершенствование продолжалось и в 90-ые годы, были добавлены следующие возможности: Teradata Manager (Клиентское ПО, предназначенное для администрирования СУБД с удаленного ПК, работающего под ОС Windows 95/NT), Диспетчер запросов к базам данных (Database Query Manager), параллельная утилита экспорта данных, разрешен доступ к таблицам БД во время архивации, увеличена в 20 раз скорость восстановления узлов после сбоев, введены поддержка дисковых массивов RAID, параллельные внешние соединения, а также поддержка запросов, связанных с многомерным анализом (OLAP), для оптимизации которых используется соединение таблиц по типу Звезда или Снежинка и параллельный оператор Hash Star Join.

В 1992 году была выпущена первая система, оперирующая с 1 терабайтом данных. В 1993 году, согласно сведениям Smaby Group, доля NCR на рынке PP составляла 80%. В 1994 году была выпущена первая система, работающая с несколькими терабайтами данных. В 1997 году по результатам исследования проведенного компанией IDC по итогам 1996 года компания NCR занимает 50,5% рынка хранилища данных по поставкам и 40,9% по доходам по сравнению с ближайшими конкурентами DEC (поставки 16,8%, доходы 15,4) и IBM (поставки 10,1%, доходы 18,9%) соответственно.

Сегодня

Сегодня Teradata - продукт, поддерживающий хранилища данных объемом свыше 500 Гбайт и позволяющий реализовать системы с объемом пользовательских данных свыше 1 Тбайт (1 триллион байтов). На СУБД Teradata реализовано самое большое в мире промышленное хранилище данных с общим объемом в 24Тбайт. Teradata является "сердцем" хранилищ данных таких крупнейших в мире компаний, как AT&T, Sprint, British Telecom, Swedish Post, Australian Telecom, Bank of America, Chemical Bank, Fidelity Investments, Proctor and Gamble, WalMart, Kmart, Sears, Otto Versand, Delta Airlines, Qantas, USAir и American Airlines, и это далеко не полный список.

У одного из клиентов (не самого крупного) работает машина системы 3600, которая за день обрабатывает: 800000 OLTP-транзакций от 7500 пользователей со временем отклика меньше секунды; 2000 OLCP-транзакций от 400 пользователей с объемом данных до 70Мбайт на транзакцию и временем отклика от долей секунды до 20 минут; 40 сложных "нерегламентированных запросов DSS" от 6 пользователей-аналитиков; а также 25Мбайт транзакций, связанных с партиями товара, в базе данных объемом 750Гбайт, содержащей 1300 таблиц. В самой большой таблице содержится 2.4 миллиарда строк. В двух других таблицах содержится по 300 миллионов строк, а в большинстве таблиц содержится от миллиона до 10 миллионов строк. Система работает 7 дней в неделю, 24 часа в сутки.

СУБД Teradata для OC UNIX

С объявлением выпуска СУБД Teradata для ОС UNIX на машине WorldMark 5100 начинается самый драматический этап в истории постоянного совершенствования продукта со времен первого выпуска в 1984 году. С появлением СУБД Teradata для ОС UNIX на машине WorldMark 5100 были сняты все ограничения, накладываемые мощностью аппаратных платформ, таким образом были полностью реализованы возможности архитектуры СУБД Teradata. Использование СУБД Teradata для ОС UNIX сразу же улучшило соотношение цена/производительность в три раза по сравнению с системой 3600. Система включает: автоматическое добавление/удаление процессоров при почти 100%-ой степени надежности системы; непрерывную масштабируемость от SMP через кластерные системы к MPP; поддержку дисковых массивов через шину SCSI и новую масштабируемую межпроцессорную шину (BYNET). В системе реализованы: виртуальные процессоры; 20-кратное увеличение хэш-корзин (hash buckets) для поддержки баз данных объемом свыше 100Тбайт; работа с данными в блоках от 4Кбайт до 32 Кбайт, наличие доли свободного пространства в блоках данных и возможность освобождения страниц памяти, для улучшения работы систем с переменной нагрузкой; использование откомпилированных шагов выполнения SQL запросов; автоматическое восстановление фрагментации; глобальное планирование приоритетов; локальная журнализация измененных строк; настраиваемые пользователем размеры кеша для наборов данных; увеличенные размеры кеша для поддержки большинства сложных SQL-запросов к промышленным базам данных; улучшенные формулы оптимизации запросов; улучшенная обработка битовых образов (bit maps); обработка ситуаций полного отключения питания; поддержка в системе гигабайтной энергонезависимой памяти; более быстрый доступ к данным по значению неуникального первичного индекса; более быстрая система передачи сообщений между процессами; и, наконец, увеличенная производительность при распределении строк.

Завтра

И это только начало. Дальнейшие усовершенствования возможностей, функций, производительности и готовности СУБД Teradata во второй половине 90-х годов будут идти в ускоренном режиме. Соединения BYNET, мощность систем NCR WorldMark и базовая архитектура параллельного программного обеспечения позволят СУБД Teradata сохранить и укрепить позиции лидера в области промышленных реляционных СУБД, систем поддержки принятия решений и приложений для хранилищ данных.

Архитектура программного обеспечения СУБД TERADATA

Секрет мощности СУБД Teradata кроется в ее архитектуре. Архитектура Teradata уникальна в своем роде. Разработанная для поддержки очень больших баз данных (Very Large Databases - VLDB), с которыми работают различные приложения по поддержке принятия решений (Decision Support System - DSS) и приложения хранилищ данных (Data Warehousing - DW), СУБД Teradata построена на архитектуре "ничего не разделяется", с тщательно проработанным многомерным параллелизмом.

В архитектуре Teradata нет ничего однопотокового. При проектировании любых особеностей или утилит всегда принимался во внимание аспект параллелизма. С появлением версии СУБД Teradata для ОС UNIX был сделан значительный скачок вперед. Теперь Teradata работает на 32-х битовых современных машинах NCR серии WorldMark, 4700, 5150 и 5100. В системе параллельно выполняются все SQL-операторы, форматирование, восстановление, загрузка и извлечение данных, управление приоритетами, инсталляция и обновление программного обеспечения, отладка, управление производительностью, доступ к словарям, блокировки, соединения таблиц, и все остальные задачи. Архитектура Teradata достаточно быстро расширяется, в то время как конкуренты при проектировании своих систем преодолевают каждый 100-гигабайтный барьер, и их системы никогда не смогут выдержать реальную нагрузку хранилищ данных.

СУБД Teradata отвечает архитектуре программного обеспечения share nothing. СУБД имеет единый образ базы данных и использует несколько виртуальных процессов (Vprocs), которые для взаимодействия между собой используют высокоскоростной слой передачи сообщений (Message Passing Layer) с малым временем задержки. Этот слой реализован в составе расширений операционной системы для параллельных баз данных (Parallel Database Extensions - PDE). В дополнение к передаче сообщений, PDE поддерживает два типа виртуальных процессов: виртуальные процессоры PE (Virtual Parsing Engines - Virtual PE), отвечающие за взаимодействие, управление пользовательскими сессиями, оптимизацию запросов, создание и управление планом запроса; и виртуальные процессы AMP (Virtual Access Module Processes - Virtual AMP), используемые для фактического манипулирования таблицами баз данных.

Расширение параллельных баз данных (PDE)

В СУБД Teradata расширение PDE обеспечивает виртуализацию программных процессов AMP и PE. PDE включает в себя слой передачи сообщений, отвечающий за межпроцессное взаимодействие виртуальных процессов, распределение строк и слияние наборов данных в единый для пользователя ответ. PDE планирует процессы в зависимости от загрузки системы и приоритетов, определенных пользователями. PDE управляет памятью и дисковыми операциями ввода/вывода, распределяет виртуальные процессы по узлам системы и ставит диски в соответствие виртуальным процессам. PDE также собирает всю статистику по использованию системы и поддерживает сбалансированную загрузку системы.

Виртуальные процессоры PE (Parsing Engines)

Взаимодействие с виртуальными процессорами PE может выполняться по локальной сети (LAN), глобальной сети (WAN) и каналам связи с мэйнфреймами (стандартными или ESCON). Диспетчер сессий управляет пользовательскими сессиями, например, устанавливает и завершает их. Дополнительные компоненты виртуальных процессоров PE включают: синтаксический разборщик SQL-запросов (Parser), оптимизатор запросов (Optimizer) и диспетчер (Dispatcher). Разборщик выполняет грамматический анализ SQL-запроса и разбивает его на несколько элементарных шагов для последующего выполнения. Оптимизатор создает наилучший из всех возможных планов выполнения запроса, а диспетчер контролирует поток выполнения шагов уже соптимизированного запроса.

Управление выполнением запросов начинается при посылке первого шага запроса виртуальному процессору AMP и продолжается до тех пор, пока не будет получен и скоординирован последний набор ответных данных. Ответные наборы данных от всех виртуальных процессов-участников обработки AMP через слой передачи сообщений (Message Passing Layer) направляются диспетчером напрямую пользователю (за одну итерацию передается один буфер). Teradata автоматически распределяет пользовательские соединения по нескольким виртуальным процессорам PE, тем самым обеспечивая равномерную загрузку коммуникационных устройств и виртуальных процессоров РЕ, отвечающих за грамматический разбор и анализ SQL-запросов. Равномерная загрузка системы и сбалансированная передача потока ответных данных от параллельных виртуальных процессоров AMP непосредственно пользовательскому приложению исключает наличие "узких" мест в одном из узлов системы. Эта архитектура принципиально отличается от других архитектур, в которых окончательные наборы ответных данных формируются (а иногда и сортируются) на одном и том же узле системы.

Виртуальные процессоры AMP (Virtual Access Module Processes)

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

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

Многомерный параллелизм

Равномерное распределение данных на диске обеспечивается при помощи использования хэш-алгоритма. Кроме того, каждому виртуальному процессору AMP передаются не только одинаковые по объему данные, но и одинаковые вычислительные мощности (ЦП и память). Виртуальные процессоры работают параллельно как на узле SMP, так и на многих узлах SMP. Тем самым они образуют основную или горизонтальную составляющую параллелизма и взаимодействуют друг с другом, используя коммуникационный слой передачи сообщений (Message Passing Layer).

Кроме того, помимо только что описанного горизонтального параллелизма Inter-Vproc, каждый виртуальный процессор AMP реализует вертикальный параллелизм (Intra-Vproc). В каждом виртуальном процессоре AMP имеется большое число рабочих подпроцессов, находящихся в очереди и ожидающих запуска. По мере увеличение загрузки виртуального процессора AMP, динамически увеличивается и число активных подпроцессов в рамках этого АМР. Когда оптимизатор сгенерировал несколько шагов по выполнению запроса, то их можно параллельно выполнить на нескольких виртуальных процессорах AMP, при этом в рамках каждого АМР параллельно запускаются на выполнение несколько подпроцессов. Эти подпроцессы образуют вторичную или вертикальную составляющую параллелизма и взаимодействуют друг с другом через глобальную разделяемую память.

Архитектура СУБД Teradata способна эффективно использовать эту двухмерную модель параллелизма как при работе на одном виртуальном процессоре, так и при работе на нескольких виртуальных процессорах.

Распределение данных

Равномерное распределение данных - это ключевое понятие при реализации распределенной, параллельной загрузки системы. Для реализации равномерного распределения данных СУБД Teradata использует одну схему распределения, основанную на использовании хэш-алгоритма. Данные обрабатываются с помощью достаточно сложного алгоритма хэширования и автоматически распределяются между всеми виртуальными процессорами AMP, в соответствии с результатами этого хэширования. Данный алгоритм зарекомендовал себя как чрезвычайно эффективный для равномерного распределения данных. Он используется с 1983 года, и в течении всего последующего периода корпорация Teradata постоянно совершенствовала его для устранения неравномерного распределения данных, даже когда размер данных БД превышал 100 Тбайт.

При вставке строки в таблицу выполняется обработка значений в колонках, по которым объявлен первичный индекс. Это значение прогоняется через алгоритм хэширования. При этом вычисляются значения Hash Bucket и Hash ID (хэш-идентификатор). СУБД Teradata всего имеет 65 535 значений Hash Bucket, которые распределяются случайным образом между всеми виртуальными процессорами АМР. Если колонки, образующие первичный индекс вставляемой строки, были выбраны нужным образом (для обеспечения равномерности данные в этих колонках должны быть уникальны или почти уникальны), то погрешность равномерности распределения данных состовляет порядка 0,5%. Именно значение Hash Bucket, вычисленное алгоритмом хэширования, и определяет, какому виртуальному процессору AMP принадлежит нужная строка. Дело в том, что строка будет храниться на дисках, принадлежащих данному виртуальному процессору AMP.

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

Кроме того, в СУБД Teradata не выделяется заранее файловое пространство, а администратор БД заранее не рассчитывает, сколько места займет каждая таблица и на каком диске она должна находится. Таким образом, размещение данных полностью автоматизировано.

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

В большинстве СУБД имеется существенный недостаток: весьма болезненной и часто используемой операцией является операция переупорядочивания данных и индексов. Структуры файловой системы СУБД Teradata спроектированы таким образом, чтобы гарантировать, что они будут использоваться оптимально даже при выполнении большого числа операций вставки, обновления и удаления записей. В СУБД Teradatа никогда не появляются хэш-цепочки (hash chains). В этой СУБД не появляются несбалансированные B-деревья. В ней также отсутствует какая-либо фрагментация индексных структур верхнего уровня.

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

Оптимизатор

СУБД Teradata поддерживает весьма развитый оптимизатор. Этот оптимизатор был специально спроектирован для рынка параллельных приложений в системах поддержки принятия решения (DSS) в 1983 году. Оптимизатор генерирует достаточно сложные планы выполнения SQL-запросов, с целью максимального использования параллелизма системы. Оптимизатору известно, сколько единиц параллелизма (виртуальных процессоров AMP) работает в системе. Оптимизатору также доступна собранная статистика и демография данных. Он использует эту инфомацию для выработки последовательности шагов для наиболее эффективного выполнения SQL-запроса, которые скоординированно отправляются виртуальным процессорам AMP.

Оптимизатору доступны все сведения о работающей параллельной конфигурации аппаратного и программного обеспечения, поэтому он может весьма точно проводить сравнение планов выполнения запросов. Оценка плана выполнения SQL-запроса полностью основывается на относительной "стоимости" по выполнению запроса, при этом оптимизатор выбирает тот план выполнения запроса, "стоимость" которого минимальна. Планирование обычных подзапросов, внешних соединений и коррелированных подзапросов полностью учитывается и оценивается планировщиком операций соединений таблиц. У оптимизатора имеется специальный алгоритм для оптимизации соединений типа "звезда" и "снежинка" для достижения максимальной производительности при он-лайновой аналитической обработке транзакций (On-Line Analytical Processing - OLAP). Эти алгоритмы полностью встроены в планировщик соединений таблиц.

Другим достоинством оптимизатора является то, что его не требуется настраивать, задавать степень распараллеливания запросов и т.п. Не допускается использование каких-либо вспомогательных операций, влияющих на работу оптимизатора. Единственный способ повлиять на работу оптимизатора - это запуск оператора COLLECT STATISTICS; назначение этого оператора - предоставление оптимизатору достаточных статистических сведений по демографии данных. Оптимизатор в СУБД Teradata - это хорошо спроектированный и устойчивый инструмент, который может обрабатывать незапланированные и повторяющиеся запросы конечных пользователей, запросы, сделанные при помощи различных инструментов и утилит OLAP, при этом без вмешательства администратора БД или системного администратора. Администратор БД должен иметь достаточно хорошее представление о статистических характеристиках запроса, а также понимать демографию данных, их использование, чтобы определить то, что требуется индексировать, а также те индексы и колонки, по которым нужно собрать статистику с помощью оператора COLLECT STATISTICS. В обеих этих операциях полностью реализованы возможности параллелизма, и они выполняются достаточно быстро.

Далее представлен пример запроса SQL, который соединяет пять таблиц, выполняя при этом одно сравнение по полю Part Name (LIKE %GREEN) и вычисляя значение агрегатной функции по сумме фактических доходов. Сами доходы сначала вычисляются в агрегатной функции, и затем суммируются.

SELECT  S_NATION, O_ORDERDATE / 10000,
SUM(L_EXTENDEDPRICE * (L_DISCOUNT/100)  -
PS_SUPPLYCOST * L_QUANTITY)
FROM PARTS, SUPPLIERS, LINEITEM, PARTSUPP, ORDERS
WHERE 	S_SUPPKEY 	= L_SUPPKEY
AND 	PS_SUPPKEY 	= L_SUPPKEY
AND 	PS_PARTKEY 	= L_PARTKEY
AND 	P_PARTKEY	= L_PARTKEY
AND 	O_ORDERKEY	= L_ORDERKEY
AND 	P_NAME LIKE '%GREEN%'

GROUP BY S_NATION, O_ORDERDATE / 10000
ORDER BY S_NATION ASC,  O_ORDERDATE / 10000 DESC;

Этот пример иллюстрируют достаточно типичный запрос систем поддержки принятия решений. Таблица Lineitem - это очень большая таблица, с детализированными данными. Размер результата этого запроса невелик, поскольку собранная информация группируется по национальностям поставщиков (число национальностей < 100), и поэтому этот результат упорядочен так, чтобы его можно легко прочитать.

Стоит подчеркнуть, что оба типа распараллеливания выполнения запросов представлены в вышеприведенном запросе: горизонтальный параллелизм (Inter-Vproc Parallelism) - все четыре виртуальных процессора AMP выполняют каждый шаг запроса одновременно. Вертикальный параллелизм Intra-Vproc (Parse Step) parallelism - при отсутствии зависимостей между шагами оптимизатор СУБД Teradata укажет, что множество шагов можно выполнять одновременно внутри каждого виртуального процессора AMP.

В СУБД Teradata имеется одно мощное средство, называемое "Explain" (Подробная информация о выполнении запроса). Результатом работы утилиты "Explain" является вывод информации на английском языке о том, как по шагам выполнялся SQL запрос. Гарантируется, что вывод команды "Explain" всегда совпадает с реальным планом выполнения запроса, сделанным оптимизатором.

Соединение таблиц

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

Для выполнения обычных операций соединения таблиц оптимизатор может выбрать один из следующих основных способов: Hash Merge Join, Nested Message Join и Standard Product Join. Hash Merge Join работает на двух отношениях (таблицах), которые отсортированы по хэш-значениям, соединение производится по совпадающим хэш-значениям. Если одно или оба отношения (таблицы), участвующие в соединении, не хэшированы, не распределены и не отсортированы по полям соединения, то они должны быть соответствующим образом подготовлены к операции соединения, и это будет учтено оптимизатором при оценке "стоимости" выполнения данной операции. Nested Message Join выбирает строку из одной таблицы и отправляет ее виртуальному процессору AMP, где уже хранится строка, с которой должно произойти соединение. На этом процессоре AMP и выполняется соединение, после чего производится выдача его результата.

Оптимизатор СУБД Teradata может использовать несколько вариантов для выбора способа соединения таблиц. Он может непосредственно производить соединение с подтаблицей индекса, а не с базовой таблицей, если все нужные поля уже представлены в индексной подтаблице. Оптимизатор может также выполнять соединение с подтаблицей индекса и извлекать значения идентификаторов строк (т.н. ROWID-значения) из таблицы индекса, помещая их во временную таблицу, чтобы позднее их отсортировать и соединить снова с базовой таблицей для извлечения других строк.

Существует также набор операторов, применяемых только для внешнего соединения (т.н. OUTER JOIN), причем один - для каждого типа "внешнего соединения". Каждый из этих операторов может быть использован для основных типов соединений таблиц, которые были перечислены выше. Существует набор операций для исключающих соединений, которые используются для реализации следующих операций над множествами: INTERSECT (пересечение) и MINUS (вычитание), а также отдельных операций с подзапросами. Последней по счету операцией (но не последней по важности) является специальная операция соединения, которая используется для соединения типа "звезда". Эта операция, известная как Hash Star Join, выполняет соединения типа cross product joins за один шаг (запатентованный механизм). Оптимизатор выявляет соединения типа "звезда" и "снежинка" и генерирует специальный высокопроизводительный шаг по выполнению такого типа соединений, чтобы максимально повысить производительность системы.

Структуры, используемые для индексирования

Первичный индекс (Primary index)

В СУБД Терадата имеется два типа первичных индексов: уникальный первичный индекс (Unique Primary Index) и неуникальный первичный индекс (Non Unique Primary Index). Как известно, индексы используются для быстрого извлечения строк из таблиц БД, при этом можно избежать полного сканированиявсей таблицы.

Первичный индекс в СУБД Терадата - это механизм, использующий алгоритм хэширования, для поставки каждой строки таблицы БД конкретному виртуальному процессору АМР, а также применяемый для быстрого извлечения строк. Это позволяет большинство операций с БД выполнять очень быстро. В любой таблице БД имеется уникальный или неуникальный первичный индекс. Далее, при доступе к строке по первичному индексу или при вставке строки, используя некий "зашитый" алгоритм хэширования, система прогоняет через него значение первичного индекса. На выходе получается некое число из 32-х бит (т.н. Row hash). Первые 16 бит, называемые hash bucket, определяют, к какому виртуальному процессору AMP пойдет вставляемая строка. Значение hash bucket варьируется от 0 до 65535. Данные значения равномерно распределены между всеми АМР в системе. Таким образом, каждый АМР знает, какие значения hash bucket к нему относятся.

Если все значения колонки первичного индекса уникальны или почти уникальны, то данные будут равномерно распределены между всеми АМР. Все, что требуется от администратора БД, - это правильно выбрать колонку (или колонки) под первичный индекс.

Существует два уровня индексирования хэш-кодов. Первый уровень хранится в памяти. Это гарантирует, что в наихудшем с точки зрения оптимизации случае, при обращении к одной строке потребуются всего две операции ввода/вывода. При кешировании ввода/вывода обеспечивается высокая вероятность того, что индекс второго уровня попадет в кеш-память, и что блок данных также окажется в памяти. Такой механизм хранения данных гарантирует, что при вставке или изменении строк не будут увеличиваться накладные расходы, связанные с выполнением этих операций (наличие хэш-цепочеки, block extensions и т.п.). Кроме того, работают специальные фоновые задачи, которые по мере необходимости устраняют фрагментацию.

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

Вторичные индексы (Secondary index)

В СУБД Teradata используются два типа вторичных индексов: уникальные и неуникальные вторичные индексы. Данные в колонке (или в колонках), объявленных как вторичный индекс, поставляются в алгоритм хэширования. Получающийся на выходе Row Hash, указывает на строки в индексной подтаблице, в которой в свою очередь хранится индентификатор (Row ID) базовой строки. Таким образом, как и в случае первичных индексов, для быстрого поиска строк по вторичным индексам используется алгоритм хэширования.

Различие между уникальными и неуникальными вторичными индексами, в общем заключатся в том, что строки уникальных вторичных индексов глобально распределены между всеми АМР и извлекаются по тому же принципу, что и строки по первичному индексу. В этом случае как правило задействуются 2 виртуальных процессора АМР, так как строка базовой таблицы принадлежит одному АМР, а строка индексной подтаблицы другому АМР. В случае неуникальных вторичных индексов, строки индексной подтаблицы и соответствующие строки базовой таблицы принадлежат одному АМР. Таким образом, при доступе к строке по неуникальному вторичному индексу, всем АМР системы посылается сообщение-запрос о наличии строк в индексной подтаблице с заданным значением. Если АМР не имеет таких строк в индексной подтаблице, то в базовую таблицу он не пойдет.

Глобальный параллелизм

Глобальный параллелизм - это те встроенные в СУБД Teradata возможности распараллеливания, при использовании которых все составляющие параллелизма (т.е. все виртуальные процессоры AMP на всех узлах системы) знают, что они работают совместно. Ни одна из известных СУБД, где реализованы способы распараллеливания, не имеет таких возможностей, и это отрицательно сказывается на их общей производительности.

В СУБД Teradata коммуникационный слой передачи сообщений (Message Passing Layer) предоставляет средства сигнализации, с помощью которых системе становится известно, какой из виртуальных процессоров AMP закончил работу по выполнению данного шага SQL первым, а какой - последним. Для всех процессоров AMP гарантируется, что пока не будет закончен предыдущий шаг, следующий шаг не будет инициирован PE. Эта глобальная синхронизация имеет важное значение для поддержки сбалансированной и скоординированной работы системы.

Возможность превращения локальных задач в глобальные требует взаимодействия между собой виртуальных процессоров. Если возможности глобального распараллеливания не встроены в СУБД, то в случае, если OLTP СУБД пытается выполнять задачи систем поддержки принятия решений, моделирование совместной работы или разделения данных среди составляющих параллелизма будет затруднено и вызовет явные проблемы с производительностью. После того как, та или иная СУБД уже сформировалась как зрелый продукт для решения определенного класса задач на конкретной платформе, определенные трудности будут представлять выявление ситуаций взаимной блокировки пользователей друг другом (Deadlock) и глобальной синхронизации блокировок среди всех составляющих параллелизма (т.е виртуальных процессоров).

Реализация СУБД TERADATA на серверах WORLD MARK 5100/5150/4700 и 4300

В предыдущем разделе были описаны особенности архитектуры программного обеспечения СУБД Teradata. В данном разделе описана аппаратная реализация СУБД Teradata на многопроцессорных серверах NCR серии World Mark и показано, как был усовершенствован многомерный параллелизм СУБД Teradata "shared nothing" для того, чтобы добиться исключительной масштабируемости системы NCR WorldMark 5150. Уникальное сочетание всех этих средств дает возможность создать системы, обладающие превосходными характеристиками производительности машин класса SMP, высокой надежностью кластерных систем и несравненной мощностью MPP.

Перенос СУБД Teradata на UNIX-систему, состоящую всего из одного узла SMP, привел к такому улучшению показателя цена/производительность, что СУБД Teradata стала конкурентноспособной по сравнению с другими коммерческими СУБД, размер БД данных в которых составляет всего 10 Гбайт. При сравнении характеристик в диапазоне больших по объему баз данных, программное обеспечение СУБД Teradata, работающее на компьютере 5150, позволяет обрабатывать данные объемом до 100 Тбайт. Следует сказать, что 100 Тбайт является лишь "теоретическим" пределом объема БД. На сегодняшний день самым крупным в мире хранилищем данных в 24 Тбайт является ХД, построенное компаний Wal Mart, для сети магазинов розничной торговли в США.

Системы с объемом данных порядка 100 Tбайт предъявляют повышенные требования к дисковым системам хранения данных, производительности и надежности работы критически важных для бизнеса приложений. Критерии производительности, которым необходимо отвечать для поддержки эффективной обработки больших по объему данных, включают как возможности отвечать на непредсказуемые запросы многих пользователей, так и возможность эффективного обновления данных, а также возможность эффективного выполнения загрузки/выгрузки данных. Когда пользователь хочет обрабатывать терабайты корпоративных данных, то СУБД должна обеспечить готовность этих данных 24 часа в сутки, 7 дней в неделю, 52 недели в году. Именно с этих позиций компания NCR оценивает надежность работы СУБД Teradata для ОС UNIX на серверах серии WorldMark.

СУБД Teradata может функционировать на трех типах архитектур:

Архитектура SMP: Параллелизм СУБД Teradata функционирует на аппаратной многопроцессорной SMP-модели.
Кластерная архитектура: СУБД Teradata функционирует на аппаратной кластерной модели, в которой отсутствуют разделяемые ресурсы, за исключением системы дисковой памяти.
Архитектура MPP: СУБД Teradata функционирует на нескольких кластерах, в которых отсутствуют разделяемые ресурсы.

Когда система имеет разделяемый ресурс, то этот ресурс становится "узким местом" в системе при росте объемов баз данных до уровня терабайт. Именно по этой причине архитектура SMP, где все аппаратные ресурсы разделяемы, а также кластерная архитектура, имеющая разделяемые диски, не являются достаточными для БД большого объема. А вот архитектура МРР вполне пригодна для реализации всех возможностей СУБД Teradata, поскольку в этой архитектуре отсутствуют "узкие места", связанные с использованием разделяемых ресурсов. Архитектура МРР объединяет в себе мощь аппаратного обеспечения серверов World Mark 5150 и мощь ядра СУБД Teradata, что делает возможным работу с несколькими БД, с объемом данных в терабайты.

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

Узел SMP

На рисунке справа показан график зависимости производительность/цена от числа ЦП, добавляемых в архитектуру SMP. Добавление ЦП ведет к увеличению производительности, но это также приводит к росту стоимости. При хорошей реализации архитектуры SMP добавление первых ЦП приводит к линейной зависимости (т.е. линейной масштабируемости). Дальнейшее увеличение числа ЦП не приводит к такому же росту показателя производительность/цена из-за "узкого места" этой архитектуры - разделяемых ресурсов. Это свойственно всем SMP архитектурам. Единственное что меняется - масштаб этого графика.

Основной задачей при внедрении СУБД Teradata на узле SMP является создание по возможности наиболее экономичной системы, с оптимальной производительностью.

На рынке компьютерных систем идут споры и дискуссии о сравнительных достоинствах архитектур SMP и MPP. Диапазон этих дискуссий простирается от утверждения "SMP может все!" до утверждения "только MPP может масштабироваться". СУБД Teradata обходит эти проблемы, используя самый эффективный узел SMP (исходя из соотношения цена/производительность) и использует этот узел как основу для перехода в архитектуру MPP. Даже там, где это действительно так, и системы SMP имеют перспективы, их использование становится неэкономичным, так как выгоды от добавления дополнительных ЦП компенсируются неэффективностью использования системной шины, из-за большого числа обращений к ней. Увеличение числа эффективно используемых ЦП в архитектуре SMP требует больших затрат на улучшение работы системной шины. Во многих случаях эти деньги лучше потратить на переход к архитектуре MPP.

Таким образом, имеется дилемма, что дороже: стоимость нескольких ЦП или стоимость соединительной платы. Пусть, к примеру, вычислительная мощность системы SMP, состоящей из 32 ЦП, распределена следующим образом: 90% своей мощности дает каждый из первых 16 ЦП, а 10% своей мощности - каждый из оставшихся 16 ЦП. Теперь предположим, что в двухузловой системе, имеющей на каждом SMP узле 10 ЦП, мощность распределена следующим образом: 80% своей мощности дает каждый ее ЦП. Очевидно, что эти две системы имеют одинаковые вычислительные мощности, хотя у второй системы на 12 ЦП меньше. Система, состоящая из 20 ЦП, будет иметь меньшую стоимость, если стоимость поддержки взаимодействия двух узлов системы не превышает стоимость 12 дополнительных ЦП для одного узла системы.

Еще сравнительно недавно выпускались системы SMP, которые поддерживали еще большее число ЦП. Возможно, в будущем эта тенденция будет продолжена, а возможно и нет. В связи с поступлением на рынок процессора P7 фирмы Intel и сравнительно медленным ростом возможностей ввода/вывода, скорее всего число мощных и дорогих ЦП в системах SMP будет уменьшаться.

На сегодняшний день в одном узле сервера World Mark 5150 установлено 4 процессора Intel Pentium Pro с частотой 200 МГц. При этом система в минимальной конфигурации реализуется на двух SMP-узлах. 8 ЦП является оптимальным значением для СУБД Teradata. СУБД Teradata может работать в системах SMP, кластерных архитектурах и системах MPP.

Реализация СУБД Терадата в архитектуре SMP (5100S, 4300 или 4700)

Несколько процессоров AMP и несколько виртуальных процессоров PE функционируют на одном узле, состоящем из нескольких ЦП, с помощью разделяемого расширения PDE. Коммуникационный слой передачи сообщений (Message Passing Layer) реализован программно как Vnet (Virtual Network - виртуальная сеть). Vnet используется для передачи сообщений между виртуальными процессорами. При этом разделяются только компоненты ОС, PDE и Vnet. Виртуальные процессоры СУБД ничего не разделяют. В действительности они даже не знают, разделяют ли они аппаратные ресурсы вместе с другими виртуальными процессорами или нет.

В этой модели разделяются все аппаратные ресурсы (в том числе системная шина и каналы SCSI IO). Как и в других системах с разделяемыми ресурсами, указанные разделяемые ресурсы время от времени становятся "узким местом" в системе.

Реализация СУБД Терадата в кластерной архитектуре (5100C, 4700 и 5150)

Реализация СУБД Teradata в кластерной архитектуре из нескольких узлов SMP, соединенных с помощью высокоскоростной шины BYNET. На каждом узле функционирует несколько виртуальных процессоров AMP и несколько виртуальных процессоров PE. Эти процессоры могут быть равномерно распределены по узлам; либо конкретные узлы могут быть выделены для виртуальных процессоров AMP или PE. Рекомендуется использовать конфигурацию с равномерным распределением виртуальных процессоров. Коммуникационный слой передачи сообщений (Message Passing Layer) реализован как комбинация программного обеспечения PDE и BYNET.

Никакое программное обеспечение не разделяется между этими узлами, поэтому архитектура "shared nothing" для СУБД Teradata естественным образом поддерживается в такой архитектуре. Каждый виртуальный процессор AMP монопольно владеет своей долей дискового пространства, на подключенном в систему дисковом массиве RAID. Единственным разделяемым аппаратным ресурсом являются BYNET (шина для коммуникации виртуальных процессоров между собой) и шина SCSI интерфейса.

Помимо виртуальных процессоров AMP и PE, каждый узел может иметь соединение с локальной сетью, до восьми канальных соединений с мэйнфреймами и UNIX-приложения (например ASF2). Два узла - это минимальная конфигурация одного кластера, максимальная конфигурация - 16 узлов на один кластер. Системный администратор может определять количество и расположение всех виртуальных процессоров.

Шина BYNET

Одна из уникальных отличительных особенностей больших систем NCR - это высокоскоростная шина BYNET. Она позволяет осуществлять масштабирование систем до огромных размеров. Bynet была спроектирована специально для работы с СУБД Teradata, а СУБД Teradata была спроектирована под шину BYNET. Этот программно-аппаратный тандем является ключевым фактором для объединения серверов серии World Mark с СУБД Teradata. BYNET - это отказоустойчивая, интеллектуальная, высокоскоростная, полностью масштабируемая сеть с коммутируемыми соединениями, обеспечивающая скорость передачи 20 Мбайт в секунду на один узел. Таким образом, кластер из 8 узлов 5100 будет иметь общую пропускную способность 160 Мбайт/сек.

Другие средства коммутации предлагают еще большую пропускную способность, однако не является главным. В действительности, если СУБД нужна более высокая пропускная способность, чем у BYNET, то это значит, что структура базы данных спроектирована недостаточно хорошо. Например, некоторые бизнес-приложения WalMart работают с базой данных в 3 Тбайт на машине 3600, в системе функционируют 365 виртуальных процессора AMP, при этом загрузка на канал связи составляет всего лишь 22 Мбайт/сек.

Энергонезависимая память

Когда SQL-запрос обновляет блок данных, копия обновлений направляется по BYNET соседнему узлу, находящемуся в том же самом кластере. Если происходит сбой узла-источника, то соседний узел помещает блок данных на диск узла-источника. Такой алгоритм работы позволяет рассматривать память как энергонезависимую (NVRAM). Наличие нескольких гигабайтов NVRAM позволяют предотвратить сбои для описанной выше операции, характерный для систем из одного SMP узла.

Высокая надежность системы

В СУБД Teradata имеется достаточно много механизмов по обеспечению высокой надежности системы. Эти механизмы показаны на

При возникновении внутренних сбоев BYNET будет автоматически перенаправлять сообщения. В случае полного сбоя сети BYNET, программное обеспечение будет перенаправлять пакеты по другим сетям. Поддержка дисковых массивов RAID гарантирует жизнеобеспечение системы в случае сбоя или замены дисков, а поддержка RDAC гарантирует жизнеобеспечение системы в случае сбоя или замены дискового контроллера. Защита от сбоев электропитания выполняется засчет сохранения копии содержимого оперативной памяти на диске, и ее последующего восстановления после включения питания.

Все эти механизмы восстановления системы от сбоев не требуют перезапуска системы и не влияют на выполнение текущих транзакций.

Программное обеспечение PDE, входящее в состав СУБД Teradata, также имеет механизмы восстановления после полного сбоя узла системы. Все виртуальные процессы отказавшего узла перенаправляются на остальные узлы кластера. На это требуется всего 90 - 120 секунд, в течение которых перезапускается база данных и происходит выравнивание нагрузки в системе. После перезапуска базы данных все AMP восстанавливаются, а это значит, что база данных снова становится доступной для пользователей.

Если произойдет сбой других узлов этого же кластера, то используется та же самая схема. 100%-ая готовность пользовательских данных гарантируется даже тогда, когда работоспособными остаются: один диск в каждом rank'e дискового массива, один контроллер дискового массива, один маршрут в сети BYNET и один узел. Такой уровень обеспечения высокой надежности СУБД Teradata не требует больше использования механизма резервного копирования данных между АМР (т.н. механизм FALLBACK). Следует обратить внимание на то, что по мере выхода из строя компонентов системы производительность падает, а если число работоспособных узлов уменьшается до одного, то также невозможно будет воспользоваться механизмом NVRAM.

Масштабируемость системы

Измерения показали, что на одном узле системы 3600 могут работать 20 процессеров AMP, а на четырех узлах может работать 80 виртуальных процессоров AMP. Эти результаты подтверждают линейный рост масштабируемости. Сервер серии World Mark 5100 унаследовал все достоинства масштабируемости от своего предшественника.

Реализация СУБД Teradata в архитектуре MPP (5100 и 5150)

Как и в случае с однокластерной системой, на каждом узле работают несколько виртуальных процессоров AMP и несколько виртуальных процессоров PE. При этом можно либо распределить равномерно процессы по узлам, либо приписать каждому AMP или PE определенный узел. Слой передачи сообщений реализован в виде комбинации программного обеспечения PDE и BYNET.

Кластеры не разделяют ни программное, ни аппаратное обеспечение. Архитектура СУБД share nothing естественно гармонирует с архитектурой системы, а возможности масштабируемости практически беспредельны.

Мощь MPP-архитектуры

Данная конфигурация может обрабатывать от 2 до 32 Тбайт данных. Общая пропускная способность шины BYNET равна 320 Мбайт/сек. Для сложных запросов по поддержке принятия решений, в случае полного сканирования диска, система в данной конфигурации может выполнять до 40000 операций чтения в секунду. Строки в 163-байта располагаются в блоках по 32К, поэтому 1.6 миллиона строк могут составлять до 64 гигабайтов памяти, ежесекундно анализируемых 256 процессорами Pentium для выполнения сложных пользовательских SQL-запросов. 1.6 миллион строк в секунду - скорость впечатляющая. Вот она, мощь MPP-архитектуры и СУБД Teradata!

BYNET

В настоящее время сеть BYNET позволяет соединять максимум 512 узлов с максимальным объемом базы данных в 128 Тбайт и пропускной способностью системы 10 Гбайт/сек. СУБД Teradata для ОС UNIX, выпущенная в декабре 1995 года, поддерживает базы данных объемом до 128 Тбайт, поэтому как только появится оборудование для создания более крупных систем, будет проведена сертификация СУБД Teradata для работы на таком оборудовании.

Теоретический предел возможностей сети BYNET составляет 4096 узлов. Благодаря современной технологии проектирования узлов, данный предел может быть реально достигнут. На таком количестве узлов можно разместить 16384 гигабайта памяти, 65536 процессоров и базы данных объемом в 1000 терабайт (1000 терабайт называется петабайт). Тем не менее, первый релиз данной технологии вовсе не означает достижения какого-либо технологического предела, поскольку уже в 1997 году объемы баз данных в сферах розничной торговли и телекоммуникаций превысят 70 Тбайт. Петабайтные базы данных будут содержать нереляционные объекты, такие как текст, звук, видео и телеметрическую информацию.

Защита инвестиций

По мере роста пользовательских систем от архитектуры SMP, к кластерным системам и MPP-системам, инвестиции, вложенные в аппартное и программное обеспечение, должны быть защищены на все 100%. Например, обновление системы 5100S до системы 5100C выполняется за счет установки дополнительных узлов, рабочей станции администратора системы (AWS) и соединительной платы для существующих узлов 5100S. Аналогичным способом система 5100C обновляется до 5100M. Инвестиции, вложенные в аппаратуру 5100C, защищены на 100%. Обновление системы выполняется на месте. СУБД Teradata, работающая на 5100S, - это та же самая СУБД, работающая на 5100C и на 5100M. Инвестиции в базы данных и все приложения также защищены на 100%.

Гибкость СУБД Teradata позволяет добавлять в существующие системы дополнительные узлы и стойки следующего поколения. Баланс в системе поддерживается за счет распределения виртуальных процессоров по всем узлам. По мере добавления в систему более мощных узлов увеличивается и число виртуальных процессоров. Аналогичным образом первоначальные инвестиции в аппаратуру 5100 будут защищены на 100% , даже при появлении технологически новых систем.

Технические особенности СУБД TERADATA

СУБД Teradata для UNIX предоставляет широкие возможности. Эти возможности рассматриваются в последующих разделах.

Возможности клиента базы данных

Пользовательские приложения могут работать с СУБД Teradata через интерфейс уровня вызовов CLI (Call Level Interface), Micro Teradata Director Program (MTDP) и Micro Operating System Interface (MOSI). Эти программные компоненты направляют операторы SQL системе управления базой данных и возвращают ответы на запросы приложению. Процедуры CLI, MTDP и MOSI хранятся в библиотеках, которые линкуются с приложением. Teradata поддерживает стандартные программные интерфейсы, такие как ODBC, JDBC и ESQL.

Возможности сервера баз данных

На серверах World Mark функционирует серверная часть СУБД. Клиентское программное обеспечение поставляется для IBM MVS и VM, UNIX System V (включая 5100), DOS, Windows, OS/2, Macintosh и других платформ. Клиентские приложения направляют операторы SQL на выполнение в СУБД.

Клиентские платформы подключаются к серверу либо через локальную сеть (LAN-attached clients), либо через каналы связи (channel-attached clients). Последнее относится к мэйнфреймам.

Средства разработки клиентских приложений СУБД Teradata для OC UNIX состоят из препроцессоров ESQL с языков (COBOL, C и PL/I), а также программных интерфейсов CLI и Teradata Director Program. В программное обеспечение для мэйнфреймов IBM входят модули связи с CICS и IMS/DC. Кроме того разработка прикладного ПО возможна через имеющиеся драйверы ODBC и JDBC, с использованием таких средств как MS Visual Basic, MS Visual C++ и др.

В программное обеспечение сервера баз данных также входит шлюз базы данных (DBS Gateway), который преобразует внешние сетевые протоколы во внутренние протоколы сообщений СУБД.

SQL

Teradata SQL обеспечивает полный уровень совместимости с ANSI-стандартом языка SQL. Кроме того имеются свои собственное расширения стандарта SQL, специфичные исключительно для СУБД Teradata. Пользователь, работающий с СУБД Teradata через программу BTEQ (клиентская программа для интерактивной работы с БД), может установить для себя либо режим ANSI SQL, либо Teradata SQL. К некоторым из важных особенностей относятся:

Оператор ALTER TABLE, который добавляет столбцы или индексы к существующим таблицам
Обновляемые представления (VIEW), включая поддержку виртуальных столбцов
Вложенные подзапросы
Макросы SQL: именованные последовательности операторов SQL
Функции справки (HELP и SHOW), которые могут показывать структуры БД, таблиц, представлений и статистические данные.
Функция EXPLAIN - используется следующим образом. Перед SQL запросом достаточно поставить слово explain, explain select ... (текст запроса). Результатом будет подробное объяснение пошагового выполнения запроса на английском языке

Препроцессоры

В СУБД Teradata входят следующие препроцессоры для языков:

VS COBOL, C и PL/1 для сред MVS и VM;
ANSI C для среды UNIX;
COBOL

Интерфейс уровня вызова (Call-Level Interface - CLI)

Интерфейс уровня вызова (Call-Level Interface - CLI) - это набор библиотечных функций, которые предоставляют прикладной программе интерфейс к СУБД Teradata. Вызовы CLI обычно поставляются в препроцессоре языка, но они также могут вызываться непосредственно в языках, для которых нет препроцессоров. В данный момент для большинства платформ доступен CLI версии 2 (CLIv2).

Словарь метаданных

В СУБД Teradata включен полностью интегрированный словарь метаданных (Data Dictionary), который позволяет пользователям получать информацию об объектах базы данных (например, таблицах и столбцах). Словарь метаданных состоит из системных таблиц и представлений, потому к нему можно обращаться с помощью стандартного языка SQL.

Безопасность в Словаре данных обеспечивается с помощью механизмов представлений (VIEW) и привилегий (PRIVILEGES). Для администраторов баз данных существуют специальные представления, в которых содержится информация о доступе, использовании и владельцах.

Управление транзакциями

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

Защита целостности данных

Целостность данных поддерживается в СУБД Teradata с помощью следующих возможностей:

Управление параллельной работой

Teradata предоставляет возможность блокировки на уровне базы данных, таблицы и хэш-значений для строк. Блокировки имеют четыре уровня: эксклюзивный (exclusive), на запись, на чтение и на доступ.

Защита при восстановлении

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

Резервное копирование и архивация баз данных

В дополнение к возможностям по архивации в режиме "off-line", предоставляемым утилитой Архивации и Восстановления (Archive and Recovery utility) и функцией Архивации и хранения (Archive and Storage Facility), в Teradata также доступны постоянное и временное журналирование. Все операции выполняются параллельно.

Журналирование

Для обеспечения целостности транзакций в СУБД Teradata используется постоянное и временное журналирование.

Временный журнал (Transient Journal)

Во временном журнале хранятся образы строк перед тем, как они изменяются в ходе транзакции, выполняющей обновление данных. После фиксации транзакции эти образы удаляются из журнала, позволяя повторно использовать освободившееся пространство. Если транзакция не может быть завершена, то Teradata выполняет автоматический "откат" транзакции и строки таблицы БД возвращаются в первоначальное состояние, используя образы во временном журнале.

Постоянный журнал (Permanent Journal)

Постоянные журналы - это необязательные таблицы, в которые записываются образы строк до выполнения транзакции и/или после фиксации транзакции. В качестве дополнительной защиты допускается двойное копирование образов, даже если для журналируемых таблиц, не используется механизм защиты fallback. Постоянные журналы позволяют выполнять откат (roll back) или прокрутку таблицы или всей базы данных (roll forward) к той или иной контрольной точке.

Механизм защиты данных - Fallback

При необходимости СУБД Teradata может хранить две копии таблиц: основную и аварийную копию, распределенные между виртуальными процессами AMP. При нормальной работе чтение производится только из основной копии, а обновление выполняется в обеих копиях. Если при сбое первая копия становится недоступной, то для чтения и обновления используется аварийная копия. С появлением RAID и кластеров в большинстве случаев использование аварийной копии стало излишним.

Кластеры

Несколько узлов 5100, 5150 или 4700 могут быть соединены в конфигурацию с разделяемым диском. Такая конфигурация называется кластером. При сбое любого узла в кластере все остальные узлы разделяют его нагрузку, до тех пор пока он не будет востановлен. Это позволяет добиться сбалансированного восстановления от сбоев и избежать значительного ухудшения производительности, которое наблюдается на многих MPP-платформах с неработающими компонентами.

Восстановление - операционная система не перезапускается

В случае перезагрузки СУБД происходит перезапуск всех ее программных компонентов. Однако в СУБД Teradata операционная система не перезапускается, что обеспечивает более быструю перезагрузку всей системы. Во время процесса восстановления каждый виртуальный процесс AMP восстанавливает по журналу транзакций таблицы данных, а также используя т.н. системную таблицу, называемую cylinder indexes и постоянно расположенную на диске, строит таблицу master index, постоянно расположенную в оперативной памяти. Восстановление виртуальных процессов AMP выполняется параллельно и асинхронно.

Обеспечение защиты данных от несанкционированного доступа

СУБД Teradata поддерживает предоставление и отмену привилегий для каждого пользователя на любую таблицу, представление, макрос или базу данных. Привилегии даются на: создание или удаление одного из данных объектов, выполнение макроса, вставку, выборку, обновление или удаление строк в таблице, а также на предоставление привилегий другим пользователям.

Идентификация пользователя происходит по его логическому имени и паролю, логическое имя также используется для назначения дискового пространства. Все функции безопасности определены посредством языка Teradata SQL. Поддерживается уровень безопасности C2.

Поддержка СУБД TERADATA в ОС UNIX

Для поддержки СУБД Teradata ОС UNIX используются следующие основные компоненты:

Программа Database Window
Утилиты поддержки
Интерфейсы и утилиты для клиентов, подсоединенных через каналы связи
Продукты расширения для клиентов, подсоединенных по каналам связи
Интерфейсы и утилиты для клиентов, подсоединенных через сеть (LAN)
Программное обеспечение для шлюза базы данных (DBS Gateway)
Программное обеспечение для поддержки каналов связи

Назначение этих компонентов объясняется в последующих разделах. Особое внимание уделено новым возможностям.

Программа Database Window

Database Window - это консольная программа для системного администрирования СУБД Teradata. Она может быть запущена в любой среде, поддерживающей Xwindows. При запуске Database Window появляется главное окно, из которого пользователь может вызвать окно супервизора, окно сообщений базы данных или любое из окон приложений.

Утилиты поддержки

Далее приводится список утилит, которые используются системными инженерами, администраторами баз данных и системными администраторами. Данные утилиты предоставляют базовые функции по обслуживанию СУБД Teradata. Эти утилиты, за исключением Pdeconfig, запускаются из приложения Database Window на рабочей станции по администрированию системы (AWS). Pdeconfig запускается как приложение UNIX. Возможности, реализованные в Teradata для UNIX, выделены жирным шрифтом.

AbortHost - отменяет незавершенные транзакции
Checktable - проверяет целостность и непротиворечивость таблицы
Config - задает логическую конфигурацию СУБД (Виртуальные процессы AMP и виртуальные процессы PE)
DBSControl (Управление СУБД) - позволяет задавать для СУБД глобальные runtime-флаги
DIP (Программа инициализации базы данных) - инициализирует базу данных
Vproc Manager (Диспетчер Vproc) - позволяет специально обученным сотрудникам получать статистическую информацию о Виртуальных процессрах и изменять различные параметры Виртуальных процессоров
Gateway Control Utility (утилита управления шлюзом) - управляет сетевыми соединениями
Ferret - позволяет специально обученным сотрудникам просматривать и устанавливать различные параметры, контролирующие использование дискового пространства, без разрушения данных файловой системы. После установки параметров Ferret может динамически переконфигурировать данные на диске так, чтобы они соответствовали новым параметрами.
Filer - позволяет специально обученным сотрудникам получать сведения, необходимые для поиска и исправления ошибок в файловой системе. Эту утилиту следует использовать с большой осторожностью, поскольку она иногда обходит средства безопасности при отображении или изменении параметров. (Программа предоставляется для использования только специалистами NCR.)
Pdeconfig - инициализирует PDE и конфигурирует аппаратное обеспечение для виртуальных процессов
QryConfig (Запрос по конфигурации) - отображает текущую логическую конфигурацию СУБД
QrySessn (Запрос по сеансам) - отображает информацию о статусе сеансов
RcvManager (Диспетчер восстановления) - отображает статус процесса восстановления данных
Rebuild (Построение таблицы) - восстанавливает таблицу или таблицы из аварийной копии, механизма fallback
Reconfig - перераспределяет данные на дисках. Выполняется автоматически при добавлении или удалении виртуальных процессов AMP
Showlocks - показывает блокировки на базах данных и таблицах
SysInit (Инициализатор системы) - позволяет специально обученным сотрудникам инициализировать системные таблицы Teradata и все пользовательские таблицы

Базовое программное обеспечение для клиентов, подсоединенных через сеть (LAN)

Базовое программное обеспечение является интерфейсом между СУБД Teradata и приложением, работающим на подсоединенной через сеть клиентской платформе. В базовое программное обеспечение входят:

Micro Teradata Director Program (MTDP)
Micro Operating System Interface (MOSI) - библиотека сервисов для конкретной операционной системы и коммуникационного протокола связи. MTDP вызывает процедуры в библиотеке MOSI (вместо прямых обращений к библиотеке операционной системы) для выполнения таких системных сервисов, как обработка прерываний, обработка ввода/вывода, а также связи по сети.
Интерфейс уровня вызова (CLI) Версии 2

Утилиты для клиентов, подсоединенных через сеть (LAN)

В состав утилит, запускающихся на подсоединенных через сеть клиентских платформах, входят:

Basic Teradata Query (BTEQ) - выполнение базовых запросов к СУБД Teradata
FastLoad - загрузка данных в пустые таблицы.
Preprocessor для языка С - для платформ NCR, на которых установлена ОС UNIX
Preprocessor для языка COBOL - для платформ NCR, на которых установлена ОС UNIX

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

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

WINCLI - для IBM PC и совместимых машин, на которых установлена операционная система MS-DOS и Microsoft Windows
ODBC - для IBM PC и совместимых машин, на которых установлена операционная система Microsoft Windows
Модуль доступа OMNI для СУБД Teradata
Database Query Manager (Диспетчер запросов к базе данных)

Клиентское программное обеспечение

В дополнение к базовому программному обеспечению клиентов и клиентским утилитам, подключающимся через сеть, для платформ 5100/5150/4700 также доступно следующее программное обеспечение:

Archive Storage Facility (ASF2) - обеспечивает полную архивацию и восстановление баз данных Teradata на ленточные устройства. Это избавляет от необходимости делать архивацию через мэйнфрейм IBM. Утилита ASF2 также используется, чтобы записывать на ленты дампы памяти, которые могут быть затем проанализированы сотрудниками из службы технической поддержки.
FastExport - выгрузка данных из таблиц
MultiLoad - загрузка и обновление данных в пустых и непустых таблицах

Программное обеспечение шлюза DBS Gateway

DBS Gateway преобразует внешние сетевые протоколы во внутренние протоколы сообщений СУБД. Первая версия СУБД Teradata для UNIX на платформе 5100 поддерживает через шлюз порядка 600 сеансов.

Программное обеспечение поддержки каналов связи

Программное обеспечение поддержки каналов связи IBM обеспечивает соединение с мэйнфреймом IBM или другими совместимыми мэйнфреймами. Поддержка каналов на 5100 предоставляет до 8 каналов связи на узел и 120 сеансов на канал.

Заключение

В настоящее время Teradata является одним из лучших в мире продуктов для массивно-параллельной обработки (MPP). Этот продукт, имеет четырнадцатилетнюю историю в технологиях параллельной обработки данных и по-настоящему поддерживает хранилища данных террабайтного объема в наиболее крупных компаниях мира. В настоящее время на UNIX-платформе, на серверах WorldMark 4700/5100/5150 СУБД Teradata достигла выдающейся производительности в SMP-системах, высокой степени надежности в кластерных системах и впечатляющей мощности в MPP-системах. Масштабируемое аппаратное и программное обеспечение, а также разумная ценовая политика делают продукты привлекательными для предприятий, использующих системы DSS.

Совсем недавно компания NCR представила новое поколение MPP-серверов: это модели NCR WorldMark 4700 и 5150. Обе модели представляю собой принципиально новое решение, сочетая в себя традиционные для серверов компании NCR, черты такие как непревзойденная производительнось, масштабируемость, высокая готовность, выгодное соотношение цена/производительность и, как итог, беспрецедентная защита инвестиций. Обе машины используют стандартные Intel-компоненты и архитектектуру PCI и позволяют клиентам начать с нескольких десятков гигабайт и расти до десятков терабайт.

Кирилл Лисянский,
Дмитрий Слободяников
NCR