По службе мне приходится администрить Teradata, DB2 UDB и Informix IDS в одном из американских казино. Teradata у нас используется как основной движок для ХД. Пользователи, а их порядка 1500, кидают запросы различной сложности посредством Cognos. Что могу сказать по поводу Teradata. Реляционная СУБД, поддерживает все основные стандарты SQL, ODBC т.д., отлично масштабируется, начиная с пары сотен гиг и заканчивая сотнями терабайт (пример Wal Mart и SBC Communications). Падает редко. За 4 года работы у нас был всего лишь один серьезный сбой вызванный неполадками со железом. Если и приходится перегружать сервер, то лишь при серьезных апдейтах версий. Иной раз бывало отваливался один из SMP узлов в кластере, в течении 5-7 минут Teradata рестартовала на оставшихся 5 узлах и система снова была в онлайне. В качестве диск сторадж мы используем EMC Symmetrix. Система доступна пользователям в режиме 24/7/365, включая то время когда работают процессы по подгрузке/обновлению данных, а также бэкапы и collect statistics. Teradata очень легко администрить. Т.к. для распределения данных на диске используется хэш-партишонинг, нет необходимости перестраивать индексы. В Informix приходится это делать регулярно. Оговорюсь правда, что это древняя 7-я версия Informix'a.
Хранилище данных на Teradata у нас в компании используется не только для т.н. "тяжелых" SQL запросов, но и для оперативных запросов пользователей выполняющихся с секундным временем ответа. В терминолгии NCR это звучит как ADW - active datawarehosing. В Терадата есть механизмы позволяющие регулировать распределение ресурсов ЦПУ и диска в зависимости от типа пользователя выполняющего тот или иной запрос. Что аналогично DB2 Governor. Кроме того имеются возможнсти ограничивать количество одновременно выполняемых запросов того или иного типа. Если время выполнения запроса не критично, а установленная квота уже выбрана, то запрос откладывается и выполняется позднее. Вся эта фигня используется когда ХД используется в одном флаконе как для DSS, так и для OLTP задач. В силу своей параллельной MPP архитектуры Терадата отлично выполняет full table scans. В этом сила брат. :-) Но кроме того есть возможности строить т.н. join индексы, пре-джойня большие таблицы под определенные запросы пользователей. Есть возможности стоить т.н. PPI - partitioned primary index. Полезно когда запрос читает данные за какой-то период времени по месяцам, кварталам. Ну и наконец, когда нужно достать данные по значению поля используемого для hash-partitioning запрос выполняется моментально, в силу того, что Teradata уже знает на каком узле параллелизма/диске лежит запись. Teradata работает на интеловской архитектуре, на железе от NCR, Dell и Компак. OC - NCR Unix MP-RAS либо ЭнТя. По последним слухам вроде как будет версия по Линух.

Про цену. Дорого. Даже в штатах клиенты Teradata это как правило компании Fortune 500, для которых потратить "мильон" на базу данных не проблема. По поводу TPC бенчмарков и прочих сравнений. Сугобо ИМХО. Мужики не парьтесь - все эти игры от лукавого. Каждый вендор загнет их под себя как ему надо, навешает лапшу на уши менеджерам, а DBA потом мучается и по ночам пейджеры звонят.

Объем ХД порядка 800Гб. В среднем в день выполняется порядка 4500-5000 DSS запросов и ~50000 "быстрых" OLTP запросов. Администрировать конечно же приходится, но скорее на предмет анализа производитльности различных запросов пользователей, capacity planning и т.п.

Самая большая таблица в хранилище чуть больше 1 миллиарда записей. Грубо говоря когда чувак приходит в казино, вставляет свою карточку игрока в определенную слот-машину и играет, в хранилище появляется запись о том сколько времени он играл, сколько проиграл/выиграл, на сколько сорвал джекпот и т.п. Меньшие таблицы имеют порядка 400-500 миллионов записей.

To Зл0й

Я согласен на все 100, что глюков везде хватает. Как правило месяца через 2-3 после выхода нового релиза будь то Teradata или DB2 появляется многостраничный документ с описанием найденных bugs. У меня даже закрадывается мысль, а не пихают ли разработчики СУБД сознательно энное кол-во жуков в код, что-бы потом их "устранять" и на большие бабки клиентов раскручивать засчет maintenance fees, minor release updates и т.п. Проблем также добавляет Cognos, который зачастую генерит отвратительный SQL. В идеале люди ответственные за разработу и поддержку каталогов должны неплохо разбираться в СУБД, но это не всегда соответствует жизненным реалиям. Честно говоря я не видел, чтобы плохой SQL убивал-бы Teradata и выливался бы в ре-старт. Иногда бывает что парсинг энджин сблеванет на плохой сиквел и база делает т.н. snapshot dump. Но это не рассматривается как outage т.к. все в онлайне, скорее это сигнал - hey this SQL is causing problems. В этом случае Teradata автоматически подгружает крэш-дамп в Калифорнию, а там умельцы из тех-сапорта извлекают SQL и имя юзера.

По вопросу MPP v.s. SMP. Как можно делать ХД терабайт эдак на 100 в SMP архитектуре? Было бы просто интересно посмотреть на эту систему. В том же DB2 версия EEE позиционируется как база для ХД в кластерной MPP архитектуре. У информикса есть или была аналогичная версия XPS. Про Оракл не скажу, поскольку ничего про него не знаю.

Priority Scheduler в Терадате штука хорошая, но она служит скорее не для "борьбы" с плохим SQL, а для оптимального управления загрузкой хранилища. Тобишь когда надо дать одному парню раза в четыре больше CPU чем другому. Priority Scheduler бывет особенно полезен, когда тяжелые запросы должны сочетаться с оперативными запросами, требующими быстрого времени ответа системы.