Был потрясен обилием ответов :)

Константин ЛисянскийНо, на самом деле, межузловой трафик - это тоже не страшно. Он есть постоянно, поскольку джойны очень часто требуют перераспределения данных между узлами. На это существует коммутатор с очень приличной пропускной способностью.Отсюда вопрос. А какое железо нужно Терадате? Могу ли я построить эту систему из кучи старых писюков с Pentium 1 на борту и ОС Windows? (утрирую) Либо нужно обязательно покупать сервера специальной архитектуры и специальные коммутаторы?

Константин Лисянский BirkhoffИ кто подает сигнал, что все таблицы обновились, можно снимать блокировку?Lock Manager А где он находится? На сервере с PE? Или еще где то?

Константин Лисянский BirkhoffНу когда таблица создается ведь указывается какой тип партишининга и по какому полю. Соответственно каждая партиция фактически представляет из себя отдельную таблицу (к которой даже можно принудительно обратиться), а оптимизатор просто вычисляет в каких их этих таблиц лежат наши данные.Интересно, а если часть таблиц с партициями, а часть - без. Как при этом джойны выполняются?
А если у разных таблиц разный партишионинг? А какая разница? Партишионинг просто задает количество таблиц и распределение данных по ним. Оптимизатор переписывает запрос таким образом, что обеспечивает доступ ко всем нужным партициям. Тип партиций и вообще их наличие и в каких таблицах роли не играет. Это влияет только на структуру перписанного запроса.

Константин Лисянский BirkhoffЭтим всем в основном администратор управляет. Автоматом мало что делается. Но честно говоря не вижу тут большой проблемы.Ну, если речь идёт о сотняз или тысячах объектов, за каждым из которых нужно следить, то желательно поменьше действий в расчёте на один объект выполнять. В противном случае администрирование в кошмар превращается.

И если речь идёт о терабайтных системах, то лишний раз данные перезагружать - тысячу раз подумаешь.А зачем их перезагружать? Разбиение таблиц по партициям это архитектурное решение, когда строится система, тогда и принимается решение как партиционировать таблицы. Потом можно, например, если у нас данные лежат по годам, добавить еще одну партицию, чтобы в нее падали данные за следующий год. То есть, это делается очень редко. Ну а от архитектурных ошибок никто не застрахован, если надо изменить схему партиционирования - то обычно делается это один раз. Иначе какой смысл? Просто в Oracle и в Teradata как мы выяснили партиции имеют разный физический и логический смысл, поэтому если для Терадаты важно динамическое перераспределение партиций на разных серверах, то для Oracle это вообще нонсенс. Может быть меня кто-то тут поправит, но мне это так видится.

Константин Лисянский BirkhoffИмхо, какая-то надуманная проблемаДа. нет. Выход из строя RAID-массива вполне вероятная вещь. Хорошо, не бомба. Дрогнула рука техника - вместо вышедшего из строя диска выдернул соседний из этой же линейки. Да, мало ли что ещё может произойти...Ну ладно, хорошо что такая фича в Терадате есть. Лишние возможности для повышения надежности никому не мешают. Но все-таки она все равно имеет смысл в архитектуре Терадаты и особого смысла не имеет в Оракле. К тому же действительно большие системы на Оракле обычно не полагаются только на средства самого Оракла. Чаще всего туда встраиваются системы для бекапирования и аварийного восстановления как на уровне железа, так и, например, от других производителей ПО типа Veritas. Но в этой области я уже не шибко разбираюсь, поэтому не буду глубоко зарываться. Если есть спецы среди тех, кто это читает, надеюсь меня поправят, если что не так :)

Константин Лисянский BirkhoffНо если бобма в здание попала с сервером, то и тут есть разные технологии типа Data Guard, которые позволяют практически в реальном времени создавать дубль базы на дургом сервере и в случае полного уничтожения основного сервера - поднять резервный. Видимо что то похожее на Dual Active.Ну, не совсем. Если в случае Data Guard нужно резервный сервер поднимать, то в случае Dual Active он постоянно работает и приносит пользу.Опять же это имеет смысл в архитектуре Терадаты. Ну и потом, все зависит от того, сколько времени нужно на подъем резервной базы. Если несколько минут терпит (что в DWH обычно так), то за несколько минут сервер можно поставить в боевой режим.

