у db2 "предел" 1024 ноды
купите больше лицензий - вам забесплатно скомпиляют скоко надо

а супер-вера в кластера с возрастом проходит

sysprgНасколько я знаю, DB2 использует "sharing nothing" архитектуру, когда никакие данные не разделяются между нодами, соответственно каждый запрос отправляется для обработки на каждую из нод кластера, а ответы объединяются - у каждой ноды часть данных и только все они вместе могут выполнить нетривиальный запрос.
Получается, что работы на каждую ноду приходится меньше (так как данных каждой ноде приходится обрабатывать меньше - они ведь раскиданы по тысячам нод). Но так или иначе каждая нода вовлечена в любой поисковый запрос.
Если я правильно понял описание архитектуры IBM и это так, то подобное решение не всегда подходит - если, скажем, у меня миллион запросов в секунду, то мне не так страшно (может быть), что у меня большие выборки за этими запросами (они могут быть маленькими!) , сколько страшно то, что я не хочу каждую ноду грузить обработкой всех запросов (миллиона штук в секунду).
А до начала выполнения запроса заранее еще не ясно, где именно лежат нужные (штучные) страницы данных, затронутых этим запросом - поэтому в sharing nothing архитектуре запрос транслируют на все ноды (на всякий случай).
Или это не так в DB2?
В целом так, но не совсем.
Да, правильное партиционирование - ключ к высокой производительности. Цель - избавится от межнодового обмена и повысить паралельность.

Да, любое партиционирование не сможет удовлетворить 100% запросов, так что придется выбирать те, ускорение которых критично, наиболее важно.

Нет, не все запросы будут раскидыватся по всем нодам - если данные запроса на ноде, к которой присоеденен клиент, то запрос выполняется только локально. Отсюда два следствия - первое, если это "большой" запрос, ну например, с агрегирующими функциями, и т.д, то он будет будет выполнятся медленнее, чем если бы данные были на разных узлах и зпрос выполнялся на всех, и второе - если запрос "мелкий", ну там insert/update/delete одной строки, то он явно будет выполнен быстрее в случае, если эти строки на ноде, куда мы присоеденились.

Есть функция DB2PARTNUM или что-то типа того, которая возвращает номер норды по переданному ей ключу партиционирования. Используя ее можно построить "маршрутизатор" (где-то валялся такой для java) запросов, не требующих распаралеливания. Ну, в принципе, этого достаточно для написания приложения, в котором запросы, требующие обработки больших массивов данных будут выполнятся на всех нодах, а не требующие - на одной.
Но можно сделать и более красиво, на основе SOA. Тогда собственно база будет всего лишь сервис, к которому обращаются потребители, а ESB будет маршрутизатором запросов.
Длительность выполнения отдельно взятого запроса увеличится (все-таки промежуточные уровни появятся), но пропускная способность всей системы вырастет.
И еще - на текущий момент нет такой реальной потребительской задачи, которая не может быть выполнена в рамках одного SMP сервера топ-класса.
Гипотетические "а вот если..." не являются реальной задачей.

точно - писали, я тоже читал :)