Статья 'Сравнительный анализ подходов к разработке архитектуры и систем управления базами данных для высоконагруженных WEB-сервисов' - журнал 'Кибернетика и программирование' - NotaBene.ru
по
Меню журнала
> Архив номеров > Рубрики > О журнале > Авторы > О журнале > Требования к статьям > Редакция и редакционный совет > Порядок рецензирования статей > Политика издания > Ретракция статей > Этические принципы > Политика открытого доступа > Оплата за публикации в открытом доступе > Online First Pre-Publication > Политика авторских прав и лицензий > Политика цифрового хранения публикации > Политика идентификации статей > Политика проверки на плагиат
Журналы индексируются
Реквизиты журнала

Публикация за 72 часа - теперь это реальность!
При необходимости издательство предоставляет авторам услугу сверхсрочной полноценной публикации. Уже через 72 часа статья появляется в числе опубликованных на сайте издательства с DOI и номерами страниц.
По первому требованию предоставляем все подтверждающие публикацию документы!
ГЛАВНАЯ > Вернуться к содержанию
Кибернетика и программирование
Правильная ссылка на статью:

Сравнительный анализ подходов к разработке архитектуры и систем управления базами данных для высоконагруженных WEB-сервисов

Сокольников Алексей Михайлович

студент, кафедра Информатики и системного программирования, Поволжский государственный технический университет

424000, Республика Марий Эл, г. Йошкар-Ола, пр. Ленина, дом 3, ПГТУ

Sokol'nikov Aleksei Mikhailovich

student of the Department of Computer Science and System Programming at the Volga State University of Technology

424000, Russia, Mari El, Yoshkar-Ola, pl. Lenina, d. 3

sokolnikov.alexey@gmail.com
Другие публикации этого автора
 

 

DOI:

10.7256/2306-4196.2014.4.12800

Дата направления статьи в редакцию:

01-08-2014


Дата публикации:

15-08-2014


Аннотация.

В современном мире для разработчиков все острее встает проблема обработки и хранения больших объемов данных. Сообщения в социальных сетях, фотографии, потоковое видео – все это создает высокую нагрузку на программное обеспечение, используемое на серверах. По этой причине стандартные подходы, используемые для проектирования архитектуры настольных приложений, чаще всего будут неэффективны, так как в большинстве случаев они не учитывают нагрузку на приложение со стороны огромного числа пользователей. На сегодняшний день нет четкого определения для высоконагруженных систем. В большинстве случаев этот термин применяются в ситуациях, когда приложение перестает справляться с моментальной нагрузкой, возложенной на него. Нельзя указать конкретных значений, по достижении которых система считается высоконагруженной, поскольку все приложение специфичны и одинаковое количество запросов может приводить к абсолютно разным нагрузкам на ресурсы. В ходе исследования систем управления базами данных было проведено несколько опытов замеряющих скорость выполнения основных операций с базами данных: добавление, выборка и удаление. На основании результатов этих опытов были сделаны выводы и даны рекомендации по выбору системы управления базами данных. В данной статье рассмотрены подходы к разработке высоконагруженных систем, выделены недостатки и преимущества каждого из подходов и приведены примеры использования этих подходов такими популярными сервисами, как ВКонтакте, Facebook, Google и Яндекс. Приведен сравнительный анализ систем управления базами данных MySQL и MongoDB. В заключении даны рекомендации по выбору СУБД в зависимости от подхода к проектированию архитектуры высоконагруженного проекта.

Ключевые слова: высоконагруженные программные системы, архитектура приложений, хранение данных, базы данных, MySQL, MongoDB, СУБД, программное приложение, большие объемы данных, реляционные базы данных

УДК:

004.4

Abstract.

In today’s world the problem of processing and storing huge amounts of data becomes increasingly pressing. Messages in social networks, photos, streaming video – altogether creates a high load on the server-side software. For this reason common approaches used in desktop-software design may be ineffective since they don’t take into account the huge load on the application created by the vast number of users. Currently, there is no clear definition for highly-loaded systems. In most cases this term is used in situations, when software fails to operate under some momentary load. There’s no specific values set at which a system can be considered highly-loaded, since each software is different and same amount of requests can lead to completely different loads on the resources. The given study of the database management systems consisted of several experiments, measuring the speed of common operation on databases, such as adding, selecting and deleting. Based on the result of these experiments the author makes conclusions and gives recommendations on choosing the database management system. The article reviews approaches in developing highly loaded systems, highlights their features and disadvantages and shows examples of the use of these approaches in popular web-services such as ВКонтакте, Facebook, Google and Яндекс. The articles brings a comparative analysis of MySQL and MongoDB database management systesms. In conclusion the author gives recommendations on selecting a database management system depending on the approach to designing architecture of a highly-loaded project.

