Зл0йТерминология в Teradata - отдельная "песня". Все называется "никак у людей". Зачем придумывать свои термины когда есть общепризнанные мне непонятно.

Похоже, что многие общепризнанные термины появляются после того, как они появляются в Терадате. Всё-таки, Терадата - пионер в области СУБД для хранилищ данных.


contrЗачем пишем? И какое отношение это имеет к перераспределению данных с целью выполенния запроса?

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

andrey_anonymousИМХО да, должен существовать узел, на котором они пройдут процедуру merge. Будет это один из "рабочих" узлов или специализированный - неважно.

Хотел бы ещё раз поддержать Олега - Терадате не требуется отдельный узел для операции merge, которая, естественно, значительно дешевле сортировки.

contrПочти.
Если не рассматривать параллельные операции.
Но замнем для ясности изложения.

Хотелось бы именно внести ясность. Возникает впечатление, что Вы сомневаетесь в том, что merge дешевле.

Назовите другую СУБД, которая умеет распараллеливать сортировку тогда сможем сравнивать.
contrКак Вы уже, несомненно, догадались, я назову oracle :)

Кстати, Вас не затруднит закинуть сюда план параллельного выполнения запроса Oracle с сортировкой не по полю, по которому сделан partitioning?
Интересно было бы посмотреть.
Равно как и планы запросов для случаев раз, два, три, рассматриваемых выше.
В отместку, т.е. в ответ, я хотел сказать :) готов запостить планы Терадаты.

contrХм... Ora как бы тоже обеспечивает, но при этом может отследитьситуации, когда parallel невыгоден и отказаться от него.
Потенциальный + оракелю и минус террадате.

Ну, Терадата, скажем, тоже умеет так. Например,

Выполнится, в общем случае, за одно чтение с диска.

Назовите другую СУБД, которая так сумеет. Подозреваю, что сначала почитается индекс, а потом данные. В Терадате же первичный индекс - это не индекс, а функция.

contr- ситуация свидетельстует об ошибке в дизайне хранилища, тоже симметрично для TD и Ora

На все случаи не надизайнишь. На то она и СУБД хранилища, чтобы уметь запросы Ad Hoc выполнять эффективно, для которых, возможно, дизайн не очень удобен.

contrВ данном случае Вы жестоко передергиваете. Готов обсуждать приватно, но в форуме реакция одна ЛОЖЬ.

Хотелось бы опять-таки поддержать коллегу. Зачем же так резко?
Я, пожалуй, соглашусь, что архитектура shared nothing по масштабируемости превосходит shared disk, потому как у последней существуют неизбежные накладные расходы на координацию доступа к расшаренному ресурсу, которые отсутствуют в shared nothing.

contrНадо-надо, рассматривайте плиз ВСЕ кейсы.
Например?

contrА технологии джойнов в Ora изначально разрабатывались исходя из требований параллельного выполнения и возможности работы с shared disk архитектурой

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

contrОракелю тут НЕ НУЖЕН интерконнект. Имелся ввиду кэш стораджа.
Интересно, с какой скоростью будет выметаться пресловутый кэш на терабайтных объёмах данных с несколькими сотнями пользователей, параллельно выполняющими запросы по таблицам с сотнями миллионов записей?
Всё конечно здорово, только кэш в хранилищах данных - далеко не панацея. К тому же, дорого это. Там пока диски правят и, наверное, долго ещё будут править. Поэтому скорость работы с большими объёмами данных зависит от оптимальной (параллельной) работы с дисками.
Хотя, время покажет. Может, через лет восемь-десять Оракл догонит по производительности Терадату :)

С уважением,
Константин Лисянский
http://lissianski.narod.ru