Операцию group by можно было бы с успехом считать операцией «партиционирования» таблицы в соответствии со значениями заданного столбца группировки, а после этого можно было бы легко обрабатывать полученные группы параллельно. Можно считать, что функция map в программе MapReduce — это обобщенный оператор group by, обеспечивающий разделение исходных данных по некоторым явно запрограммированным пользователем правилам. Функцию reduce можно считать обобщением агрегатной функции в SQL. Получается, что аналитик при написании новой аналитической функции не обязан выходить за пределы того набора понятий, к которому он привык, работая с традиционной аналитической СУБД.
Создается впечатление, что поддержка MapReduce внутри параллельной аналитической СУБД должна полностью удовлетворить потребности аналитиков, а будущие аналитические приложения станут серверными, выполняемыми параллельно поблизости от своих данных. Все это означает, что может быть обеспечена горизонтальная масштабируемость будущих аналитических систем и тем самым решена и проблема Больших Данных. Однако здесь хочется сделать крамольное замечание. Фактически в новом поколении аналитических параллельных СУБД обеспечивается возможность параллельного программирования аналитических приложений, которое проще и понятней для неподготовленных специалистов. То есть частично решается более общая проблема — проблема параллельного программирования для суперкомпьютеров. Возникает вопрос, а не заслуживает ли этот подход более широкого применения, нежели расширение аналитического параллельного сервера баз данных? Не стоит ли попытаться применять MapReduce для программирования параллельных задач обработки больших объемов данных? Действительно, Большие Данные бессмысленны без больших вычислений, а большие вычисления чаще всего невозможны без поддержки эффективного доступа к Большим Данным. Не стоит ли об этом задуматься?