Новий підхід до збереження слабоструктурованих медичних даних Текст научной статьи по специальности «Экономика и бизнес»

УДК 004.9:530.1

НОВИЙ П1ДХ1Д ДО ЗБЕРЕЖЕННЯ СЛАБОСТРУКТУРОВАНИХ МЕДИЧНИХ ДАНИХ

1.Б. Швороб1

У зв'язку зi швидким збiльшенням обсягу слабоструктурованих i неструктурова-них даних, питання про 1х оптимальне збереження е досить актуальним. Важливо зберь гати 1х в зручному формат для подальшого оброблення. Проте обробити неструктуро-ванi або слабоструктурованi даш складно через невизначенiсть у схемi даних. Щоб усу-нути цю проблему, здiйснено аналiз нереляцiйних баз даних та 1х застосування на реальному прикладi для збереження системи i оброблення медичних даних.

Ключовг слова: слабоструктуроваш данi, NoSQL, №о4], графовi бази даних, доку-менто-орiентованi бази даних.

Вступ. Швидке збшьшення обсягу шформацн зумовило пошук нових шдход1в до вир1шення проблеми з и збереження. Вважають, що нереляцшш бази даних (NoSQL) найбшьш придатш для збереження слабоструктурованих даних. NoSQL охоплюе широкий спектр технологш баз даних, розроблених зпдно з вимогами нових систем та !х потреб [1, 11]:

• розробники працюють у середовишД, що продукуе велику к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 архiтектури з використанням вiльного програмного забезпечення, розподiлених серверiв i хмарних обчис-лень замють великих монолiтних серверiв та шфраструктури зберiгання даних. Реляцшш бази даних не були розроблеш для того, щоб впоратися 1з проблемами, яю виникли сьогодш, не були побудоваш для того, щоб забезпечити паралел1зм даних, скористатися перевагами сховищ 1 обчислювально! потуж-ност1, доступних сьогодш.

Нереляцшш бази даних дшяться на кшька тишв залежно в1д можливост1 масштабування систем збер1гання, модел1 даних 1 запит1в. Основш види нереля-цшних баз даних: бази даних типу ключ/значення, документо-ор1ентоваш, стов-пчиково-ор1ентоваш та графов1 бази даних. Бази даних типу ключ/значення використовують для оргашзацн даних. Це дае змогу зберегти за певним ключем будь-як1 дан1 У документарно-ор1ентованих базах даних кожен запис збер1-гаеться у вигляд1 окремого документа, який мае свш власний наб1р пол1в. Стов-пчиково-ор1ентоваш бази даних збер1гають даш не як кортеж1, а як стовпш Для подання баз даних у вигляду граф1в, використовують вершини 1 ребра, як1 з'ед-

1 аспiр. 1.Б. Швороб - кафедра 1СМ, НУ " Льв1вська полггехнка"

нують !х [2]. Вибiр типу нереляцiйноi бази даних залежить вiд багатьох факто-рiв, зокрема й обрано! предметно! области

Пор1вняно з реляцiйними базами даних, бази даних NoSQL гнучкiшi у планi масштабування та забезпечують кращу продуктивнiсть, а також з допомо-гою !х моделей даних вдаеться вирiшити кiлька проблем, нетипових для кла-сично! реляцiйноi модели

• великi обсяги швидко змшюваних структурованих, слабоструктурованих i нес-труктурованих даних;

• чiткi часовi межi для опрацювання певного обсягу даних, швидка iтерацiя схе-ми, а також часп змiни коду;

• простота та зручтсть у використант для об'eктно-орieнтованого програмуван-ня;

• геогра<^чно розподiлена масштабована архиектура, замiсть дорого!', моноли-но! архiтектури.

Мета роботи - порiвняння та аналiз графових i документо-оркнтова-них баз даних, наведення приклад1в опрацювання та збереження даних для вщ-повiдних БД для медичних даних та об'еднання обох видш баз даних.

1. Отримання шформаци з деяких баз даних ШБОЬ

1.1. Документо-орieнтованi бази даних

Документо-орiентованi баз даних характеризуються тим, що в них нема схеми оргашзацп даних [3]. Це означае:

• сутносп не повиннi мати однорщну структуру, тобто рiзнi записи можуть мати рiзнi стовпцi;

• типи значень можуть бути рiзними для кожного запису;

• колонки можуть мати бшьше одного значення (масиви);