Константин ЛисянскийКонечно, нет, но индексов нужно больше. А это - больше дискового пространства, больше администрирования.
В целом работает правило, что Терадата требует меньше дискового простанства чем любая другая СУБД (кроме, пожалуй, Sybase IQ, который в этом плане делает всех :)В наше-то время, когда у некоторых дома на компе терабайт диского пространства, экономить на месте на диске для индексов? :)

Константин ЛисянскийЕсть запрос на выборку по полю, не являющемуся первичным индексом (по полу, например). В этом случае все 100 устройств параллелизма будут сканировать свою часть таблицы, сотоящую из 10 тыс. записей. Это вполне предсказуемая нагрузка. Ясно, что, поскольку наши записи перемешаны в случайном порядке, количество записей с мужским или женским полом будет примерно одинаковым на каждом устройстве параллелизма.

Имеет это какой-то смысл или я слишком увлёкся?
Ну я могу допустить, что М и Ж распределены примерно равномерно, но другие данные, например типы проданной продукции по регионам могут довольно сильно различаться от партиции к партиции.

Константин ЛисянскийПо поводу COUNT DISTINCT.
Допустим, есть таблица заказов:
order_id, order_date, customer_id, product_id, amount

Вполне логично допустить, что первичным индексом будет order_id для равномерного распределения таблицы по дискам.
Теперь надо вычислить сколько уникальных клиентов сделали заказы в течение года.

SELECT count(DISTINCT customer_id) FROM orders;

Как посчитать параллельно?
Первое соображение - в силу хэширования потенциально на каждом диске имеются записи содержащие все значения customer_id.

Давайте первым шагом перераспределим данные между узлами по столбцу customer_id.Вот этот шаг я не понял - а все остальные понятны :)
У нас же данные отхешированы по order_id? Я понимаю, если бы мы Distinct count считали по order_id - это было бы элементарно, так как на других узлах значения не повторяется и весь запрос сводится к обычному count.
А что значит "перераспределим данные между узлами по столбцу customer_id"?

2 Константин

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

Константин ЛисянскийДругой вариант - сначала перераспределить данные по группируемому (групиируемым, если их много) столбцу, а вторым этапом сделать все параллельно.Вот я так и не понимаю, чтоже кроется за словом "перераспределение"?
Что значит данные перераспределяются? Раньше писалось, что они как-бы даже перераспределяются между узлами?

Константин ЛисянскийК вопросу о трафике и о коммутаторе BYNET.
Эта информация уже немного устарела в части цифр, но основные моменты сохранились:

The Teradata BYNET interconnect differs from other communication technology on the market (Ethernet, for example) by moving data from one location to another on the network. The network bandwidth is a function only of the equipment purchased.

A gigabyte Ethernet can move 1 GB regardless of how many computers are attached to it: More computers mean more contention and slower performance for all on the network. The BYNET works like a phone switch, quite different from the typical network. Its switched "folded banyan" architecture delivers additional network bandwidth for each node added to the configuration. Each connection to a node delivers 120 MB/sec. A 2-node system has a 240 MB/sec. interconnect; 4 nodes, 480 MB/sec.; 8 nodes, 960 MB/sec.; 100 nodes, 12 GB/sec. The current BYNET implementation can support up to 512 nodes (1 to 4 PB,) but the design is capable of 4,096 nodes (8 to 32 PB) if a customer is ready to solve a problem of that magnitude.Чудеса какие-то :)
Из этой статьи правда совершенно не ясно, как этот "баньян" обеспечивает такую гигантскую пропускную споосбность? Или здесь просто суммируются 120 MB/sec каждых двух взаимных соединений? Если так, тогда это ничего не гарантирует....

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