Врожденный параллелизм

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

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

В продуктах Teradata изначально были отвергнуты однопоточные операции. Разработчики распараллелили все, от ввода SQL-предложений до мельчайших деталей их выполнения. Фундаментальная идея состояла в том, чтобы снабдить каждый компонент системы множеством братьев-близнецов. Не зная заранее, где появятся «узкие места», разработчики предусмотрительно устранили причины заторов. В СУБД Teradata можно без ограничений определять число путей межузловых соединений, каналов связи с мэйнфреймами, шлюзов и единиц параллелизма. Это дает гибкость и контроль над производительностью, которая критически важна для современных крупномасштабных систем, предназначенных для поддержки принятия решений.

Основной единицей параллелизма является виртуальный процессор доступа (Access Module Processor). Все запросы и операции загрузки данных, резервного копирования, построения индексов распределяются между AMP. В первой версии AMP были физическими процессорами, но затем стали виртуальными. На отдельном SMP-узле (Symmetric MultiProcessor — «симметричная многопроцессорность») могут работать несколько AMP, реализованных в виде процессов операционной системы, а все такие узлы объединяются в систему с массовой параллельной обработкой (Massively Parallel Processing, MPP). Процессоры AMP позволяют распределять ресурсы, распараллеливая все операции. А для повышения их производительности используются методы организации как внешнего, так и внутреннего параллелизма.

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

Внутренним параллелизмом называют перекрытие по времени отдельных операций с базой данных. Оптимизатор разбивает SQL-запрос на несколько высокоуровневых операций, называемых шагами, и направляет их AMP для выполнения. Часто шаг является довольно большим фрагментом работы и может быть простым (таким как сканирование таблицы и возврат результата) или сложным (сканирование двух таблиц с отбором строк, соединение таблиц, перераспределение результатов соединения по указанным столбцам, сортировка перераспределенных строк и размещение результатов в промежуточной таблице). В пределах каждого из таких шагов несколько операций выполняются параллельно с помощью конвейерной обработки. При сканировании таблиц отобранные строки могут по конвейеру отправляться в процесс соединения (рис. 1). Конвейерная обработка позволяет начать следующее действие прежде, чем закончено предыдущее. Она выполняется при любой возможности в пределах каждого шага.

Рис. 1. Конвейеризация четырех действий одного шага SQL на каждом процессоре AMP

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

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

На рис. 2 показана система с четырьмя AMP и запрос, разделенный оптимизатором на семь шагов. Шаг 2.2 (аналогичный шагу 1.2) соответствует внутреннему параллелизму: сканируются и соединяются две таблицы, Lineitem и Order. Все три действия выполняются конвейерным методом в пределах одного шага. Шаги 1.1 и 1.2, как и шаги 2.1 и 2.2, демонстрируют многошаговый параллелизм, при котором каждый процессор AMP выполняет два шага одновременно.

В дополнение к методам параллельной обработки, показанным на рис. 2, предлагается расширение SQL, называемое Multi-Statement Request («запрос, состоящий из нескольких предложений»), позволяющее связать несколько предложений SQL и направить их оптимизатору как единое целое. СУБД пытается выполнить эти предложения параллельно, причем все общие подвыражения обрабатываются однократно, а результаты поступают в общее пользование. Соответствующий метод известен как «исключение общих подвыражений». Если связать вместе шесть предложений выбора SELECT, содержащих один и тот же подзапрос, последний будет выполнен только один раз. Но даже если предложения SQL зависят друг от друга и выполняются с перекрытием по времени, каждое из них возвратит собственный независимый результат.

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

Размещение данных

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

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

Хеш-секционирование

Введенные данные обрабатываются с помощью сложного алгоритма хеширования и автоматически распределяются по всем процессорам AMP. Индексация также основана на хешировании, что уменьшает нагрузку на администратора базы данных при настройке прямого доступа. Для определения базы данных администратор просто выбирает в каждой таблице в качестве первичного ключа столбец или набор столбцов. Как показано на рис. 3, хеш-коды ключевых столбцов определяют процессор AMP, который принимает данные на хранение, и логическое местонахождение данных в его дисковом пространстве. И все это — без выполнения отдельной операции CREATE INDEX («Создать индекс»). При выборе строки значение первичного ключа также передается алгоритму хеширования, который выдает хеш-коды, определяющие, какой процессор AMP владеет строкой и где находятся данные. Хеш-секционирование обеспечивает несколько явных преимуществ системам поддержки решений.

