CC BY
428
УДК 004.62
М.Т. Фкун, С.С. Клюс ПОБУДОВА СИСТЕМИ В1ЗУАЛ1ЗАЩ1 ДАНИХ З ВИКОРИСТАННЯМ ДОКУМЕНТО-ОРШНТОВАНО1 СКБД
MONGODB
Вступ. Зростання об'ему даних, ор!ентованих на користувач!в, викликало швидке збiльшення об'ему i титв даних, яш створюються, вiдoбpaжaються, aнaлiзyються i apхiвyються. KpiM того, змiнюeться кшьшсть нових нaбopiв джерел даних, у тому числ! датчики, системи глобального позицюнування (GPS), aвтoмaтизoвaнi трекери i системи мoнiтopингy, якi створюють велик! масиви даних. Ц велик! обсяги нaбopiв даних, як1 часто називають «великими даними»(англ. Big Data), створюють нов! виклики i можливосп навколо збертання, анал!зу та арх!вування.
Паралельно 3i швидким зростанням обсяпв даних, дан! також стають все бшьш частково-структурованими i розаяними. Це означае, що традицшш методи управлшня даними, засноваш на попередньому визначенш схеми даних i посилань м!ж даними, вже не вшповщають сучасним вимогам обробки i анал!зу великих р!знотипних слабко структурованих даних. Ц види СКБД називаються NoSQL [1-3]. Вони не е повним запереченням мови SQL i реляцшно! модел!, шдхщ NoSQL виходить з того, що SQL - це важливий i дуже корисний шструмент, але при цьому вш не може вважатися ушверсальним. Одшею з проблем, на яку вказують для класичних реляцшних БД, е проблема при робот! з даними дуже великого об'ему, з! слабко структурованими або неструктурованими даними, особливо у системах з високим навантаженням. Основна мета подходу - розширити можливосп БД там, де SQL недостатньо гнучкий, i не випсняти його там, де вш справляеться з! сво!ми завданнями дуже ефективно.
Документо-ор!ентована система керування базами даних (ДОСКБД) - це система, яка збертае колекцш текстових даних та надае змогу створювання запиттв i оновлення об'екпв. Зазвичай, база даних включае в себе безл!ч докуменпв, що сшввшносяться за предметом, походженням або застосуванням. Змют кожного документа може бути вшьним текстом, частково структурованим текстом, який включае кшька чггко визначених атрибупв (наприклад, назва, автор, дата), або добре структурованим текстом, наприклад, може бути закодованим з використанням мови XML. 1нод! документа також можуть мютити мультимедшш компоненти.
Постановка задачь ДОСКБД можуть застосовуватись для збереження великого об'ему даних: змш курав валют, акцш та цшних папер!в, трекшгу використання сайту (анал!зу журнал!в 1нтернет-сервер!в з великою кшьшстю користувач!в), як1 можуть використовуватись для розробки системи мониторингу (в!зуал!заци даних) реального часу. Таким чином, ДОСКБД надають нов! шформацшш технологи для видавництв, цифрових б!блютек, електронного уряду та електронного б!знесу в цшому. Оскшьки нов! технологй' обробки великих масив!в слабко структуровано! шформаци ще мало дослщжеш, обрана тема дано! стати представляеться актуальною.
Метою до^дження е визначення переваг i недолЫв документо-ор!ентовано1 СКБД MongoDB на приклад! створення системи в!зуал!заци даних реального часу.
Анал!з розвитку нереляцшних СКБД та !х особливостей. 1снуе багато причин використовувати нереляцшш СКБД, але можна видшити дв! основш причини:
- Продуктившсть розробки застосувань. Багато зусиль в обласп розробки програмного забезпечення витрачаеться на вшображення модел! та структури даних, яш знаходяться в оперативнш пам'яп комп'ютера, у реляцшш бази даних. NoSQL сховища даних можуть забезпечити модель даних, яка краще вшповщатиме потребам розробнишв застосувань, тим самим спрощуючи взаемодш з СКБД i, в результат! чого, зменшуючи к1льк1сть написаного коду, час на налагодження i впровадження.
- Велик! масштаби даних. Оргашзацп вважають доцшьним збертати велик! об'еми даних i обробляти !х бшьш швидко. Зробити це виявляеться досить дорого, якщо взагал! можливо, з використанням реляцшних СКБД. Основною причиною е те, що реляцшна база даних призначена для запуску на одному комп'ютер!, але, як правило, е бшьш економним збертати велик! обсяги даних i запускати обчислення на кластерах, як1 складаються з набагато менших i дешевших машин. Багато нереляцшних СКБД спещально спроектоваш та розроблеш для роботи на кластерах, саме тому вони краще шдходять для збереження великих об'ем!в даних.
В литератур! часпше за все видшяють так1 види не реляцшних СКБД:
- Стовпчико-opieHmoeaHi СКБД. Структура даних в них контрастуе з кортежним (рядковим) форматом реляцшних СКБД. Це дозволяе уникати використання мюця при збертанш null-даних, просто не збернаючи стовпщ, якщо не юнуе даних для цього стовпця. Стовпщ не потребують шякого апрюрного визначення. Кр!м того, вони здатш збертати будь-як1 типи даних, оскшьки дан! можуть бути
збережеш у виглядi масиву байпв. Така структура даних, звана як Bigtable, використовуеться, зокрема, компашею Google.
- СКБД типу «ключ-значення». Вони е простою хеш-таблицею, тому весь доступ до даних здшснюеться через первинний ключ. У якосп значень даних використовуються blob-об'екти (англ. Binary Large Objects - велиш об'екти у бшарному формап). Оск1льки СКБД типу «ключ-значення» завжди використовують первинний ключ для доступу до даних, вони, як правило, мають високу продуктивнiсть i легко масштабуються.
- Бази даних на основi граф1в. Вони дозволяють зберiгати об'екти предметно!' областi i зв'язки мгж цими об'ектами. Об'екти також називають вузлами, як1 мають властивостi. Вузол е представлениям екземпляра об'екта в застосуванш. Зв'язки мiж об'ектами, вiдомi як ребра, як1 можуть мати властивостг Ребра мають направлення; вузли органiзованi зв'язками, як1 дозволять знайти певш закономiрностi м1ж вузлами. Оргашзащя графа дозволяе зберегти данi один раз i попм iнтерпретувати по^зному на основi зв'язк1в мiж об'ектами. Така структура даних мае багато загального з представленням знань на основаiв семантичних мереж.
- Багатовимiрнi бази даних. Використовуютьтся для штерактивного аналiтичного опрацювання агрегованих даних, при цьому агрегац1я може бути по дек1лькох рiвнях iерархiï, наприклад, рiк, квартал, мюяц. Гiперкуб даних можна розглядати як множину ввдношень реляцiйноï бази даних за значеннями кожного з вимiрiв. Отже, носiем багатовимiрноï моделi даних е ввдношення реляцiйноï бази даних, зображеш як зафiксованi вимiри. Отже, мiж реляiйною моделлю та багатомiрною iснуе взаемне вщображення, а значить, можна даш, представленi в однш моделi, перетворити в iншу модель. Тому побудоваш на багатомiрнiй моделi технологiï OLAP (On Line Analysis processing) [4] реалiзованi в поширених СКБД реляiйного типу MS SQL Server, Oracle та шших. Багатовимiрна модель розширюе реляцiйну: множина операцш, окрiм традицiйних реляцiйних, мiстить операцп зрiзу, згортки, деталiзацiï, обертання.
- Об'ектш СКБД. В них даш моделюються у виглядi об'ектiв, 1'х атрибутiв, методiв i класiв. Одним з вщомих представник1в цього типу систем збер^ання й обробки даних е СКБД CACHÉ [5]. Крiм об'ектно1' моделi вона шдтримуе також реляцшну i багатовимiрну, при цьому представлення даних в однiй iз моделей автоматично перетворюеться в iншi моделi.
- документо-орiентованi СКБД. Документи е основною концепцiею в документо-орiентованих СКБД. База даних зберiгае i вибирае документи, як1 можуть бути XML, JSON, BSON, i так далг Документи - це iерархiчнi структури даних, як1 можуть складатися з карт, колекцiй та скалярних значень. Документи, що зберiгаються, не обов'язково повинш бути з однаковою структурою.
Використання термiну «NoSQL», в тепершньому розумiннi пов'язують з Йоханом Оскарссоном (2009 р.), а першими прообразами програмних продуктiв були таш, як BigTable (пропрiетарна високопродуктивна база даних, побудована на основi Google File System (GFS), Chubby Lock Service i деяких шших продуктах Google.
Компан1я Google за останш кшька рок1в, побудувала масштабну iнфраструктуру для свое1' пошуково1' системи i шших програм, включаючи Google Maps, Google Earth, Gmail, Google Finance i Google Apps. Була опублiкована i представлена серiя робiт, яка пояснюе деяк1 з ключових елементiв шфраструктури створених систем. Найбiльш важливi з цих публтацш представленi в [6-9].
Шсля схвалення NoSQL двома провщними веб-гiгантами - Google i Amazon - з'явилося кшька нових продукпв. Багато розробнишв почали використовувати методи та ще1' NoSQL в сво1'х прикладних програмах. Менш н1ж за 5 рошв NoSQL i пов'язаш з ним поняття для управлшня великим обсягами даних одержали широке поширення i використання у багатьох вщомих компан1ях, включаючи Facebook, Netflix, Yahoo, EBay, Hulu, IBM та ш.
В роботi [10] наведено таш три вщмшносп систем NoSQL вщ реляцiйних СКБД
1. Неструктуроватсть. У нереляцшних базах даних, на вщм^ вщ реляцiйних, структура даних не регламентована (або слабо титзована, якщо проводити аналогiï з мовами програмування) - в окремому рядку або докуменп можна додати довшьне поле без попереднього декларативного змшення структури всiеï таблицi.
Перевагою вщсутносп схеми е бiльш ефективна робота з розаяними (sparse) даними. Якщо в одному докуменп е поле birthday, а в другому - немае, значить н1якого порожнього поля birthday для другого створено не буде. I в стовпчико-орiентованих базах даних NoSQL, в яких використовуються знайомi поняття таблиць/колонок, в силу вщсутносл схеми, атрибути (колонки) не оголошуються декларативно i можуть мшятися/додаватися тд час сесiï роботи користува з базою. Це дозволяе зокрема використовувати динамiчнi колонки для реалiзацiï списков.
У неструктуровано1' схеми е сво1' недолiки: накладнi витрати в кодi прикладно1' програми при змш моделi даних; вiдсутнiсть обмежень, що забеспечують iлiснiсть бази даних (not null, unique, check constraint i т.д.); додатковi складнощi в розумшш i контролi структури даних при паралельнш роботi з базою даних.
Проблеми паралелiзму юнують i в реляцшних базах даних (втрата результагiв оновлення, залежность вщ незафiксованих результатiв, неузгодженона обробка результапв) [4], але у неструктурованих БД вони бшьш складнi.
2. Представления даних у виглядг агрегат1в. На ввдшну вщ реляцiйноï моделi, яка збершае логiчну модель предметноï сфери в рiзних нормалiзованих таблицях, NoSQL-сховища оперують з цими сутностями як з цшсними об'ектами. С ще1" точки зору вони ближче до об'ектних баз даних. Наприклад, в об'ектнш СКБД CACHÉ [5] таю агрегати називаються глобалами. Оскiльки в агрегат! зберiгаeгься вся iнформацiя для певно1' задачi, щоб звести до мшмуму операцiï «join» м1ж об'ектами, то наслщком цього може бути дублювання iнформацiï в iнших агрегатах. В цьому полягае головне правило проектування структури даних в NoSQL базах даних - вони повинш вiдповiдати вимогам застосування i бути максимально ошгашзованими пщ найбiльш част запити. Наприклад, якщо платеж! регулярно витягуються разом iз замовленням - мае сенс 1'х включати в загальний об'ект, якщо ж багато запипв працюють тшьки з платежами - значить, краще 1'х винести в окрему сутшсть. До речи, в реляцшних базах даних теж приходиться йти на денормалiзацiю БД тд найб№ш частi запити [11]. Це компромю, на який доводиться йти, щоб запоб^и значного уповшьнення роботи бази. Плюси i м!нуси обох шдход!в згрупованi у таблиц 1.
Таблиця 1.
Переваги i недолши рiзних пiдходiв зберiгання даних
Структури й органiзацiя даних Переваги Нeдолiки
Нормалiзованi таблицi реляцiйноï моделi даних Цiлiснiсть iнформацii при оновленш (мiняeмо запис в однiй таблиш, а не у декшькох). Неефективна у pозподiлeному сepeдовищi.
Орieнтованiсть на широкий спектр запитiв до даних Низька швидкють читання при викоpистaннi сполучень (joins)
Математичний базис мов манiпулювання даними Невщповщшсть peляцiйноï модeлi фiзичнiй стpуктуpi даних
Даш у виглядi arperaTiB в NoSQL-базах даних Найкращий споаб досягти високоi' швидкостi читання у розподшеному середовищi. Оптимiзaцiя тiльки пiд певний тип запипв.
Можливiсть зберiгати фiзичнi об'екти у тому виглядi, в якому з ними легше працювати застосування(легше кодувати i менше помилок при перетворенш) Тpуднощi щодо зебеспечення цiлiсностi нeноpмaлiзовaних даних
Вбудована пiдтримка атомарносп на рiвнi записiв Вiдсутнiсть математичного базису для мови мaнiпулювaння даними
3. Слабк ACID-властивостi. ACID (англ. Atomicity, Consistency, Isolation, Durability) - це Ha6ip властивостей, що гарантують надiйну роботу транзакцiй бази даних: атомаршсть, узгодженiсть, iзольованiсть, довговiчнiсть [4]. Узгодженiсть даних була найважлившою з точки зору архiтекторiв i розробникiв баз даних. Bci реляцшш бази забезпечували той чи шший рiвень iзоляцii - або за рахунок блокувань при змiнi i блокуючого читання, або за рахунок undo-лопв. З появою величезних масивiв iнформацii' i розподiлених систем стало ясно, що забезпечення для них транзакцшного набору операцш з одного боку i отримання високо! доступност i швидкого часу вiдгуку з шшого - неможливо.
Виходячи з вищенаведеного, виконано аналiз iснуючих документо-орieнтованих (ДО) СКБД та вибiр базово! для системи вiзуалiзацii даних. На сьогодшшнш день iснуe досить багато ДОСКБД. Вони випускаються пiд рiзними лiцензiями та реалiзованi для використання на рiзних платформах, хоча деяш можуть використовуватись на декiлькох платформах одночасно. Незважакш на деякi вщмшносп, слiд зазначити, що кожна реалiзацiя документно! бази даних базуеться на основному понятт - «документ», яка описуе один запис у базi даних. При цьому допускаються рiзнi способи органiзацii зберiгання спискiв докуменпв.
Для системи вiзуалiзацii даних важливими при виборi документо-орiентованоi СКБД е наявшсть REST- та HTTP-API - яш дозволяють взаемодiяти з базою даних через протокол передачi даних HTTP, що досить зручно i дозволяе робити запити та отримувати даш, використовуючи HTTP запити: HTTP GET, POST, UPDATE та DELETE.
Досить часто при подальшому розвитку програмного продукту можливо створення самостшного
застосування, тому важливим е ктентський API, який дозволить взаeмодiяти з базою даних на бшьш високому рiвнi абстракци.
Незважаючи не те, що кожна реалiзацif документо-орiентованоf бази даних вiдрiзняеться у деталях, загалом, всi вони припускають, що документи iнкапсулюють i кодують данi (iнформацiю) у деяких стандартних форматах. Формати кодування включють XML, YAML, JSON(JavaScript Object Notation), i BSON, а також бiнарний формат, такий як PDF i документи Microsoft Office (MS Word, Excel i т. д.) [10].
Наприклад, документ може виглядати так:
{
FirstName:»Romanov», Address:»15 Okt Pr.», Hobby:»sailing»
}
1нший документ може бути:
{
FirstName:»Bulba», Address:»6 Krylova Str.», Children:[
{Name:»Leonid»,Age:12}, (Name:»Eugen», Age:10}, {Name:»Tamara», Age:7}, (Name:»Elena», Age:3}
]
}
Важливою характеристикою для обрання конкретно! ДОСКБД е можливють горизонтально! масштабованостi, тобто тдключення велико! кiлькостi клiентiв.
Неодмiнно треба звернути увагу на цiну та лщензш документо-орiентовано! СКБД. Оск1льки немае сенсу купувати дорогу систему для малого проекту, який не буде користуватися прившеями платних рiшень.
Важливим фактором е наявшсть документации За наявносл вичерпно! документацп досить легко розпочати використання системи та вивчати особливосп роботи з СКБД.
На додаток до вище перерахованих властивостей слад додати: наявшсть гнучко! мови для формування запитiв, наявнiсть динамiчних запитiв, наявнiсть вiзуальних застосувань керування базою даних, швидке додавання нових докуменпв та швiдка вибiрка незалежно ввд масштабу.
Необхiдно також враховувати к1льк1сть активних користувачiв, форумiв, блопв та iнших Internet-ресурсiв обрано! СКБД, оск1льки за наявностi чисельно! спiльноти легше знайти вiдповiдi на виникакта у процесi роботи з системою питання.
У таблицi 2 наведено порiвняння характеристик найбiльш поширених документо-орiентованих
СКБД.
Для реалiзацi! системи вiзуалiзацi! даних було обрано СКБД MongoDB з вiдкритим вихвдним кодом, яка не потребуе опису схеми таблиць. MongoDB займае шшу мгж швидкими i масштабованими системами, що оперують даними у формап ключ/значення, i реляцшними СКБД, функцiональними i зручними у формуванш запитiв. Код MongoDB написаний мовою C++ i поширюеться в рамках лщензи AGPLv3. GNU Affero General Public License ( загальна суспiльна лiцензiя Affero GNU) або 'GNU AGPL' — вшьна лiцензiя на програмне забезпечення, видана Фондом Втних Програм, та орiентована на сервернi веб-програми та веб-застосування. GNU AGPL подiбна до GNU GPL за винятком того, що мае додаткову секцiю, яка надае право отримати сирцевий код змшено! програми користувачам, як1 використовують !! через мережу.
У рамках дано! роботи виконана розробка системи вiзуалiзацi! даних реального часу. Головною задачею системи буде обробка подiй, прив'язаних до дати та часу. Система буде ввдповщати за збереження !х у документо-орiентовану базу даних MongoDB. На рис. 1 представлено функцюнальну модель системи та декомпозищю !! окремих модул1в (рис. 2 i 3) за стандартом IDEF0 [12].
В системi реалiзовано можливiсть приймати поди у стандартизованому форматi BSON та збертати !х у колекщях СКБД MongoDB, визначаючи необхiднi колекцп, спираючись на тип поди. Якщо колекцiя для визначеного типу не юнуе, необхвдно створити !! та колекцш для розрахованих метрик за типом поди.
Метрики у даному контекст е одним iз способiв обчислення властивостей системи, базуючись на збережених подiях, що представляють шгерес. Згрупувавши i звiвши !х до одного значення, можна отримати певш характеристики системи. Наприклад, якщо юнуе набiр подiй «request», можна обчислити число запипв в кожнiй п'ятихвилинний штервал часу, протягом останнього тижня. Цей показник, «sum(request)» сввдчить про штенсившсть запитiв з плином часу.
Таблиця 2.
Пор!вняння характеристик трьох ДОСКБД
""^-^СКБД NoSQL Критерш^-^^ CouchDB MongoDB OrientDB
REST-API HTTP-API Присутш Присутш HTTP
Кл!ентський API JavaScript, PHP, Ruby, Python i Erlang Java, JavaScript, C++, C#, PHP, Python, Perl, Ruby Java
Цша Безкоштовна Безкоштовна Безкоштовна
Популяршсть Висока Дуже висока Середня
Гнучка мова запипв Запити на мовах JavaScript та Erlang JavaScript та вбудована гнучка мова запипв Щдтримуе мову запипв SQL та Gremlin
Динашчш запити Hi Так Так
Пвдтримка АСГОвластивостей Гарантуе, при збереженш докуменпв через мехашзм MVCC, як PostgreSQL Оновлюе документ! на шсщ без реально! пвдтримки паралел!зму, що надае додаткову швидк1сть запису Повна тдтримка ACID-властиво стей
Р!вень горизонтально! масштабованосп Високий Дуже високий завдяки ввдсутносп паралел!зму Низький
Рис. 1. Функцюнальна модель системи
Рис. 2. Декомпозиция функцюнально! модел! системи на першому piBHi Розглянемо бшьш детально та проведемо декомпозицш процесу запуску серверу обробки даних на
рис. 3.
Рис. ЗДекомпозищя процесу запуску серверу обробки даних
На рис. 4 наведено д1аграму клаав [13] програмного забезпечення системи в1зуал1зацй'.
Головним способом взаемоди i3 застосуваннями е протокол передач! даних HTTP.
В систем! в!зуал!зацй е можливють робити запити подш i метрик, через HTTP GET запит або за допомогою WebSockets. Одшею з головних вимог е воображения даних, отриманих за допомогою запипв под!й та метрик, у реальному час!.
Для реал!зацй системи обрано мову програмування JavaScript та серверну реал!зац!ю мови Node.js, оскшьки вона добре !нтегруеться з MongoDB та може використовуватись у запитах.
Node.js - платформа з вщкритим вих!дним кодом для програмування серверно! частини застосувань на мов! JavaScript [14].
с mt CataVitualliatcniy-btHrTi
Рис. 4. Ддаграма клаав розроблено! системи
Для потоково!' передач1 даних була обрана технология WebSockets [15], оск1льки цю технолопю досить легко використовувати у прикладних програмах, застосовуючи мову JavaScript.
Одшею з головних вимог до розроблювано!' системи е ввдображення даних, отриманих за допомогою запипв подш та метрик, у реальному часг
Основш результати i висновки. Практичним результатом виконано! роботи е створена система в1зуал1заци даних реального часу, призначена для консолщацп й обробки шформацп про поди у високонавантажених веб-системах. Система використовуе документо-ор1ентовану СКБД MongoDB для збер1гання отриманих даних та JavaScript для обробки подш на сторош сервера, який запускаеться 1з застосуванням платформи Node.js.
Як приклад повсякденного застосування системи в1зуал1зацп реального часу можна привести можливють вщправки зр1з1в даних про обсяги i специф1ку траф1ку кожш 5 хвилин з подальшим анал1зом вах накопичених даних в наочному виглядг
1нший типовий варiант використання - протоколювання волатильностi курсу певно! валюти в режимi реального часу. При цьому слiд мати на уваз^ що моделi числових послвдовностей дозволяють не тiльки здiйснювати монiторинг хронологи поведшки певного показника, але також передбачати його iмовiрнiсну поведiнку в майбутньому на пiдставi вже накопичено! iнформацiï та автоматичного виявлення трендiв. Перевага системи складаеться в формуванш вiзуальноï загально! картини роботи системи в режимi реального часу.
Нажаль, чорно-бiлий формат представлення графiчного матерiалу не дозволяе наглядно представити результати приклади роботи системи вiзуалiзаiï даних.
ЛИТЕРАТУРА
1. Shashank Tiwari. Professional NoSQL. Indianapolis. John Wiley & Sons, Inc. - 2011. - 480 p.
2. Eelco Plugge, Peter Membrey and Tim Hawkins. The Definitive Guide to MongoDB. The NoSQL Database for Cloud and Desktop Computing. SpringerVerlag, New York. Apress, Inc. - 2010. - 328 p. - ISBN: 9781-4302-3051-9.
3. Document-oriented database. Режим доступу: URL: http://en.wikipedia.org/wiki/Document-oriented_ database. - Загол. з екрану.
4. Дейт К. Дж. Введение в системы баз данных, 7-е издание. : Пер. с англ. - М: Издательство «Вильямс», 2001. - 1072 с.
5. Кречетов Н.Е., Петухова Е.А., Скворцов В.И., Умников А.В., Щукин Б.А. Постреляционная технология CACHÉ для реализации объектных приложений. Учебное пособие. М.:МИФИ, 2001. - 152 с.
6. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. "The Google File System"; pub. 19th ACM Symposium on Operating Systems Principles, Lake George, NY, October 2003. URL: http://labs.google. com/papers/gfs.html.
7. Jeffrey Dean and Sanjay Ghemawat. "MapReduce: Simplified Data Processing on Large Clusters"; pub. 0SDI'04: Sixth Symposium on Operating System Design and Implementation, San Francisco, CA, December 2004. URL: http://labs.google.com/papers/mapreduce.html.
8. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar
Chandra, Andrew Fikes, and Robert E. Gruber. "Bigtable: A Distributed Storage System for Structured Data"; pub. OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November 2006. URL: http://labs.google.com/papers/bigtable.html.
9. Mike Burrows. "The Chubby Lock Service for Loosely-Coupled Distributed Systems"; pub. OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November 2006. URL: http://labs.google.com/papers/chubby.html.
10. NoSQL базы данных: понимаем суть: URL: http://habrahabr.ru/post/152477/. - Загол. з екрану.
11. Кунгурцев А.Б., Зиноватная С.Л. Изменение структуры реляционной базы данных для применения денормализации отношений // Вестник Херсонского национального технического университета. -Херсон, 2007. - №4(27). - С. 293 - 296.
12. Применение CASE-средства BPwin 4.0 для информационного моделирования в системах обработки данных [Текст] / Горин С.В. ; Тандоев А.Ю // СУБД /. - М., 1995. - №3. - С. 125-127.
13. Крэг Ларман. Применение UML 2.0 и шаблонов проектирования [Електронний ресурс] - 3-е изд. - М.: Вильямс, 2006. - 736 с. - Режим доступа: URL : http://www.williamspublishing.com/ Books/978-5-8459-1185-8.html - Загол. з екрану.
14. Pedro Teixeira. Professional Node.js: Building Javascript Based Scalable Software. Indianapolis, IN. John Wiley & Sons, Inc. - 2012. - 412 p.
15. WebSocket. Режим доступу: URL: http://ru.wikipedia.org/wiki/WebSocket. - Загол. з екрану.
Ф1СУН М.Т. - д.т.н., проф., завщувач кафедри штелектуальних шформацшних систем, Чорноморський
державний ушверситет iм. П. Могили.
Науковi штереси: бази даних, штелектуальш шформацшш системи, решжишршг, комп'ютерна лшгвютика.
КЛЮС С.С. - студент мапстратури кафедри штелектуальних шформацшних систем, Чорноморський
державний ушверситет iм. П. Могили
Науковi штереси: бази даних, штелектуальш шформацшш системи.
