Молодежи свойственно увлекаться новыми идеями.
Молодежи свойственно увлекаться новыми идеями. Идея MapReduce, выдвинутая и реализованная сначала Google, а потом и сообществом open source в проекте Hadoop почти мгновенно овладела молодыми массами. Причем даже теми представителями компьютерной молодежи, которые получили хорошее образование и последующий практический опыт в области систем управления базами данных. Мне неоднократно приходилось слышать от молодых коллег, что они считают достоинствами MapReduce отсутствие схемы данных (в том числе, и отсутствие поддержки типов данных) и даже потребность в явном программировании конструкций, которые испокон веков поддерживались в СУБД на уровне высокоуровневых языковых конструкций языка SQL. Понятно, что дополнительным стимулом к применению MapReduce была привязка этой технологии к «облачным» вычислениям, возможность практически бесплатно арендовать виртуальный кластер с большим числом узлов и развернуть на нем свою MapReduce программу, почти автоматически достигнув громадной производительности своего приложения.
До поры до времени представители старшего и среднего поколений сообщества баз данных ограничивались ворчанием в адрес MapReduce, что, в свою очередь, еще больше привлекало молодежь к использованию соответствующих средств. Действительно, раз «старики» ворчат, значит, они просто не понимают, что средства управления данными их поколений просто устарели, и нужно переходить к использованию новых, прогрессивных технологий.
И вот, наконец, ворчание стариков (а больше других ворчали Майкл Стоунбрейкер и Дэвид Девитт) выразилось в инициировании ими чрезвычайно интересного проекта по практическому сравнению технологии MapReduce с технологиями параллельных СУБД категории sharing nothing. Результатам этого проекта и посвящается статья, пересказ которой предлагается вашему вниманию.
Как мне кажется, статья написана предельно объективно. В ней подчеркивается ряд достоинств MapReduce. Некоторые из них кажутся мне сомнительными (например, то, что написание явного кода приложений оказывается проще использования функционально эквивалентных конструкций SQL), но это уже вопросы вкуса. Но основной итог статьи состоит в том, что на простых аналитических задачах параллельные СУБД просто кладут на лопатки Hadoop. И авторы показывают, что здесь дело совсем не в убогости этой реализации (хотя и отмечаются пути ее совершенствования), а в архитектурных недостатках MapReduce.
Финал статьи написан очень мирно, типа «ребята, давайте жить дружно». Другими словами, не отрицайте достижений технологии баз данных, а старайтесь использовать эти достижения в новых технологиях. А сообщество баз данных постарается, в свою очередь, перенять те аспекты технологии MapReduce, которых не достает в современных СУБД.
Статья информативна и увлекательна. Желаю вам приятного чтения.
Сергей Кузнецов
