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

Реферат по теме выпускной работы

Содержание

Введение

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

1. Актуальность темы

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

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

Современные высоконагруженные приложения изменили требования к СУБД — стали актуальны эффективные технологии создания cпециализированных решений с гарантированным временем реакции при обработке больших массивов данных. Вместе с тем, несмотря на появление таких технологий, как NoSQL, потенциал давно cуществующих подходов реализован еще не полностью. Можно сделать вывод, что Оптимизации для высоконагруженных реляционных БД и альтернативные решения является актуальной темой и не потеряет своeй актуальности в ближайшее время.

2. Цель и задачи исследования, планируемые результаты

Целью магистерской работы является разработка высоконагруженной веб-системы с поддержкой высокой посещаемости и ориентированной на хранение большого количества графических и мультимедийных данных

Основные задачи исследования:

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

3. Обзор исследований и разработок

С момента выхода первой работы, в которой была сформулирована проблема оптимизации запросов к базам данных, прошло уже более 40 лет. На протяжении этого времени вышло множество публикаций, посвященных данной тематике. Некоторое представление о численности исследований и разработок может дать анализ библиографий вышедших на настоящий момент работ. Так, исследование М. Ярке (M. Jarke) и Ю. Коха (J. Koch) включает в себя перечень из более чем 253 работ, М. Маннино (M. V. Mannino), П. Чу (P. Chu) и Т.Сейджера (T. Sager) – 64 работы), Я. Ионнидиса (Y. E. 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 Объем анимации 10.6 КБ Количество кадров 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. Локальность данных. Намного эффективней выполнять вычисления рядом с данными. HDFS предоставляет приложениям программный интерфейс, который позволяет выполнять вычисления ближе к необходимым данным, сокращая пересылки между узлами кластера.

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.