Т.Е. однозначно для баз более терабайта нужна 64 разрядная платформа, Или про нормальную производительность можно забыть.


Чепуха это батенька.

Приезжайте к нам в соседний Арканзас, там ХД у компании Вол-Март за сотню терабайт прекрасно работает в 32-разрядной архитектуре.

Немного за жизнь. Объем памяти в интелловском серваке от NCR скажем 4 ГБ max. К примеру кластер состоит из 14 узлов. 14Х4=56 ГБ на систему. Объем данных у меня в базе порядка 1 Терабайта. Данные лежат в 3-й нормальной форме и есть несколько десятков больших таблиц каждая из которых может быть порядка 20-30 ГБ. О каком кэше можно говорить когда пользователи выполняют в среднем 10000-15000 DSS запросов в день, объединяя большие таблицы,
используя самые различные условия выборки, выгружая большие объемы данных для построения многомерных кубов PowerPlay и тулзов по визуализации данных. Количество пользователей в ХД около 1000, данные собираются со всех 26 казино компании. Вся производительность на уровне железа определятся кол-вом узлов в системе, скоростью CPU в этих узлах и скоростью дисковой подсистемы (EMC Symmetrix). Оптимизация индексами, приоритеты и пр. это уже отдельные
приблуды.

Кэш конечно же хорош для OLTP запросов и приложений, но не всегда
полезен в терабайтных ХД с большим кол-ом пользователей и самое главное
с неограниченными возможностями строить любые запросы при помощи тулзов типа Cognos или Business Objects конечными пользователями.

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

По поводу Оракла RAC есть ряд вопросов. Насколько его тяжело администрить в многоузловом кластере? Если это 20 узлов, означает ли это что у меня есть 20 инстансов Оракла на каждом узле? Нужно ли создовать dbspace'ы, tablespace'ы, добавлять дисквое пространство, по необходимости, делать реорги, перестраивать индексы и т.п. Скажем в Информиксе и DB2 (версии для OLTP систем) это приходится делать постоянно. В Терадате всего этого нет в принципе. Сущность CУБД одна в независимости от кол-ва узлов.

Насколько хорошо RAC может обрабатывать 20-50 одновременных тяжелых запросов пользователей? Можно ли при этом подгружать данные в хранилище? Данные могут быть в 3 НФ или же это должна быть многомерная
структура? Какие ограничения на ко-во узлов в кластере RAC?

Вопрос сложности администрирования совсем не праздный скажем в Штатах, где хороший DBA получает 80-100K в год и менеджмент учитывает сколько DBA'ев требуется в отдел для поддержки той или иной системы.