Keywords:

highly loaded software systems, application architecture, data storage, database, MySQL, MongoDB, DBMS, software, large amounts of data, relational databases

Введение

Согласно опубликованным исследованиям TNS Web Index в январе 2011 года сайт Google посетили 20 миллионов 845 тысяч россиян[1]. Охват аудитории Wikipedia за тот же месяц составил 18 миллионов жителей Российской Федерации. Опираясь на эти цифры можно с уверенностью утверждать, что проектирование архитектуры приложения, устойчивой к высокой нагрузке играет важную роль при создании любого бизнес-проекта, претендующего на успех в сети Интернет.

Подходы к построению архитектуры приложения

Существует два подхода к реализации сервис-ориентированной архитектуры[5]. Условно их называют промышленный и эвристический . Разница между подходами заключается в способе разработки средств масштабирования. При эвристическом подходе средства разрабатываются совместно с бизнес-логикой. При промышленном – отдельно.

Рассмотрим более подробно промышленный подход (Рисунок 1), поскольку его используют большинство крупных проектов: Facebook, Yandex, Google.01_01

Рисунок 1. Промышленный подход к разработке архитектуры

В приложении, спроектированном промышленным подходом, имеется большая шина (API), на которую отправляются все запросы и от которой приходит обработанный результат. Недостатки данного подхода:

Во-первых, много времени уходит на разработку общего API – набора классов, функций и констант, предоставляемых приложением для использования во внешних программных продуктах.

Во-вторых, из-за высокой нагрузки на API, для его корректной работы необходимо высокопроизводительное аппаратное обеспечение.

Преимущества подхода:

Основным преимуществом данного подхода является быстрая разработка приложений. Поскольку к моменту, когда все API реализовано, приложениям, остается лишь обращаться к его методам и получать необходимые данные.

Второе неоспоримое преимущество – возможность найма разработчиков, далеких от создания сервисов с высокой нагрузкой. Основное API сервисов разрабатывается командой инженеров, специализирующихся на создании высоконагруженных систем. Таким образом, для разработчиков новых приложений, все методы будут реализованы в API, обращаясь к которому уже не стоит беспокоиться о решении проблемы высокой нагрузки.

Обратный подход используется в разработке ВКонтакте. Когда в этой компании разрабатывается какой-либо сервис, разработчику отдают все полномочия и оговаривается, что сервис должен быть масштабируем [6]. Такой подход называется эвристическим.

Основным его недостатком является предъявление высоких требований к квалификации разработчика, поскольку помимо бизнес-логики сервиса он должен позаботиться и о масштабировании своего продукта.

Преимущество данного подхода заключается в том, что отсутствует огромная нагрузка на главную шину, по которой в случае промышленного подхода пропускаются все данные и проходят запросы. В эвристическом подходе каждый сервис борется с высокой нагрузкой самостоятельно. Благодаря этому использование аппаратного обеспечения происходит более эффективно.

Еще одним немаловажным преимуществом сервис-ориентированного подхода является возможность его горизонтального масштабирования.

Масштабируемость[7] — способность системы справляться с увеличением рабочей нагрузки при добавлении ресурсов (обычно аппаратных). Существует два вида масштабирования системы: горизонтальное и вертикальное. Вертикальное – увеличение производительности системы за счет установки более мощного аппаратного обеспечения. Горизонтальное – увеличение за счет количества серверов.

Вертикально масштабировать проект значительно проще, достаточно лишь снабдить сервера более мощными процессорами или добавить оперативной памяти. Проблема такого подхода в том, что на определенном этапе не будет существовать подходящего аппаратного обеспечения, способного справится с текущими нагрузками. Таким образом, в итоге придется масштабировать приложение горизонтально, то есть разносить функционал на модули, которые будут выполняться на отдельных серверах.

Поскольку монолитное приложение представляет из себя единую структуру, его нельзя декомпозировать на модули, а это означает, что горизонтальное масштабирование применить невозможно.