• записи можуть мати вкладену структуру.

Документо-орiентованi БД часто використовують внутршш позначення, якi можуть бути опрацьоваш безпосередньо в додатках, в основному 180№ JS0N-документи зазвичай також можуть бути збереженi у виглядi чистого тексту в ключ/значення-сховищах або реляцiйних системах управлшня базами даних. Проте таю документа вимагають оброблення структур на сторош клiента, а це, водночас, робить недоступними деякi можливосп, що надаються сховища-ми документiв (наприклад, вториннi iндекси).

Документи подаються у виглядi одно- або дворiвневих конструкцш типу ключ-значення. Можна сформувати документ будь-яко! складно!' структури iз збереженням можливостi !х використання у заданш системi управлiння. Незва-жаючи на потужний характер i можливiсть отримати записи окремих ключiв, системи управлшня на основi документiв мають сво! власнi проблеми пор1вня-но з iншими. Наприклад, отримання значення запису означае отримання вск! iнформацi! про запис. Те ж саме стосуеться оновлень, а це впливае на продук-тившсть. Данi i ввдношення не зберкаються в таблицях, е схожими на звичайш реляцiйнi бази даних, але насправдi представляють собою набiр незалежних до-кументiв.

Документо-орiентованi бази даних часто використовують для:

• ущ1льнено'1 шформаци — документи на 0CH0Bi сховища даних дають змогу пра-цювати з глибоко вкладеними, складними структурами даних.

• JavaScript-дружшх систем — одним з найважливших функщональних доку-ментiв на основi сховища даних е спосiб, яким вони взаемодшть з додатками: за допомогою JS-дружнього подання даних JSON.

Найвщомтими документо-орieнтованими базами даних е:

• CouchDB — документо-орiентована система управлшня базами даних, яка не потребуе опису схеми даних. Ця програма е вшьною, вiдкритою, написана на мовi Erlang [5].

• MongoDB — документо-орiентована система управлiння базами даних з вщкри-тим вихщним кодом, яка не потребуе опису схеми таблиць. Написана на мовi C ++. СУБД оперуе наборами JSON-подiбних документ, що зберiгаються у двшковому виглядi у форматi BSON.

С шють основних концепцiй для документо-орiентованих баз даних на прикладi MongoDB [4]:

1. MongoDB — концептуально те ж саме, що i звичайна реляцшна база. Всере-динi MongoDB може бути нуль або кшька баз даних, кожна з яких е контейнером для шших обfектiв;

2. База даних може мати нуль або бшьше "колекцш" (рис. 1). Колекщя настшь-ки схожа на традицшну "таблицю", що ii можна розглядати, як те ж саме;

3. Колекщя складаеться з нуля або бшьше "документ". Знову ж таки, цей документ можна розглядати як "рядок";

4. Документ складаеться з одного або кшькох "полiв", як можна розглядати як "стовпщ";

5. "1ндекси" в MongoDB практично щентичш шдексам у реляцшних базах да-них;

6. "Курсори" вiдрiзняються вiд попереднiх п'яти понять, але вони дуже важли-Bi (хоча iнодi це iгноруеться) i заслуговують окремого обговорення. Важли-во розумгги, що коли здiйснюеться запит будь-яких даних в MongoDB, по-вертаеться покажчик, за допомогою якого можна зробити що-небудь — роз-рахувати, пропустити певну кшьюсть попереднiх записiв — без завантажен-ня даних.

Схематичне подання документо-орiентованоí бази даних подано на

Рис. 1. Схематичне подання документо-opieHmoeaHo'i бази даних

Прикладом такого документа на 0CH0Bi обрано! предметно!' област (нес-

труктуроваш файли i3 вмiстом iнструкцiй до медичних лтв) у форматi JSON е: {

"title": "Levoryn",

"latin_title": "Levorinum",

"indication":[

"Candidiasis gastrointestinal tract", "Lesion of skin", "Mucosal lesions"], "contraindication":[ "Liver"

"Acute gastrointestinal diseases" "Gastric ulcer and duodenal ulcer" "Uterine bleeding"], "release_form":[

"Powder for external use", "Tablets 500 000 IU", "Tablets 500 000 IU", "2000000 IU powder", "cream in tubes of 30 meters"], "application_method":[

"Inside of 400,000-500,000 IU 2-3 times a day for 10-12 days"

"Children under 2 years are designated on the basis of 25 000 IU / kg per day"

"From 2 to 6 years - 20 000 IU / kg per day",

"After 6 years - in a single dose of 200,000-250,000 IU 3-4 times a day"]

}

