Действительно ли о модели разработки MapReduce можно говорить лишь в контексте нереляционных хранилищ данных?
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Всем привет!
Я хотела бы узнать мнение сообщества DOU, действительно ли правильно относить применение термина MapReduce только к нереляционному миру. Такой вопрос мне пришел в голову после прослушивания одной презентации на тему нереляционных хранилищ данных.
Какой-то время назад я читала о том, что в некоторых реляционных базах данных есть так называемые пользовательские агрегационные функции (user-defined aggregate functions), как, например, в Oracle. Вот, вообщем-то, мне и стало интересно окунутся в эту тему на столько, на сколько позволяли мои познания и свободное время. Поэтому прошу, если кто-либо со мной в чем-либо не согласен, не стеснятся оставлять свои конструктивные комментарии под текстом статьи, так как мне было бы интересно добраться до истины вместе с вами.
Перед тем, как начать, я оговорюсь, что не собираюсь сравнивать нереляционные и реляционные хранилища данных, так как мне кажется каждое из этих решений направленно на решение своих задач, и поэтому поводу уже написан интересный труд Gaurav Vaish — Getting Started with NoSQL, в котором автор попытался раскрыть области (на сколько хорошо, хотела бы тоже услышать по этому поводу конструктивные комментарии), в которых оправдано/неоправданно применение обоих решений. Книга по размеру небольшая и написана легко. На протяжении всей книги автор, как мне показалось, уделял максимум внимания конкретики, поэтому воды скорей всего в ней не заметите.
Ну начну с того, что когда я разобралась с этой темой, то пришла к выводу, что пользовательские агрегационные функции (user-defined aggregate functions) ничто иное, как реализация MapReduce модели. Почему? Давайте попробуем в этом вместе разобраться.
Рассмотрим кластерную архитектуру как для нереляционного решения на базе MongoDB, так и для реляционного на базе БД Oracle 9i+. Рассматривать я буду по документациям и статьям которые прочла (буду в своей статье делать ссылки, где только это будет возможно и уместно), так как сама не пробовала разворачивать боевое окружение ни для первого ни для второго случая. Поэтому решила написать статью, чтоб встретить в комментариях людей с реальным опытом и конструктивной критикой.
Как наверное многим ’в теме’ известно, что модель разработки MapReduce направленна, в первую очередь, на решение задач, связанных с вычислениями над огромными массивами данных (об этом для ознакомления можно прочитать на MapReduce). Основывается это решение на модели распределённых вычислений, где MapReduce задача отправляется на узел, где находятся данные, выполняет операцию на узле над данными, и промежуточный результат возвращает прокси узлу (тот узел, через который приложение взаимодействует с кластером), который уже отвечает за то, чтоб из промежуточных результатов, собранный от узлов с данными, собрать финальный результат и отправить приложению (можно сказать агрегация данных в распределенном окружении).
Реализуется это решение за счет того, что изначально существует архитектура, например, на базе кластера, которая позволяет разделять данные между узлами в более-менее равных пропорциях (в MongoDB это сделано с помощью механизма shard key: sharding-shard-key, в БД Oracle 9i+ с помощью cluster key: docs.oracle.com/...0/tablecls.htm#CNCPT88828, и, на сколько я понимаю, по этим ключам вычисляется хеш-код, с помощью которого можно однозначно определить место положения данных. О возможном варианте реализации процесса поиска места положения данных по хешу хорошо написано в этой статье: distributed-hash-tables-and-consistent-hashing), чтоб в дальнейшем иметь возможность запускать распределенные вычисления на разных физических/логических узлах (под логическим узлом я имею ввиду — одна физическая машина, но с несколькими запущенными узлами на ней). О достоинствах и недостатках хранения данных на физических и/или логических узлах говорить не буду, так как это не совпадает с целью статьи, собственно, как и о возможных решениях отказоустойчивости и масштабируемости.
Итак, вернёмся к нашим баранам. Решение на базе БД Oracle 9i+ исходя из документации я попыталась выразить следующей задачей для более легкого восприятия процесса: есть входящий набор данных в виде облака с различными объектами инфраструктуры внутри, и поставим задачу — подсчитать количество объектов, относящиеся к каждой инфраструктуре. Графически реализация этой задачи будет выглядеть следующим образом:
Решение этой же задачи для нереляционной БД (в нашем примере — MongoDB, хотя, собственно, не имеет значения...) графически выглядит следующим образом:
Добавлю, что задачу я намеренно выбрала наиболее простую и решение также, чтоб обратить внимание читателей на схожесть и разницу в реализациях. В настоящем же приложении для MapReduce скорей всего будет использоваться связка: Input Values -> Splitting -> Mapping -> Shuffling -> Reducing -> Final Result, как хорошо показано здесь: xiaochongzhang.me/blog/?p=338.
Вывод: из двух графических представлений видно, что и user-defined aggregate functions и MapReduce на диаграммах ведут себя схоже в распределенной среде (Oracle БД также построена на кластере), но процессы называются разными именами.
Интересный факт: после серфинга различных ресурсов я нашла, что упоминание и описание процедуры распределенного вычисления для Oracle БД вышла раньше, чем для MapReduce.
Описание API пользовательских агрегационные функций (user-defined aggregate functions) для БД Oracle 9i+ вышла в Сентябре, 2003, и была описана Adrian Billington (ссылка здесь: www.oracle-developer.net/display.php?id=215), в то время, как Google в лице Mark C. Chu-Carroll описал это решение в 2004 году (ссылка здесь: searchcloudcomputing.techtarget.com/definition/MapReduce)
Спасибо за внимание, и жду от вас конструктивных комментариев и, главное, дополнений.
106 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів