ФКНТ   Кафедра АСУ ДонНТУ   Портал магістрів

Реферат за темою випускної роботи

Зміст

Вступ

На сьогоднішній день в від ІТ-індустрії потрібно не тільки зберігати інформацію і досягати абстрактної швидкодії, а обробляти конкретні дані будь-якої природи і доставляти їх конкретному користувачеві. І тут виявилося, що традиційні реляційні СУБД, які були створені в епоху мейнфреймів і Unix-систем, були розраховані на транзакційну обробку табличних даних і не допускають можливості роботи у системах з горизонтальним масштабуванням, необхідних для операцій з розподіленими джерелами різнорідних даних величезних обсягів. Крім того, стало очевидно, що сучасні користувачі не хочуть витрачати час на конвертацію даних в реляційні формати, а вважають за краще зберігати їх у початковому вигляді, структуруя тільки за необхідністю, наприклад при вирішенні завдань аналітики. Як наслідок, зараз заговорили мало не про кризу колишньої ще зовсім недавно стабільної області СУБД - тут почалися зрушення, виражені, зокрема, у появі таких рухів, як NoSQL і NewSQL [1, 2].

1. Актуальність теми

Ми живемо в інформаційний вік. Нелегко виміряти загальний обсяг електронних даних, але за оцінками IDC розмір цифрового всесвіту у 2006 р. становив 0.18 зеттабайт, а до 2011 р. досяг 1.8 зеттабайт, продемонструвавши десятикратне зростання за 5 років. Стрімко зростаючий обсяг інформації ставить нові складні завдання щодо організації його зберігання і обробки [3].

За багаторічну історію розвитку систем обробки даних було вироблено кілька моделей подання інформації: ієрархічна, мережева, реляційна, об'єктно-реляційна і т. д. Найбільшого поширення отримала реляційна, надовго стала стандартом подання структурованої інформації, і одна з головних причин цього її простота для прикладного програміста. Реляційний механізм дозволяє представляти інформацію з різних предметних областей, використовуючи зручний підхід до маніпулювання даними, оформлений у вигляді SQL. Простота і природність реляційної алгебри дозволили створити універсальні алгоритми виконання запитів, що задовольняють більшість розробників прикладних систем. Однак реляційна модель оперує тільки атомарними даними, що виключає обробку неструктурованої інформації, і, більше того, неможливо навіть зберігання текстових документів довільної довжини, все разом це призводить до неможливості зберігання мультимедіа. До того ж транзакційні бази сильно збільшуються в об'ємі при персоналізації послуг, і працювати з ними засобами реляційних СУБД стає все складніше [4].

Сучасні високонавантажені додатки змінили вимоги до СУБД - стали актуальні ефективні технології створення спеціалізованих рішень з гарантованим часом реакції при обробці великих масивів даних. Разом з тим, незважаючи на появу таких технологій, як NoSQL, потенціал давно існуючих підходів реалізований ще не повністю. Можна зробити висновок, що Оптимізації для високонавантажених реляційних БД і альтернативні рішення є актуальною темою і не втратить своe актуальності найближчим часом.

2. Мета і задачі дослідження та заплановані результати

Метою магістерської роботи є розробка високонавантаженої веб-системи з підтримкою високої відвідуваності і орієнтованої на зберігання великої кількості графічних і мультимедійних даних

Основні завдання дослідження:

  1. Провести огляд технологій застосовуваних для оптимізації реляційних баз даних.
  2. Проаналізувати застосування альтернативні рішень порівняно з реляційними бд.
  3. Дослідити характеристики найбільш відомих архітектур високонавантажених систем.
  4. Спроектувати архітектури високонавантаженої системи онлайн аналога друкованого періодичного видання.
  5. Розробити метод оптимізації високонавантаженого додатки
  6. Практична реалізація веб-системи онлайн аналога друкованого періодичного видання

3. Огляд досліджень і розробок

З моменту виходу першої роботи, в якій була сформульована проблема оптимізації запитів до баз даних, пройшло вже більше 40 років. Протягом цього часу вийшло безліч публікацій, присвячених даній тематиці. Певне уявлення про чисельність досліджень і розробок може дати аналіз бібліографій робіт. Так, дослідження М. Ярку (M. Jarke) і Ю. Коха (J. Koch) включає в себе перелік із понад 253 робіт, М. Манніно (MV Mannino), П. Чу (P. Chu) і Т.Сейджера (T. Sager) - 64 роботи), Я. Іоннідіса (YE Ionnidis)-більше 50 робіт, С. Чаудхари (S. Chaudhari) - 61 робота, С. Д. Кузнєцова - 128 робіт. Огляди методів оптимізації також містяться в тематичних розділах робіт Г. Грейфа (G. Graefe), К. Дейта (C. Date), М. Т. Оцсу (M. Ozsu) і П. Валдуреза (P. Valduriez), Р. Рамакрішнан (R. Ramakrishnan) і Дж. Герке (J. Gehrcke). Крім цього, слід врахувати коротку бібліографію робіт, присвячених оптимізації запитів, в якій міститься класифікація цих робіт за темами. Нарівні з академічними дослідженнями, присвяченими оптимізації запитів, паралельно виходять публікації компаній, присвячені вирішенню цього завдання в рамках СУБД (наприклад, MySQL, Oracle, DB2, PostgreSQL). Як показує представлена вище статистика публікацій у даній галузі, повний огляд є нетривіальним завданням. По даній тематиці проведено вже велика кількість конференцій таких як HighLoad + + (2007, 2008, 2009, 2010, 2011і 2012, 2013), NoSQL matters Conference (2013), NoSQL NOW (2013) [1, 2, 4].

4. Підхід роботи з великими даними

4.1 Реляційні СУБД

До певного моменту, практично єдиною відповіддю на питання як зберігати й обробляти дані? Була реляційна СУБД. Але зі збільшенням обсягів з'явилися проблеми, з якими класична реляційна архітектура не справлялася, тому інженерам довелося придумувати нові рішення. Питанню оптимізації запитів присвячено безліч статей і оглядів [3, 6, 7]. Можно виділити два основні методи оптимізації - статистичний та алгебраїчний. Статистичний метод базується на системі оцінок, статистикою бази даних і припущення моделі. Застосування різних евристик звужує простір пошуку, і вибирається оптимальний план виконання запиту. Алгебраїчний метод заснований на застосуванні до запиту операцій реляційної алгебри та математичної логіки, завдяки чому на виході виходить еквівалентний канонічний запит[8].

Спроби пристосувати реляційну СУБД до роботи з великими даними призводять до наступного:

  1. Відмови від суворої консистентності.
  2. Відмови від нормалізації і впровадження надмірності.
  3. Втрата виразності мови SQL і необхідності моделювати частину її функцій програмно.
  4. Ускладнення клієнтського програмного забезпечення.
  5. Складнощі підтримки працездатності та відмовостійкості отриманого рішення.

Необхідно відзначити, що виробники реляційних СУБД усвідомлюють всі ці проблеми і вже почали пропонувати масштабовані кластерні рішення. Однак вартість впровадження та супроводу подібних рішень часто не окупається.

4.2 NoSQL

Популярність NoSQL став набирати в 2009 р, у зв'язку з появою великої кількості веб-стартапів, для яких найважливішим завданням є підтримання постійної високої пропускної здатності сховища при необмеженому збільшенні обсягу даних. NoSQL не має на увазі відмови від всіх принципів реляційної моделі. Більше того, термін NoSQL вперше був використаний в 1998 році для опису реляційної бази даних, що не використала SQL.

Основні особливості NoSQL підходу:

  1. Виняток зайвого ускладнення.
  2. Висока пропускна здатність.
  3. Необмежене горизонтальне масштабування.
  4. Консистенція в жертву продуктивності.
Рух NoSQL і SQL Обсяг анімації 11 КБ Кількість кадрів 10

Рисунок 1 - Рух NoSQL і SQL

