Сергій Кузнецов
Поки дослідники і розробники примудряються впоратися з вчорашніми «великими даними», з'являються нові Великі Дані нових видів, з якими впоратися раніше неможливо. У цьому зв'язку сьогоднішній сплеск ажіотажу навколо Великих Даних в чому є штучним. Вічність і примарність проблеми навряд чи дозволяють розраховувати на її повне і остаточне рішення. Це погано для користувачів і розробників додатків, але гарантує постійну зайнятість дослідників і розробників СУБД. Звичайно, їх діяльність нагадує спроби моряків доплисти до міражу, навіяного фата-морганою, але самі ці спроби захоплюючі й корисні, оскільки підтримують саме розвиток людства.
Великі Дані та перспективні СУБД
Прийнято вважати, що традиційні РСУБД дозволяють ефективно управляти транзакційними та аналітичними базами даних. Транзакційні призначені для підтримки оперативних транзакційних додатків (системи резервування, управління логістикою, торгові системи і т. д.), що працюють з даними, що відображають поточний стан тієї чи іншої області діяльності, причому швидко і часто оновлюваними. Аналітичні бази містять історичні дані, що надходять з різних джерел, одним з яких є транзакційні бази даних.
Проблема Великих Даних знайома обом цим категоріям. Обсяги транзакційних баз ростуть через розвиток оперативних потреб користувачів, бізнесу чи науки. Наприклад, транзакційні бази інтернет-магазинів сильно збільшуються в об'ємі при персоналізації послуг. Обсяги аналітичних баз збільшуються в силу своєї природи - дані в них завжди тільки накопичуються і не знищуються. Іншою серйозною причиною зростання обсягу аналітичних баз є потреба бізнес-аналітиків у залученні нових джерел даних, наприклад черпаних з відкритих ресурсів Мережі.
Для транзакційних баз окремий випадок проблеми Великих Даних можна сформулювати наступним чином: потрібно забезпечити технологію щодо недорогого масштабування СУБД і транзакційних додатків, що дозволяє підтримувати необхідну швидкість обробки транзакцій при зростанні обсягу даних і збільшенні числа одночасно виконуваних транзакцій. Для аналітичних баз окремий випадок проблеми звучить так: потрібно забезпечити технологію щодо недорогого масштабування СУБД та аналітичних додатків, що дозволяє аналітикам розширювати можливості СУБД з виконання аналітичних запитів і забезпечувати ефективну оперативну аналітичну обробку даних при зростанні їх обсягу.
У першому десятилітті нового століття дослідникам на чолі з Майклом Стоунбрейкер вдалося намацати шляхи рішень обох частинах випадків, взявши за основу такі загальні принципи:
перенос обчислень якомога ближче до даних;
використання архітектури без спільно використовуваних ресурсів (sharing nothing);
ефективне розділення даних по вузлах системи з можливістю їх реплікації в декількох вузлах.
Перший принцип означає, що СУБД і додатки організуються таким чином, щоб мінімізувати пересилання даних між вузлами системи. Очевидно, що важливість цього принципу зростає при зростанні обсягу даних. Наслідком принципу є потреба в перенесенні додатків баз даних на сторону сервера.
Другий принцип говорить про можливість реального розпаралелювання роботи СУБД і додатків, оскільки при відсутності загальних ресурсів між вузлами обчислювальної системи (фактично при використанні кластерної архітектури) зменшується ймовірність конфліктів.
Третій принци...
