Иииии? и как же это связано с распределенностью?
А то что данные даже 1 таблспейса(простите, для примера буду говорить про оракл, кажеться в остальных СУБД есть нечто похожее) могут лежать физически на разных винтах? И даже больше: данные одной таблицы могут лежать в разных таблспейсах(см partitioning concepts) ? При том, что никакой распределенности при этом не будет, а производительность даже при больших объемах данных будет ок.
Опять же: а при распределенной БД, будут возрастать накладные расходы на синхронизацию и сеть. Как обычно, палка - о двух концах.

представьте что у вас 1 винт, 2 блина и 4 магнитных головки,
как ваши задачи ни распараллеливай, получится только увеличить время
доступа по сравнению с последовательной выборкой

trop: ага. все верно. А теперь этот же вопрос Вам: 1 винт, 2 блина, 4 головки. Как поможет распределенность? ы?
И вдогонку: много ли Вы видели распределенных СУБД под сапом? Мне такое не попадалось. Я видел кластера, но не под erp.

Но даже в случае с 1 винтом, субд реализуют так, чтобы оптмизировать многопользовательский доступ. Различные кэши и прочая-прочая-прочая.

под юбку не заглядывал, но репликацию enterprise поддерживает и попадался часто.
пример: 100 таблиц рамером 1-10Гб ,каким образом помогут многопользвательский доступ и кэши?

trop: а на мой вопрос (ваше предложение в условиях вашей же задачи), значит, ответа не будет? Я так понимаю, его не будет по тому, что распределение БД(разнос по разным серверам) и хранение на разных винтах разных частей базы - по сути одно и то же. Только в случае "много винтов на одном сервере" накладных расходов меньше
Кэш субд обычно хранит наиболее часто использующуюся инфу, например: планы разбора, метаданные, данные таблиц. Т.е. ессесно в кэше будут часто используемые данные(вынос из кэша по алгоритму Low Reuse). Естественно, если читать все 100 таблиц страфигенного размера по full scan, то кэш не поможет. Но в условно усредненных условиях, с параллельным чтением с одного винта справляется и обычная персоналка.
До уровня винта есть много прослоек, давайте загибать пальцы: кэш сапа, кэш субд, кэш оси (не все и не всё помещают на raw device), кэш винта.
Вообще, это проблема уровня базиса. Как разработчик, я знаю, что при нормально настроенном базисе и адекватной задаче, распараллеливание повышает производительность. Лучше всего повышает в части ввода данных(личный опыт: параллельный ввод сд заказов в большом объеме). Хуже - в части выборки данных.

как много букв.. как мёртвому припарка, если у ТС была imdb, то распараллеливание бы спасло ,вы мои сомнения не развеяли.
вы же не предлагаете ему днём запускать параллельные задачи, потому что если встанет продуктивная система
из-за его задач его найдут и накажут (запускать свои странные расчёты ночью).
предлагаю ТС отписаться насколько ускорилось выполнение задачи.

trop: ну раз ответа не будет, то ок
По поводу задачи ТС я уже выше излагал: щастья ему особого от распараллеливания не будет. В задаче ему надо читать все таблицы базы по full scan фактически. "не, не взлетит"(С). Постановка из разряда "ну и запросики у вас, сказала БД и повисла"

Кстати, а "imdb", это что такое?