Это в основном стратегия, которую использует Teradata. У вас есть выделенный сервер обработки, памяти и хранилища, и данные распределяются по процессорам. Каждое устройство имеет свою собственную избыточность, так как данные не хранятся где-либо еще - если вы потеряете AMP, вы потеряете данные.
В Teradata магией, которая делает возможным разделение, является ПЕРВИЧНЫЙ ИНДЕКС. Это определяет, на каком AMP хранятся данные. Запрос распространяется на все AMP, и они возвращают данные, которые затем объединяются. Производительность снижается, когда наблюдается перекос, и данные должны быть перераспределены из AMP, где они находятся, в AMP, который нуждается в них для обработки.
Таким образом, система межпроцессного взаимодействия, процессор запросов и система хеширования являются ключевыми компонентами системы такого типа.
Во многих случаях массово-параллельный подход хорошо работает, когда данные совместно используют очень похожие первичные индексы (миллионы клиентов, миллионы счетов клиентов, миллионы событий потока кликов клиентов). Это отлично подходит для большого класса проблем, потому что вещи часто делятся на клиентов, или по дате, или что-то подобное.
Сбой, когда вы имеете дело с такими вещами, как звездные схемы в стиле Кимбалла или пытаетесь перемещаться по очень сложной модели 3NF в одном запросе. В этих случаях вам лучше создавать промежуточные временные или изменчивые таблицы и указывать первичный индекс, чтобы данные хорошо распределялись по AMP и сопоставлялись с тем, к чему вы собираетесь присоединиться при следующем соединении. Или переоборудовать свой склад.
В системах MPP добавление емкости включает добавление памяти, хранилища и обработки одновременно, что обеспечивает довольно хорошую масштабируемость.