Теорема Брюера[8] утверждает, что в любой реализации распределенных вычислений можно обеспечить не более двух из трех свойств: согласованность данных, доступность, устойчивость к разделению. В случае с монолитными приложениями все приложение находится в одном месте и устойчивостью к разделению данных можно пренебречь. По этой причине в приложениях с такой архитектурой принято применять реляционные системы управления базами данных, например MySQL или PostgreSQL.

В случае же сервис-ориентированной архитектуры в целях обеспечения устойчивости данных к разделению лучше использовать NoSQL базы данных. Кроме того, они оптимизированы для операций поиска и добавления нового элемента. Это полезно для анализа статических элементов в больших объемах данных. В качестве примера такой базы данных можно привести MongoDB[9].

Сравнение производительности MySQL и MongoDB

В данном эксперименте сравнивалась производительность основных операций с базами данных, таких как вставка, выборка, удаление и поиск среднего значения. При проведении тестов использовался язык PHP версии 5.4.9 и персональный компьютер со следующими характеристиками: процессор Intel Core i5 2.80 GHz, ОЗУ 8GB, ОС Windows 7.

Вставка элементов:

Для проведения эксперимента по замеру скорости вставки элементов был написан PHP-скрипт, создающий в базе 250 000 записей. Каждые 5 000 записей замерялось среднее время выполнения запроса. Зависимость времени выполнения операции (в секундах) от количества элементов в базе показана в таблице 1.

5 000

30 000

100 000

190 000

250 000

MySQL

0.001184

0.000765

0.000835

0.001013

0.000707

MongoDB

0.000105

0.000102

0.000102

0.000101

0.000103

Таблица 1

Таблица 1 показывает, что время выполнения запроса в MongoDB для операции вставки на порядок ниже, чем для СУБД MySQL.

Рисунок 2 показывает график по всем результатам эксперимента вставки:

02

Рисунок 2.

Выборка элементов:

Для проведения эксперимента по замеру средней скорости выборки элементов был разработан скрипт, создающий 250 000 записей в базе и проводящий выборку всех элементов базы через каждые 5 000 записей. Аналогично прошлому эксперименту, считалось среднее время выполнения запроса на интервале через 5 000. Результаты эксперимента в таблице 2:

5 000

30 000

100 000

190 000

250 000

MySQL

0,0231

0,0959

0,4708

0,8351

1,1745

MongoDB

0,0145

0,0883

0,3083

0,5656

0,7334

Таблица 2

Рисунок 3 - График зависимости среднего времени выполнения запроса (в секундах) от количества элементов в базе данных при выборке элементов:

03

Рисунок 3.

Как видно из графика, при малом количестве данных в базе (до 50 000 записей) разница практически не ощутима. В середине графика (150 000 записей) для обоих СУБД заметен скачок, предположительно, его причина появления обусловлена задержкой при считывании данных с диска.

Поиск среднего значения

Для данного эксперимента был разработан PHP скрипт, делающий выборку из базы среднего значение одного из полей целочисленного типа. В цикле происходила запись в базу 250 000 элементов и через каждые 5 000 элементов происходило вычисление среднего значения поля всей базы. Результаты эксперимента в таблице 3:

5 000

30 000

100 000

190 000

250 000

MySQL

0,0014

0,0144

0,3213

0,627

0,679

MongoDB

0,0047

0,0269

0,0889

0,1665

0,2225

Таблица 3

Таблица 3 указывает на то, что вычисление среднего значения для целочисленного значения в MongoDB происходит быстрее, чем в MySQL. Графически зависимость отображается следующим образом:

04

Рисунок 4.

Удаление элемента по индексу

Для проведения опыта по удалению элементов из базы был разработан PHP скрипт, запускающий запрос на удаление записи из базы данных 250 000 раз.

Результат работы скрипта в таблице 4

5 000

30 000

100 000

190 000

250 000

MySQL

0,001

0,0008

0,0006

0,0007

0,001

MongoDB

0,000104

0,000088

0,000147

0,000119

0,000088

Таблица 4

Как видно из полученной таблицы при удалении элементов из таблицы производительность MongoDB выше, чем у MySQL.

Полный результат опыта по удалению записей из таблицы в графическом представлении на рисунке 5:

05

Рисунок 5.

Заключение

Разработка программных систем с высокой нагрузкой на сегодняшний день достаточно актуальная тема. Но универсального ответа на вопрос «Как лучше проектировать высоконагруженное приложение» не существует.