Механизм индексации на основе хеширования позволяет обойтись без упорядочения ключей. Часто в системах управления базами данных для индексации применяется тот ли иной вариант сбалансированного дерева (B-дерева) на базе алфавитной последовательности, указанной пользователем. По мере поступления в систему новых данных и добавления в случайном порядке элементов к индексам B-дерева эти структуры постепенно становятся неупорядоченными. Стоимость использования индекса быстро возрастает, а при реорганизации вся структура становится недоступной. Алгоритмы хеширования не задействуют требующих реорганизации вторичных структур, им не нужны определенный пользователем алфавитный порядок и сортировка данных перед занесением или вставкой.

Хеш-секционирование позволяет по значениям первичного ключа поместить на один узел сходные строки из разных таблиц. Если соединение выполняется по первичным ключам обеих таблиц, подлежащие соединению строки будут находиться на одном узле и принадлежать одному процессору AMP. Расположение соединяемых строк в памяти одного узла приводит к уменьшению межузлового трафика и времени выполнения запроса, а само межузловое соединение высвобождается для другой работы (рис. 4). Для размещения хешированных данных требуется лишь выбрать столбцы, образующие первичный индекс таблицы, а затем процесс физического размещения данных полностью осуществляется в автоматическом режиме. Не нужно изменять размеры и переименовывать файлы, предпринимать выгрузку или перезагрузку данных.

Рис. 4. Операция соединения, позволяющая избежать избыточной нагрузки на межузловое соединение: подлежащие соединению строки принадлежат одному процессору AMP

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

Секционированный первичный индекс

Выгоды хеширования данных обусловлены включением секционирования во все решения Teradata. Секционированный первичный индекс (partitioned primary index, PPI) позволяет разделять таблицы по интересующим столбцам. Наряду с этим он используется для равномерного распределения данных, локализации операций соединения данных, принадлежащих одному процессору AMP, и эффективного доступа к ним (если значения первичного ключа указаны в запросе).

Рис. 5. Распределение данных по AMP с использованием PPI

Значение первичного ключа строки определяет процессор AMP, которому она принадлежит, вне зависимости от того, секционирован ли первичный индекс. Но если первичный индекс таблицы определен как секционированный, строка вводится в нужную секцию дисковой памяти AMP. Порядок размещения строк в секции определяется их хеш-кодами (рис. 5). В обработке популярной секции, например, коммерческих данных текущей недели участвуют все имеющиеся в системе AMP.

Ограничения традиционных схем

Традиционные варианты размещения данных не обеспечивают сбалансированной рабочей нагрузки, имеют врожденные ограничения, ограничивающие доступность данных и перегружающие межузловые соединения. Секционирование по наборам данных ведет к снижению производительности — администратор баз данных должен «вручную» сгруппировать данные в наборы по мере их поступления в систему. С помощью секционирования по наборам данных можно достичь равномерного распределения данных, но невозможно сбалансировать рабочую нагрузку. Поскольку администратор распределяет по одному входному файлу за раз, самые свежие данные будут находиться в небольшом подмножестве файлов.

Обычно в информационном хранилище существенная часть обработки состоит в сравнении самых новых данных с более «старыми», поэтому множество пользователей одновременно пытаются получить доступ к свежим наборам данных. В системах MPP или в кластерах СУБД не может определить, находятся ли на одном узле подлежащие соединению строки двух таблиц, секционированных по наборам данных, поэтому любая операция соединения требует передачи огромных объемов данных по межузловому соединению, что приводит к снижению производительности системы.

Секционирование по диапазонам ключей отрицательно сказывается на равномерности распределения рабочей нагрузки. При традиционном секционировании по диапазонам ключей строки размещаются на диске в соответствии с ключами секционирования. Такое секционирование эффективно, если используется многократный доступ к базе данных с повторяющимися условиями: администратор может разделить таблицу на несколько коллекций строк, исходя из этих условий. Но секционирование по диапазонам ключей создает проблемы для параллельной базы данных и ее администратора.

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

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

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

Дополнительные преимущества логической адресации

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

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

Ответственность за данные

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