На сьогоднішній день створено велику кількість NoSQL рішень. Багато теоретиків і практиків створювали свої власні класифікації, але найбільш простою і загальновживаною можна вважати систему, засновану на використовуваної моделі даних, запропоновану Ріком Кейтелем (Rick Cattel):

  1. Сховища ключ-значення. Відмінною особливістю є проста модель даних - асоціативний масив або словник, що дозволяє працювати з даними по ключу. Основне завдання подібних сховищ - максимальна продуктивність, тому ніяка інформація про структуру значень не зберігається.
  2. Документні сховища. Модель даних подібних сховищ дозволяє об'єднувати безліч пар ключ-значення в абстракцію, звану документ. Документи можуть мати вкладену структуру і об'єднуватися в колекції. Однак це скоріше зручний спосіб логічного об'єднання, тому що ніякої жорсткої схеми у документів немає і безлічі пар ключ-значення, навіть в рамках однієї колекції, можуть бути абсолютно довільними. Робота з документами проводиться по ключу, однак існують рішення, що дозволяють здійснювати запити за значеннями атрибутів.
  3. Колоночного сховища. Цей тип здається найбільш схожим з традиційними реляційними СУБД. Модель даних сховищ подібного типу має на увазі зберігання значень як неінтерпретіруемих байтових масивів, адресованих кортежами ключ рядки, ключ стовпця, мітка часу. Основою моделі даних є колонка, число колонок для однієї таблиці може бути необмеженим. Колонки по ключах об'єднуються в сімейства, що володіють певним набором властивостей.
  4. Сховища на графах. Подібні сховища застосовуються для роботи з даними, які природним чином представляються графами (наприклад, соціальна мережа). Модель даних складається з вершин, ребер і властивостей. Робота з даними здійснюється шляхом обходу графа по ребрах із заданими властивостями [2].

4.3 MapReduce

MapReduce - це підхід до обробки даних, який має дві серйозних переваги в порівнянні з традиційними рішеннями. Перше і найголовніше - це продуктивність. Теоретично MapReduce може бути розпарован, що дозволяє обробляти величезні масиви даних на безлічі ядер / процесорів / машин. Другою перевагою MapReduce є можливість описувати обробку даних кодом. У порівнянні з тим, що можна зробити за допомогою SQL, можливості коду всередині MapReduce набагато багатіше і дозволяють розширити рамки можливого навіть без використання спеціалізованих рішень. Реалізації вже маються на C #, Ruby, Java, Python.

За зберігання та організацію даних у кластері відповідає розподілена файлова система HDFS [9]. При проектуванні використовувалися такі принципи:

  1. Апаратні збої неминучі. Тому HDFS реалізує надійні алгоритми реплікації даних, а для метаданих файлової системи підтримується журнал, що дозволяє відновити стан.
  2. Потокова обробка та великі обсяги. HDFS влаштована таким чином, щоб забезпечити максимальну продуктивність потокового доступу до даних. До того ж структури файлової системи оптимізовані для роботи з великими файлами.
  3. Локальність даних. Набагато ефективніше виконувати обчислення поруч з даними.

MapReduce - це шаблон який стрімко набуває популярності, його вже можна використовувати майже скрізь, навколо сформувалася ціла екосистема проектів:

  1. Hive - розподілене сховище даних. Hive управляє даними в HDFS і надає мову запитів HiveQL, засновану на SQL. Запити HiveQL автоматично транслюються в MapReduce завдання
  2. Pig - середовище виконання і високорівнева мова, для опису обчислень в Hadoop. Програми Pig також транслюються в MapReduce завдання.
  3. Hbase - розподілена база даних. Hbase використовує HDFS, як сховище і підтримує як пакетні обчислення, так і довільний доступ [10].
  4. ZooKeeper - високодоступних координаційний сервіс, який використовується для побудови розподілених додатків.

Висновки

