Зл0йДля начала Терадата: Все очень просто. Предположим что есть 2 таблицы table_a и table_b. Предположим что первичные индексы данных таблиц построены по атрибутам column_a1 и column_b1 соответственно. Теперь строим Join такой что column_a1=column_b27. Доступ в table_b идет не по первичному индексу. т.е. amp'у прочитавшему страницу данных из таблицы table_a придется данные для таблицы table_b собирать со всех amp'ов системы через Bynet. Ведь они же раскиданы по amp'ам исходя из хеширования по column_b1. Теперь предположим что обе таблицы по 200 миллионов записей, чтобы жизнь медом не казалась. Все. Приплыли.

Хм, а "Приплыли" что означает? Будет выбрана стратегия реализации join (в данном случае скорее всего будет merge join, через redistribute), узким местом которой является суммарное IO узлов (у терадаты все стратегии join кроме одной упираются в IO узлов). То есть, при добавлении узлов скорость выполнения запроса будет расти линейно, от кол-ва узлов. Для не индексированных таблиц. Ну это у всех так, в том числе наверное и у Oracle, в случае shared-nothing конфигураций. Где же затык терадаты?

Зл0йКогда все узлы начинают дружно слать друг другу по Bynet'у записи то затык происходит в пропускной способности Bynet'а, которая безусловно велика но небезгранична. Суммарная пропускная способность узлов по IO выше на порядок чем Bynet'а собственно (120MB per second per node bandwidth). Предположим узлов 40, на каждом из них висит NCR'овский сказевый дисковый массив. Какова их суммарная пропускная способность по IO 40 SCSI каналов?

Насчет линейно растущей скорости это вы в рекламном проспекте NCR прочитали? Она линейно растет только в случае AMP-local join. Teradata вообще-то не единственная СУБД MPP-архитектуры. У них у всех при Table Redistribution происходит утыкание в пропускную способность интерконнекта.

Shared-nothing конфигурация Оракла - для меня нечто новое. Ни разу не видел. Я даже сомневаюсь что Оракл сам по себе поддерживает такую конфигурацию. С помощью "надстройки" над ним наверное shared-nothing сделать можно, как и с любой СУБД. Вот DB2 EEE, Informix XPS и Tandem такую конфигурацию поддерживают, это точно.

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

1) Пропускная способность Bynet в актуальной версии - 180Mb в секунду на узел. Если рассмотреть Ваш пример на двухузловой системе, каждый узел может разослать не больше 100 млн. записей, а на самом деле меньше (только чужие строки). Если предположить что разослать нужно 70млн, размер строки 100 байт с overhead то нужно разослать 7Гб. 40 секунд. Читать он их будет дольше, и не нужно ссылаться на показатели интерфейсов, блоки со строками в терадате рассыпаны в случайном порядке, это не потоковое видео.
Хотя конечно можно сконфигурировать такую систему что она заткнет байнет. Именно для этого конфигурациями занимаются люди из терадаты.

2) Даже если предположить что в качестве среды передачи данных для Bynet будет использоваться 10Mbit/s Ethernet система будет масштабироваться линейно. Если вдвое увеличить систему то на каждый амп и узел данных будет приходится вдвое меньше, и чтобы их переслать времени нужно вдвое меньше (вспомните, что байнет это иерархическая топология и она не заткнется, как общая шина, просто от кол-ва пакетов). Отсюда и масштабируемость на таких задачах, свойственная shared-nothing.

3) В документации по Oracle написано что RAC работает на shared nothing: Data Warehousing Guide 10g Release 1 (10.1)
Page 5-28

Не удержался: коллеги работающие с Oracle, вопрос был как (какой тип join, как разводится по узлам) и сколько времени в этой СУБД будет выполнятся следующий join:
Зл0йДля начала Терадата: Все очень просто. Предположим что есть 2 таблицы table_a и table_b. Предположим что первичные индексы данных таблиц построены по атрибутам column_a1 и column_b1 соответственно. Теперь строим Join такой что column_a1=column_b27.
То есть, по column_a1 и column_b1 сделан hash-partitioning (первичный индекс в терадате это первичный метод доступа). Join по условию column_a1=column_b27. Индексов нет, таблицы по 200mln rows.