Если стоит задача в сжатые сроки произвести основной функционал приложения, к примеру, для показа прототипа инвестору, то логичнее проектировать монолитное приложение, поскольку это позволить уменьшить срок разработки. В случае успеха проекта, для удобства поддержки и поддержания масштабируемости его следует привести к сервис-ориентированной архитектуре.

Если имеется достаточное количество разработчиков, обладающих знаниями в области производства высоконагруженных систем, то можно проектировать сервис-ориентированное приложение используя эвристический подход. Такой подход на первых этапах будет быстрее, чем промышленный, поскольку не будет тратиться время на разработку общего API. Каждый сервис будет масштабироваться отдельно. Проблемы возникнут в дальнейшем, когда необходимо будет расширить проект новыми разработчиками. При таком подходе квалификация специалиста имеет огромное значение.

Так же эвристический подход удобно применять, когда недостаточно средств на мощное аппаратное обеспечение (требуемое при промышленном подходе).

В случае, когда у компании достаточное количество временных и денежных ресурсов лучший вариант – промышленный подход к реализации высоконагруженной системы, поскольку есть возможность купить дорогостоящее аппаратное обеспечение и потратить много времени на разработку API. Кроме того, крупным компаниям предпочтительнее вложить заранее известную сумму в стоимость аппаратной части и получить рабочее приложение, способное выдерживать высокие нагрузки.

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

Дополнительным преимуществом MongoDB является относительная простота горизонтального масштабирования, по сравнению с MySQL. Однако это полезно лишь в случае сервис-ориентированной архитектуры приложения, поскольку монолитное приложение нельзя горизонтально масштабировать, а следовательно, в большинстве случаев для такого проекта можно обойтись обычной реляционной СУБД, такой как MySQL или PostgreSQL.

Библиография
1.
http://oborot.ru/news/9740/24 (дата обращения-9 мая 2014)
2.
http://www.iso.ru/print/rus/document6072.phtml (дата обращения-14 мая 2014)
3.
http://www.communigate.com/ru/ (дата обращения – 8 мая 2014)
4.
Разработка высоконагруженных систем. По материалам конференции HighLoad++ 2010-2011 / Олег Бунин //Москва, Издательство Олега Бунина, 2011.-416 стр.
5.
http://www.myshared.ru/slide/182074/ (дата обращения – 15 мая 2014)
6.
http://seopult.tv/programs/biz_people/oleg_bunin_vysokie_nagruzki_runeta/text/ (дата обращения – 13 мая 2014)
7.
IBM Redbook: The RS/6000 SP Inside Out, id: SG24-5374-00, СЫ.15
8.
Brewer, Eric A. A Certain Freedom: Thoughts on the CAP Theorem// Proceeding of the XXIX ACM SIGACT-SIGOPS symposium on Principles of distributed computing. — N. Y.: ACM, 2010. — В. 29. — № 1. — С. 335-336.
9.
http://www.mongodb.org/ (дата обращения – 1 июня 2014)
References (transliterated)
1.
http://oborot.ru/news/9740/24 (data obrashcheniya-9 maya 2014)
2.
http://www.iso.ru/print/rus/document6072.phtml (data obrashcheniya-14 maya 2014)
3.
http://www.communigate.com/ru/ (data obrashcheniya – 8 maya 2014)
4.
Razrabotka vysokonagruzhennykh sistem. Po materialam konferentsii HighLoad++ 2010-2011 / Oleg Bunin //Moskva, Izdatel'stvo Olega Bunina, 2011.-416 str.
5.
http://www.myshared.ru/slide/182074/ (data obrashcheniya – 15 maya 2014)
6.
http://seopult.tv/programs/biz_people/oleg_bunin_vysokie_nagruzki_runeta/text/ (data obrashcheniya – 13 maya 2014)
7.
IBM Redbook: The RS/6000 SP Inside Out, id: SG24-5374-00, SY.15
8.
Brewer, Eric A. A Certain Freedom: Thoughts on the CAP Theorem// Proceeding of the XXIX ACM SIGACT-SIGOPS symposium on Principles of distributed computing. — N. Y.: ACM, 2010. — V. 29. — № 1. — S. 335-336.
9.
http://www.mongodb.org/ (data obrashcheniya – 1 iyunya 2014)
Ссылка на эту статью

Просто выделите и скопируйте ссылку на эту статью в буфер обмена. Вы можете также попробовать найти похожие статьи


Другие сайты издательства:
Официальный сайт издательства NotaBene / Aurora Group s.r.o.
Сайт исторического журнала "History Illustrated"