Чи справді про модель розробки MapReduce можна говорити лише в контексті нереляційних сховищ даних?

Всім привіт !

Я хотіла б дізнатися думку спільноти 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: , і , на скільки я розумію , за цими ключам обчислюється хеш -код , за допомогою якого можна однозначно визначити місце положення даних. Про можливе варіанті реалізації процесу пошуку місця положення даних по хешу добре написано в цій статті: 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( посилання тут : ) , в той час , як Googleв особі Mark C. Chu - Carrollописав це рішення в 2004 році ( посилання тут : )

Спасибі за увагу , і чекаю від вас конструктивних коментарів і , головне , доповнень .

Опубліковано: 18/05/14 @ 04:16
Розділ Реклама

SEO Блог

Чи справді про модель розробки MapReduce можна говорити лише в контексті нереляційних сховищ даних?

Рекомендуємо: