п забезпечує ефективну паралельну обробку транзакцій або ефективну підтримку оперативної аналітичної обробки даних.
Всі три принципи далеко не нові і датовані 80-ми роками минулого століття. Наприклад, на принципах sharing nothing грунтується популярна і ефективна паралельна СУБД Teradata, успішно використовувана вже протягом декількох десятків років. Однак саме сьогодні всі три принципи вдалося успішно застосувати при створенні реально масштабованих паралельних транзакційних та аналітичних СУБД.
Застосування цих принципів є необхідною, але не достатньою для реалізації обох категорій систем, і в кожному випадку доводиться вдаватися до додаткових ідеям. Зокрема, транзакційні паралельні СУБД виявляється вигідно засновувати на давно відомих ідеях обробки в основній пам'яті, а для забезпечення надійності даних застосовувати розвинену реплікацію. В аналітичних же системах більш ефективна технологія зберігання табличних даних у зовнішній пам'яті по стовпцях в сукупності з підтримкою різноманітних надлишкових структур даних (ідеї зберігання даних по стовпцях не нові і використовувалися, наприклад, в аналітичній СУБД Sybase IQ).
Шляхи вирішення проблеми великих транзакційних та аналітичних даних намічені, але це не означає, що вирішені навіть приватні види проблем. Наприклад, транзакційні паралельні СУБД ефективно працюють тільки при такому поділі даних, яке мінімізує число розподілених транзакцій в наявної робочої навантаженні, а при зміні робочого навантаження потрібно перерозподіляти дані. Аналітичні паралельні СУБД справляються зі складними аналітичними запитами тільки в тих випадках, коли поділ даних відповідає специфіці запитів. Іншими словами, час від часу доводиться перерозподіляти дані величезного обсягу (у тому числі і при горизонтальному масштабуванні систем).
Масштабована паралельна серверна бізнес-аналітика
Отже, спільнота розробників баз даних порівняно добре навчилося будувати горизонтально масштабовані паралельні аналітичні СУБД, здатні підтримувати ефективне виконання стандартних аналітичних запитів. Але як бути з принципом наближення обчислень до даних? Якщо на сервері СУБД працюють лише базові засоби аналітики, то в будь-якому більш-менш серйозному аналітичному додатку доведеться перетягувати великі обсяги аналітичних даних на робочі станції або в кращому випадку - на проміжні аналітичні сервери. Єдиним способом усунення цього дефекту є розширення серверних аналітичних засобів новими аналітичними функціями, що поставляються бізнес-аналітиками. На перший погляд, відповідні можливості надають засоби SQL, що дозволяють користувачам визначати власні функції, процедури та типи даних, але SQL не забезпечує розпаралелювання програм. Іншими словами, аналітик змушений писати паралельні програми для виконання на стороні сервера при обробці майбутніх аналітичних запитів, причому шматочки цих програм повинні будуть виконуватися поблизу від відповідних шматочків даних. Як це зробити?
Єдиним поширеним методом паралельного програмування в кластерному середовищі є MPI - інтерфейс передачі повідомлень, що дозволяє програмісту вказати розташування паралельно виконуваних частин програми у вузлах кластерів і забезпечити їх взаємодію для формування остаточного результату. Програмування з використанням MPI являє собою складність навіть для професійних програмістів. Чи можна зробити професійними програмістами бізнес-аналітиків, яким бл...