В других СУБД любой процесс может временно получить контроль над объектом, но блокировками должен управлять некий центральный процесс (чтобы гарантировать целостность данных). Однако при централизации механизма блокировки возникают две проблемы. Во-первых, стратегия блокировки сама по себе может стать узким местом, если блокировку нельзя отменить полностью. Во-вторых, задача, для решения которой нужно использовать строку, должна получить блокировку, а после завершения работы передать управление, обычно вместе со строкой, следующему процессу. Такой порядок действий приемлем в среде SMP, где имеются общие указатели памяти, но в данном случае быстро приведет к перегрузке межузлового соединения. Яркий тому пример — общие диски, которые не смогут обеспечить полноценной масштабируемости. Системы на их базе всегда будут использовать динамический алгоритм для определения того, какой экземпляр базы данных обращается к тем или иным строкам. Этот экземпляр может и не быть владельцем строки, управляющим ее блокировками. Узкие места неизбежно появятся в любой системе с мало-мальски серьезной нагрузкой.

Рис. 6. Локальная автономность позволяет каждому процессору AMP полностью контролировать данные

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

Интеллектуальное межузловое соединение

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

Рис. 7. Одна из двух половин сети BYNET для конфигурации Teradata с 64 узлами. Каждая пара узлов имеет несколько соединительных путей BYNET

Сеть BYNET, используемая в СУБД Teradata, является масштабируемой и коммутируемой (рис. 7), и СУБД пытается использовать как можно больше ее функциональных возможностей. Совместно с базой сеть BYNET доставляет сообщения, перемещает данные, собирает результаты и координирует работу AMP. Подобно тому как удаленная работа позволяет разгрузить транспортные артерии (поскольку освобождает сотрудников от необходимости постоянно ездить в офис и обратно), в СУБД минимизируется межузловой трафик за счет поощрения «домашней» обработки.

Принадлежность объектов процессорам AMP ограничивает блокировку рамками одного узла. Хеш-секционирование, которое поддерживает совместное размещение подлежащих соединению строк, уменьшает масштабы транспортировки данных с целью соединения. Все операции агрегирования сначала сводятся к наименьшему набору подсумм на локальном уровне (уровне AMP). И даже когда требуются услуги BYNET, использование динамических групп сокращает до минимума число обменивающихся сообщениями процессоров AMP. Управляемые BYNET семафоры обеспечивают упрощенную координацию параллельной обработки запроса по межузловому соединению. Оптимизатор запросов «знает» стоимость пересылки строк таблицы через BYNET и учитывает эти затраты в окончательном плане соединения.

Двухточечная схема

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

Транспортные средства общего назначения

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

Сохранение пропускной способности

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

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

Оптимизатор параллельных запросов

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

С ростом числа таблиц в запросе оптимизатор должен рассмотреть возрастающее число вариантов последовательности соединения

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

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

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

Одним из методов оптимизации является подход Using the AMP-to-CPU Ratio, при котором операции запроса, требующие интенсивной вычислительной нагрузки, выбираются как можно реже — лишь когда оптимизатор понимает, что на один AMP приходится недостаточно вычислительной мощности. При соединении путем перемножения таблиц СУБД объединяет каждую строку одной таблицы с каждой строкой другой. Это может потребовать множества операций сравнения и относительно больших ресурсов центрального процессора. Но оптимизатор СУБД Teradata реже выбирает соединение перемножением при наличии менее мощных процессоров или меньшего соотношения AMP/CPU.

Синхронизация параллельных операций

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

Координация при выполнении запроса. При обработке SQL-предложений СУБД разбивает запросы на независимые шаги. Они направляются по сети BYNET к AMP от одного из процессоров синтаксического разбора (Parsing Engine, PE) — по одному шагу за раз или сразу несколько шагов в случае внешнего параллелизма. Только когда шаг завершен всеми участвующими в нем процессорами AMP, им направляется следующий шаг. Это гарантирует, что все единицы параллелизма в базе данных выполняют одну и ту же часть работы в одно и то же время (рис. 8).

Рис. 8. Синхронное параллельное сканирование таблицы всеми процессорами AMP

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

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

Керри Болинджер (Carrie Ballinger) — старший консультант по технологиям в корпоративном центре Active Data Warehouse компании Teradata.