де: title - назва препарату; latin_title - загальна назва латиною; indication - пока-зання для застосування; contraindication - протипоказання; release_form - форма випуску лшарського засобу; application_method - дозування.

1.2. База даних на ocHoei графiв

Графовi бази даних, також вiдомi як графо-орiентованi бази даних, - графи, подання даних в яких здшснюеться у виглядi структур, таких як вузли, та ребер, яю е вщношеннями мiж вузлами [6]. Таю бази даних дають змогу легко обробляти даш в цш формi i легко обчислити специфiчнi властивосп графiв, таких як довжина шляху ввд одного вузла до шшого.

Графо-орiентованi бази даних, як правило, не забезпечують вдекси для всiх вершин, прямий доступ до вузлш на основi значень атрибупв не е можли-вим у цих випадках. Моделi на основi графових баз даних використовують де-ревовиднi структури (тобто графи) з вузлами i ребра, що з'еднують мiж собою через ввдношення (рис. 2).

Деяк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 бази даних використовують для:

• опрацювання складно'1 реляцшно\' шформацп - бази даних на 0CH0Bi графiв роб-лять цей процес надзвичайно ефективним i простим у використанш 3i складни-ми структурами даних, але не мають реляцшно\' шформацп, наприклад, зв'язкiв мiж двома об'ектами i рiзними ступенями iнших суб'екпв, опосередковано по-в'язаних з ними.

• моделювання та класифкащя - графо-орiентованi бази даних стануть найкра-щим рiшенням у будь-якш ситуаци, де беруть участь вщношення. Моделювання даних i класифiкацiя рiзноl шформацп, що зв'язана реляцшним чином, можуть бути оброблеш дуже добре за допомогою цього типу сховищ даних. Найвщом^ графовi бази даних:

• Neo4J пропонуе повноцiнну базу даних iз транзакцiями, iндексами, кiлькома режимами роботи i простотою вивчення, завдяки дуже легкiй структурi [7]. Весь код вщкритий i доступний, i програма розповсюджуеться пiд лiцензiею AGPL для некомерцшного використання, а також е платш варiанти для комерцшного.

• AllegroGraph е сучасною, високопродуктивною, постiйною графовою базою даних [8]. AllegroGraph використовуе ефективне використання пам'ят в поеднан-нi зi зберiганням на основi жорстких дисюв, що дае змогу йому масштабувати до мiльярдiв квадрациклiв, зберiгаючи при цьому високу продуктивнють. AllegroGraph шдтримуе SPARQL, RDFS++ i лопку Prolog для великого числа кшент-ських програм.

2. Документ на основi бази даних графа

Шд час роботи зi слабоструктурованими даними важливо зберегти яко-мога бiльшу '1х ктьюсть у найшвидшiй для використання форм1 База даних на основi документо-орieнтованого графа включае складнiсть вузла графа даних, тобто, коли вузлом е елемент з багатьма рiзними характеристиками.

Прикладами такого роду баз даних е ОпейёЬ, СоисЮВ, №о4 ] [10]. Та-ка реалiзацiя використовуе документ для забезпечення гнучкостi запипв до гра-

Рис 2. Схематичне подання графово'1 бази даних

фових баз даних, а збереження у виглядi ключ/значення забезпечуе швидкий пошук даних. Об'ект G тако'1 бази даних можна подати так:

G = {<N, E>}, (1)

де: N - вершина графа, E - множина ребер,

E = {<e_1,..., e_n>}. (2)

З огляду на те, що документ використовуе спрямований граф, то вузол графа можна подати у виглядi об'екта, який мютить множину параметрiв типу ключ/значення, наприклад,

N = {<k, v>}. (3)

Отже, документо-орiентований граф можна подати у такому виглядi:

G = {<{k, v}, {e_1,..., e_n}>}. (4)

На рис. 3 показано схематичне подання документо-орiентованого графа.

Рис. 3. Схематичне подання документо-opicHmoeaHozo графа

Розглянемо приклад збереження та оброблення даних про лкарсью засо-би (рис. 4), побудувавши документо-орiентований граф на основi бази даних Neo4 j [9].

Створенi вершини графа будуть двох типiв: препарати i хвороби (пока-зання та протипоказання). Ребра також будуть двох титв: показання та проти-показання. Наступний приклад показуе створення вузла i ребер для медичних препаратiв. Оскшьки це документо-орiентований граф, то тд час створення вершин вказуемо додатковi характеристики.

CREATE (Levorinum:Antibiotic {title:'Levoryn', latin_title:lLevorinuml, release_form: 'Tablets 500 000 IU',

application_method:lInside of 400,000-500,000 IU 2-3 times a day for 10-12 days'})

CREATE (Candidiasis:Disease {name: Candidiasis gastrointestinal tract'})

CREATE (SkinLesions:Disease {name: Lesion of skin'})

CREATE (MucosalLesions:Disease {name: Mucosal lesions'})

CREATE (Liver:Disease {name: Liver illness})

CREATE (stomach:Disease {name: Acute gastrointestinal diseases'})

CREATE (ulcer:Disease {name: Gastric ulcer and duodenal ulcer'})

CREATE (uteineBleeding:Disease {name: Uterine bleeding'})

CREATE

(Candidiasis)-[:INDICATION]->(Levorinum), (SkinLesions)-[:INDICATION]->(Levorinum), (MucosalLesions)-[:INDICATION]->(Levorinum), (Liver)-[:CONTRAINDICATION]->(Levorinum),

(Stomach)-[:CONTRAINDICATION]->(Levorinum),

(Ulcer)-[:CONTRAINDICATION]->(Levorinum),

(UteineBleeding)-[:CONTRAINDICATION]->(Levorinum)

Внаслiдок цього отримаемо граф з десяти препаратiв (рис. 5).

Рис. 4. Документо-орieнтований граф для системи збереження та оброблення тформаци про медичш препарати

Запити в щй базi даних будуть виглядати таким чином. Припустимо, що потрiбно знайти лiки при показаннi до застосування у виглядi деяко!' шфекцп (див. рис. 5):

MATCH (p:Disease)-[r:INDICATION]->(m:Antibiotic) WHERE p.name = "Infection" RETURN p, r, m

Рис. 5. Результат виконання запиту при заданш певноХ умови При виборi препарапв потрiбно враховувати не тшьки показання, але i протипоказання. Нехай протипоказаш гострi шлунково-кишковi захворювання. Такий запит буде виглядати так:

MATCH (p:Disease)-[:INDICATION]->(m:Antibiotic)<-[:CONTRAINDICATION]-(pc:Disease) WHERE p.name = "Infection" AND NOT pc.name = "Acute gastrointestinal diseases" RETURN m.latin_title

ВнаслДдок цього отримаемо множину з трьох медичних препаратдв: Lata-moxef, Tetracyclin, Lincomycin. Отже, база даних на основi документо-орДенто-ваного графа в цьому випадку е дуже зручним засобом для збереження даних. Вважаеться, що при виборi препаратiв потрiбно враховувати не тДльки показания та протипоказання, а також iншi фактори, таю як дозування, вiк i вага па-цiента та ш Подальшi дослiджения будуть спрямованi на розширення та опти-мiзацiю базу даних для врахування цих фактордв.

Було здiйснено аналiз оброблення слабоструктурованих даних для рДз-них тишв баз даних (табл.). Аналiз проводився за такими параметрами: юль-юсть створюваних об'ектiв (документiв або вузлiв) (N), вага бази даних (W), час запису в базу даних (t), час виконання запиту з юлькома умовами (tc). Пiд час аналiзу було використано 100 шструкцш для медичних препаратiв.

Табл. Результата аналЬу оброблення слабоструктурованих даних

N W(M6) t(Mc) tc(MC)

Документо-оркнтована БД 100 40.2 10 2

Графова БД 740 30.9 15 1.4

Документо-орieнтований граф 740 61.1 20.72 1.3

Висновок

РозглянутД бази даних не е однотипними, але в бiльшостi випадюв засто-совуються в одних i тих же цiлях. Хоча для цього використовуються рiзнi засо-би. Варто також звернути увагу, що БД, яю так чи Днакше використовують принцип ключ/значення, як правило, дають об'ектно-орiентований iнтерфейс для програмДста.

Вибiр мiж технологiями NoSQL залежить вiд багатьох факторiв (постановка завдання, квалiфiкацiя розробника, особливостi вимог до обладнання, швидкодiя i т. Дн.), тому однозначно! рекомендащ! щодо того, яка база даних повинна бути використана, не може бути надано. Проте вважаеться, що розгля-нутД типи баз даних використовують нову i достатньо прогресивну технологДю, яка за багатьма показниками випереджае перевiренi часом релящйш бази даних (MS SQL, MySQL, Oracle тощо), яю вже десятки роюв займають передовi пози-цп на ринку БД. Зважаючи на лавиноподiбне зростання користувачiв 1нтернету та у зв'язку зД збДльшенням навантаження на сховища даних, варто, можливо, переглянути класичнД пДдходи до реалДзацД! баз даних та звернути увагу на новД технологи, яю пропонуе IT-сшльнота.

1стотною перевагою зберДгання даних в документо-оркнтованш базД даних е зручнДсть для подальшого оброблення даних. Однак запити будуть склад-ними i при запитД може прийти набагато бДльше шформацп, нДж це потрДбно. Це, водночас, впливае на продуктивнДсть. Даш в графовДй базД даних займають великий обсяг. Час оптимДзацД! бази даних графа е бДльшим. ГрафовД бази даних значно домДнують над реляцшними у разД пошуку в реальному часД з великими обсягами даних. Отже, графовД бази даних потрДбно використовувати за наяв-ностД великих обсягДв даних i ресурсдв, за умови, що швидке виконання пошуку е дуже важливим.

Залежно ввд вимог до проекту та для оптимЬацц i пришвидшення робо-ти iз великими обсягами даних потрiбно використовувати вiдповiднi бази да-них. Наприклад, для програмного рiшення дуже важливим е швидкий пошук, тому для цього можна використати графову базу даних. В окремих випадках можна комбiнувати пердставлення даних у виглядi документо-орiентованих графових баз даних.

Лiтература

1. NoSQL Database Couchbase. [Electronic resource]. - Mode of access http://www.couchba-se.com/nosql-resources/what-is-no-sql

2. Ljalyk O. NOSQL Storage Systems: Comparative Analysis and the Pro-spects for Their Usage in Educational Portals / O. Ljalyk, V. Mandzjuk // Scientific notes of Ternopil National Pedagogical University. Pedagogy. - Ternopil. - 2011. - Vol. 1. - Pp. 234-241.

3. Banker K. MongoDB in action / K. Banker. - Manning, NY, 2012. - Pp. 288.

4. The MongoDB 3.2 Manual. Technical documentation. - 2016. [Electronic resource]. - Mode of access http:// docs.mongodb.com/manual/

5. CouchDB Technical documentation - 2016. [Electronic resource]. - Mode of access http:// docs.couchdb.org/en/1.6.1/intro/why.html

6. Renzo A. Survey of Graph Database Models / A. Renzo, C. Gutierrez // ACM Computing Surveys. - 2008. - Vol. 40, No. 1. - Pp. 123-129.

7. Glibovets, A.M. Comparison Neo4 and relational database MySQL. PROCEEDINGS / A.M. Glibovets, A.O. Dobriansky // Computer Science. - 2015. - Vol. 177. - Pp. 108-112.

8. Franz, Incorporated: AllegroGraph.Technical documentation (2016). [Electronic resource]. -Mode of access http://franz.com/agraph/support/documentation/current/agraph-introduction.html

9. Robinson I. Graph Databases / I. Robinson, J. Webber, E. Eifrem // O'Reilly Media, Inc. -2015. - Pp. 25-53.

10. Buerli M. The Current State of Graph Databases / M. Buerli // Cal Poly San Luis Obispo, 2012. - Pp. 123-129.

11. Planet Cassandra. [Electronic resource]. - Mode of access http://www.planetcassandra.org/ what-is-nosql/

Надшшла до редакцп 26.06.2016р.

Швороб И.Б. Новый подход к сохранению слабоструктурированных медицинских данных

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

Ключевые слова: слабоструктурированные данные, NoSQL, Neo4 j, графовые базы данных, документо-ориентированные базы данных.

Shvorob I.B. New approach to maintaining health semistructured data

In connection with the rapid increase in the volume semistructured and unstructured data, the question of optimal saving is quite important. In optimal storage, it is important saving them in a convenient format for further processing. However, the processing of unstructured and semistructured data is difficult to implement because of the uncertainty in the data schema. To resolve this issue done some review and analysis of non-relational databases and their applications are on a real example for system preservation and processing of information about medicines.

Keywords: semistructured data, NoSQL, Neo4 j, Graph database, document-oriented database.