В останні десятиліття явно намітилася тенденція заміни друкованих періодичних видань онлайн аналогами. Цей спосіб подання інформації дозволяє необмеженому колу читачів ознайомитися з опублікованим матеріалом, вільно вести дискусії з авторами статей та іншими зацікавленими особами. Електронний журнал дозволяє швидко організовувати часте оновлення інформації шляхом зниження часу і витрат на такі видавничі процедури, як верстка, тиражування і так далі. Слід зауважити, що фактична кількість читачів безпосередньо залежить не тільки від цінності наданої інформації, але і від способу побудови, зручності доступу до різних розділів, зовнішнього вигляду видання, швидкості завантаження сторінок. Так само має велике значення висока швидкість завантаження мультимедійного контенту, без втрати його якості. Таким чином, виникає необхідність проектування високонавантаженої системи, для зберігання великих обсягів даних, у тому числі графічних і мультимедійних, з високою продуктивністю і мінімальним часом обробки.  При проектуванні сховища даних для подібного роду системи повинні бути дотримані такі вимоги: сховище даних повинне забезпечувати максимальну продуктивність на читання даних, повинна бути забезпечена можливість масштабування і розподілу навантаження на необмежену кількість серверів, дизайн логічної структури повинен бути достатньо гнучким. Класична реляційна база даних не відповідає цим вимогам і виникає необхідність або її оптимізації, або пошуку альтернативного рішення. У результаті проведених досліджень були визначені основні підходи проектування високонавантаженої бд, з урахуванням специфіки зберігання часто запитуваної мультимедійної інформації.

У рамках магістерської роботи передбачається розробка високонавантаженої веб-системи, проектування сховища даних з високою пропускною здатністю при необмеженому збільшенні обсягу даних.

У рамках магістерської роботи передбачається розробка високонавантаженої веб-системи, проектування сховища даних з високою пропускною здатністю при необмеженому збільшенні обсягу даних.

При написанні даного реферату магістерська робота ще не завершена. Остаточне завершення: грудень 2013 року. Повний текст роботи та матеріали по темі можуть бути отримані у автора або його керівника після вказаної дати.

Перелік посилань

  1. Мендкович Н. А. Обзор развития методов лексической оптимизации запросов / Н. А. Мендкович, С. Д. Кузнецов / Труды Института системного программирования т. 23, М., ИСП РАН, 2012, стр. 195-214
  2. Клеменков П.А. Большие данные: современные подходы к хранению и обработке / П.А. Клеменков, С.Д. Кузнецов / Труды Института системного программирования, т. 23, М., ИСП РАН, 2012, стр. 143-158.
  3. Tom White Hadoop: The Definitive Guide, 3rd Edition / White Tom /O'Reilly Media, 2012, 688 p.
  4. Волков Д. Открытые системы СУБД / 4. Д. Волков / М. 2012, № 02 ISSN 1028-7493
  5. Rick Cattell Scalable SQL and NoSQL Data Stores / Cattell Rick / SIGMOD Record, December 2010 (Vol. 39, No. 4)
  6. Mark A. Beyer, Douglas Laney. The Importance of Big Data: A Definition, 21 June 2012.
  7. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, Robert E. Gruber. Bigtable: a distributed storage system for structured data. Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation, vol. 7, p. 15-15, USENIX Association Berkeley, CA, USA, 2006
  8. Пашинин О.В. ОПТИМИЗАЦИЯ ЗАПРОСОВ К БАЗАМ ДАННЫХ / О.В. Пашинин / Математические структуры и моделирование 2007, вып. 17, с. 100–107
  9. Konstantin Shvachko, Hairong Kuang, Sanjai Radia, Robert Chansler. The Hadoop Distributed File System. MSST '10 Proceedings of the 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST), 2010, pp. 1-10.
  10. P. Hunt, M. Konar, F. P. Junqueira, and B. Reed. ZooKeeper: wait-free coordination for internet-scale systems. USENIXATC'10: Proceedings of the 2010 USENIX conference on USENIX annual technical conference. Berkeley, CA, USA: USENIX Association, 2010, pp. 11–11.