Концепція зберігання великих даних

1. Обробка надвеликих
масивів даних
Лекція5: Концепція зберігання
великих даних

2. Термінологія
Розглянемо ключові концепції, пов'язані зі
зберіганням масивів даних для великих
даних.
Ці концепції дають інформацію про те, що
зберігання великих даних має
характеристики, що радикально
відрізняються, від технології зберігання в
реляційних базах даних, властивих
традиційним інформаційним системам.

3. Зберігання великих даних
Дані, отримані із зовнішніх джерел, часто бувають не в
тому форматі або не в тій структурі, які можуть бути
безпосередньо оброблені.
Щоб перебороти ці несумісності й підготувати дані для
зберігання й обробки, необхідно виконати
перетворення сирих даних. Перетворення даних
містить у собі кроки з фільтрації, очищенню й інших
способів підготовки даних для їхнього наступного
аналізу.
З погляду зберігання, копія даних спочатку зберігається
в її первісному форматі, і потім перетворені дані
потрібно зберегти знову.

4. Зберігання великих даних
Як правило, зберігання потрібно щоразу , коли відбувається наступне:
- отриманий зовнішній масив даних або внутрішній масив даних будуть
використовуватися в середовищі обробки великих даних;
- при виконанні дій з даними для того, щоб їх можна було
використовувати для аналізу даних;
- при обробці даних за допомогою застосування ETL, або коли
згенеровані результати при виконанні аналітичної операції.
Через необхідність зберігання масивів даних великого обсягу, часто в
декількох екземплярах, були створені інноваційні стратегії зберігання й
технології для досягнення економічних і маштабованих рішень по зберіганню
даних. Для того, щоб зрозуміти основні механізми технології зберігання
великиих даних, мии розглянемо наступні теми:
- кластери;
- файлові системи й розподілені файлові системи;
- NoSQL бази даних;
- шардинг;
- реплікація;
- CAP теорема;
- ACID - сукупність властивостей (Atomicity, Consistency, Isolation,
Durability);

5. Кластер
При обчисленні кластер являє собою тісно зв'язану сукупність серверів або
вузлів (компютерів) . Ці сервери, як правило, мають однакову апаратну
специфікацію й з'єднані разом через мережу для роботи як єдиний блок, як
показано на малюнку 5.1. Кожний вузол у кластері має свої власні виділені
ресурси, такі як пам'ять, процесор і жорсткий диск. Кластер може виконувати
задачу, розбиваючи її на дрібні складові й розподіляючи їхнє виконання на
різних комп'ютерах, що належать кластеру.
Один кластер

6. Файлові системи й розподілені файлові
системи
Файлова система - це спосіб зберігання й організації
даних у запам'ятовуючому пристрої, такому як флеш-
накопичувач, DVD-диски й жорсткі диски. Файл - це
неподільна одиниця зберігання, використовувана
файловою системою для зберігання даних. Файлова
система забезпечує логічне подання даних, що
зберігаються на запам'ятовуючому пристрої, і
представляє його у вигляді деревоподібної структури
каталогів і файлів, як показано на малюнку 5.2.
Операційні системи використовують файлові системи
для зберігання й зчитування даних за дорученням
застосунків. Кожна операційна система підтримує
одну або кілька файлових систем, наприклад NTFS в
Mіcrosoft Wіndows і ext в Lіnux.
 Малюнок 5.2. Позначення, використовуване для
подання файлової системи.

7. Розподілена файлова система - файлова
система, що може зберігати великі файли,
розподілені по вузлах кластера, як показано
на малюнку 5.3. Для клієнта файли
виглядають як локальні об'єкти; однак це
тільки логічне подання, тому що фізично
файли розподілені по усьому кластері. Ці
локально відображувані елементи
представлені завдяки розподіленій файловій
системі, що дозволяє здійснювати доступ до
файлів з різноманітних місць. Прикладами
можуть бути файлова система Google (GFS) і
розподілена файлова система Hadoop
(HDFS).
Файлові системи й розподілені файлові системи

8. Рис. 5.3 Позначення, використовуване для подання розподілених
файлових систем.
Файлові системи й розподілені файлові системи

9. Hadoop – в загальних словах це файлова система HDFS та набір
інструментів для оброблення даних.
Файлові системи й розподілені файлові
системи
Hadoop — вільна програмна
платформа і платформа для
організації розподіленого зберігання і
обробки наборів великих даних з
використанням моделі програмування
MapReduce, при якій завдання ділиться
на багато дрібніших відособлених
фрагментів, кожен з яких може бути
запущений на окремому вузлі кластера
що складається з серійних комп'ютерів
.
Ядро системи Apache Hadoop складається з розподіленої файлової системи Hadoop Distributed Filesystem (HDFS), та
системи обчислень на основі моделі програмування MapReduce.
Основний фреймворк Hadoop складається з наступних модулів:
Hadoop Common – містить бібліотеки та утиліти потрібні іншим модулям Hadoop;
Hadoop Distributed File System (HDFS) – розподілена файлова система, яка зберігає дані на звичайних машинах,
надаючи дуже високу загальну пропускну здатність на кластері загалом;
Hadoop YARN – платформа що відповідає за керування обчислювальними ресурсами в кластерах і їх використання
для користувацьких завдань.
Hadoop MapReduce – реалізація моделі програмування MapReduce для обробки великих об'ємів даних.

10. База даних типу NoSQL є не реляційною базою даних, що відрізняється
високою масштабованістю, відмовостійкістю й розроблена спеціально
для зберігання напівструктурованих і неструктурованих даних.
База даних типу NoSQL найчастіше забезпечується інтерфейсом запиту,
заснованим на APІ, що може викликатися за допомогою застосування.
База даних типу NoSQL також підтримує мови запитів відмінні від
структурованої мови запитів SQL, оскільки SQL був розроблений для
запиту тільки структурованих даних, що зберігаються в реляційній базі
даних.
Як приклад, база даних типу NoSQL, що оптимізована для зберігання XML-
файлів, часто використовує XQuery як мову запитів. У такий же спосіб,
база даних типу NoSQL, розроблена для зберігання RDF-даних буде
використовувати мову SPARQL для запиту відношень, які вона містить.
Як багато хто затверджує, існують деякі бази даних типу NoSQL, які також
забезпечуються SQL-подібним інтерфейсом запиту, як показано на рис.
5.4.
NoSQL

11. NoSQL
Рис. 5.4. База даних типу
NoSQL може забезпечуватися
APІ- або SQL-подібним
інтерфейсом запиту.
NoSQL (зазвичай
розшифровується як "non SQL",
"non relational" or "not only SQL" -
англ. не тільки SQL ) - база
даних, що забезпечує інший
механізм зберігання та
видобування даних, ніж звичний
підхід таблиць-відношень в
реляційних базах даних.
Поява NoSQL була спричинена потребами Web 2.0 компаній, такими як
Facebook, Google, та Amazon.com. NoSQL бази даних все більше і більше
використовуються в задачах із застосуванням big data та real-time web
застосунках. NoSQL системи також називають "Not only SQL" (англ. not only
SQL — не тільки SQL) для підкреслення того, що вони можуть підтримувати
SQL-подібну структуру та мову запитів.

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

13. Шардинг
Sharding - це процес збереження записів даних на декількох машинах. З його
допомогою БД може горизонально маштабуватись. Так як розмір даних збільшується,
однієї машини може бути недостатньо, щоб зберігати дані, забезпечуючи високу
швидкість зчитувантня і запису. Шардінг вирішує цю проблему. З шардінгом можна
додати нові машини, щоб підтримати зростання даних і вимоги операцій читання і
запису.
Шард(Shard) - це екземпляр БД, що містить підмножину даних колекції. Кожен shard
являє собою повторюючу копію(Replica Set).
БД розподіляє дані, або шарди, на рівні колекції. Sharding розбиває колекцію
даних по шард-ключу(Shard key).
Шардинг - це процес горизонтального поділу великого масиву даних на
колекцію менших, які є більш керованими й називаються шардами. Шарди
розподілені серед множини вузлів, де вузол - це сервер або комп'ютер (рис.
5.5). Кожен шард зберігається на окремому вузлі, і кожен вузол
відповідальний тільки за дані, що зберігаються на ньому. Кожен сегмент
спільно використовує одну і ту саму логічну структуру в базі даних, і всі
разом шарди являють собою повний набір даних.

14. Шардинг
Рис. 5.5 Приклад
розбиття, де масив даних
розподіляється між
вузлами A і B, у
результаті чого виходить
шард A і шард B
відповідно.
Шардинг часто є
прозорим для клієнта,
однак це не є
обов'язковою вимогою.
Шардинг дозволяє
розподіляти
навантаження з обробки
між декількома вузлами
для досягнення
горизонтальної
масштабованості.

15.  Горизонтальне масштабування - це спосіб збільшення
продуктивності системи за рахунок додавання
аналогічних або потужніших ресурсів поряд з існуючими
ресурсами. Оскільки кожен вузол відповідає тільки за
частину всього масиву даних, то при цьому час
читання/запису значно покращується.
Підтримання збалансованого розподілу даних
Додавання нових даних чи додавання нових серверів може спричинити дизбаланс в кластері, деякі
шарди можуть стати значно "важчими" за решту.
БД впровадили два фонові процеси: розбивання і балансування.
Розбивання
Розбивання - це фоновий процес який контролює розмір шардів. Коли один блок
перевищує встановлені в конфігураційному сервері розміри БД його розбиває на
менші шарди. При чому спрацьовують тригери і автомарично оновлюються метадані
конфігураціних серверів.
Балансування
Балансування - фоновий процес який відповідає за переміщення блоків даних(chunks). Балансування може бути
запущене з будь якого router'а в кластері. Коли в одному шарді накопичується багато блоків то ці блоки
переміщуються до інших шардів. Наприклад: Якщо відношення Користувачі має 100 блоків на shard 1 і 50 блоків
на shard 2, то балансувальник змістить частину блоків з першого на другий шард.
Шардинг

16. Шардинг
Рис. 5.6 ілюструє, як працює
сегментування на практиці:
1. Кожний сегмент може
незалежно обслуговувати операції
читання й запису для певної
підмножини даних, за які він
відповідає.
2. Залежно від запиту дані
можуть бути обрані з обох
сегментів.
Рис. 5.6 Приклад
сегментування, де дані
витягають із обох вузлів A і B.

17.  Перевагою шардинга є те, що він забезпечує
часткову відмовостійкість до збоїв. У випадку
збою вузла, тільки ті дані, що зберігаються на
цьому вузлі піддаються руйнуванню. Що
стосується розбивки даних, то необхідно
враховувати шаблони запитів, щоб самі
сегменти не ставали вузькими місцями
продуктивності.
 Наприклад, запити, що вимагають дані з
декількох сегментів, накладають обмеження на
продуктивність. Локальне розміщення даних
дозволяє зберігати загальнодоступні дані,
розташовані в одному сегменті, і допомагає
протистояти таким проблемам із продуктивністю.
Шардинг

18. Реплікація
Реплікація (фр. replique — знову, ще прикладаю,
з лат. replicо, також англ. replication) — у різних галузях
науки і техніки термін, що означає процес
створення копій.
Реплікація зберігає сукупність копій наборів даних, відомих
як "репліки", на декількох вузлах (рис. 5.7).
Реплікація забезпечує масштабованість і доступність
завдяки тому факту, що одні і ті самі дані реплікуються на
різних вузлах. При цьому також досягається
відмовостійкість, оскільки надмірність даних гарантує, що
дані не будуть загублені у випадку, коли окремий вузол
виходить із ладу. Для реалізації реплікації
використовуються два різних методи:
 ведучий-відомий (master-slave) головний сервер
(майстер-сервер)

19. Реплікація
Рис. 5.7 Приклад
реплікації, де набір
даних реплікується у
вузол A і вузол B, у
результаті виходить
репліка A і репліка B.

20. Режим реплікації "ведучий-відомий"
Під час односпрямованого режиму реплікації "ведучий-
відомий" вузли розміщаються в конфігурації ведучий-
відомий, і всі дані записуються в головний вузол. Після
збереження дані реплікуються на кілька підлеглих вузлів.
Усі зовнішні запити на запис, включаючи вставку,
відновлення й видалення даних, відбуваються на
головному вузлі, у той час, як запити на читання можуть
виконуватися будь-яким підлеглим вузлом. На рис. 5.8
керування записом здійснюється головним вузлом, і дані
можуть зчитуватися або з веденого (підлеглого) вузла А,
або з веденого (підлеглого) вузла В.
Реплікація

21. Реплікація
У веб застосуваннях зазвичай домінують запити на отримання
інформації - читання коментарів, постів, призначених для користувача даних і
т.д. Таким чином слабким місцем є операція читання і саме її потрібно
масштабувати. Для вирішення цього завдання використовується механізм
реплікації - один сервер призначається головним (майстер-сервером) і виконує
всі запити модифікації даних, а інші сервери (слейв) обробляють тільки запити
отримання даних. При зміні або додаванні даних, майстер-сервер повідомляє
всі слейв-сервери, таким чином підтримуючи актуальність даних.
Крім того, реплікація використовується для географічного розподілу
серверів (наприклад один сервер в Америці, інший в Європі).
Принцип роботи реплікації
Майстер-сервер при виконанні модифікацій пише всі зроблені зміни в
лог, slave-сервери з певною періодичністю перевіряють лог на предмет появи
нових даних і якщо вони є - виконують аналогічні дії зі своїми даними.
Важливим питанням для розподілених систем є реплікація даних. Дані звичайно
реплікуються для підвищення надійності й збільшення продуктивності. Одна з основних
проблем при цьому - збереження несуперечності реплік. Якщо в одну з копій вносяться
зміни, то необхідно забезпечити, щоб ці зміни були внесені й в інші копії, інакше репліки
більше не будуть однаковими.
Деталі - http://moodle.ipo.kpi.ua/moodle/mod/resource/view.php?id=6195
Реплікація

22. Режим реплікації "ведучий-відомий"
Рисунок 5.8 Приклад
однонаправленого режиму
реплікації " ведучий-відомий"
, де ведучий вузол А є
одноточковим контактом для
всіх функцій запису, а дані
можуть зчитуватися з
відомого вузла А і з відомого
вузла В.
Режим однонаправленої
реплікації " ведучий-відомий
" ідеально підходить для
читання інтенсивних
завантажень у більшій мірі
(наприклад, у сфері Веб),
ніж для запису інтенсивних
завантажень, оскільки
зростаючі вимоги до
читання можуть керуватися
за допомогою
горизонтального
масштабування через
додавання додаткових

23. Режим реплікації "ведучий-відомий"
Записи є погодженими, оскільки всі записи координуються головним
вузлом. Це означає, що продуктивність запису буде погіршуватися в
міру збільшення обсягу запису.
Якщо ведучий вузол вийде з ладу, то читання як і раніше буде
можливим через кожен відомих вузлів.
Слайв-вузол може бути зконфігурованим як резервний вузол для
мастер-вузла. І у випадку збою основного вузла запис не буде
підтримуватися доти, поки майстер-вузол не буде відновлений.
Майстер-вузол відновлюється або з резервної копії ведучого вузла,
або з підлеглих вузлів вибирається новий ведучий вузол. Одна із
проблем, пов'язаних з однонаправленим режимом реплікації "
ведучий-відомий", - це неузгодженість читання, що може бути
проблемою, якщо слайв-вузол читається до відновлення майстер-
вузла, який його копіює.

24. Сценарій неузгодженості читання
Рис. 5.9 ілюструє
сценарій, якому виникає
неузгодженість читання.
1. Користувач А обновляє
дані.
2. Дані копіюються на
слайв-вузол А майстер-
вузлом.
3. Перед копіюванням
даних на слайв-вузол В,
користувач В намагається
прочитати дані слайв-
вузла В, що приводить до
неузгодженого зчитування.
4. В остаточному підсумку
дані стануть погодженими,
коли слайв-вузол В буде
оновлено майстрер-
вузлом.

25. При реплікації в режимі "одноранговий" усі вузли працюють на одному
рівні. Інакше кажучи, між вузлами немає відносин " ведучий-відомий".
Кожен вузол, є одноранговим вузлом, який рівною мірою здатен
обробляти операції читання й запису. Кожен запис копіюється всім
одноранговим вузлам, як показано на рис. 5.10.
Режим реплікації "одноранговий"
Рис. 5.10. Дані для
запису копіюються
в однорангові
вузли A, B і C
одночасно. Дані
зчитуються з
однорангового
вузла A, але їх
також можна
зчитувати з
однорангового
вузла B або вузла
C.

26. Режим реплікації "одноранговий"
Однорангова реплікація піддається помилкам запису, що виникають у
результаті одночасного відновлення одних і тих самих даних
декількома одноранговими вузлами. Цю проблему можна розв'язати
шляхом реалізації або песимістичної або оптимістичної стратегії
розпарелелювання.
• Песимістичний паралелізм являє собою стратегію
попередження, яка запобігає неузгодженості. Вона використовує
блокування для гарантії того, що тільки одне оновлення на запис може
відбуватися одночасно. Однак це завдає шкоди доступності, оскільки
обновлюваний запис бази даних залишається недоступним доти, поки
не будуть звільнені всі блокування.
• Оптимістичний паралелізм - це реактивна стратегія, яка не
використовує блокування. Замість цього вона допускає
неузгодженість свідомо знаючи, що в остаточному підсумку
погодженість буде досягнута після того, як усі оновлення поширяться.
При оптимістичному паралелізмі однорангові вузли можуть
залишатися неузгодженими протягом деякого періоду часу, перш ніж
досягнуть узгодженості. Однак база даних залишається доступною,
оскільки блокування не було задіяне.

27. Режим реплікації "одноранговий"
Для забезпечення погодженості читання, там може бути реалізована
система голосування в тому випадку, якщо читання оголошене
погодженим, а більшість однорангових вузлів містять одну і ту саму
версію запису. Впровадження такої системи голосування вимагає
надійного й швидкого механізму обміну даними між одноранговими
вузлами.

28. Режим реплікації "одноранговий"
Рис. 5.11 Приклад
однорангової реплікації, коли
відбувається неузгоджене
читання.
Рис. 5.11 демонструє
сценарій, коли відбувається
неузгоджене читання.
1. Користувач А обновляє
дані.
2. a. Дані копіюються в
одноранговий вузол A.
b. Дані копіюються в
одноранговий вузол B.
3. Перш ніж дані будуть
скопійовані в одноранговий
вузол C, користувач B може
спробувати прочитати дані з
однорангового вузла З, що
приведе до неузгодженого
читання.
4. В остаточному підсумку
дані будуть оновлені на
одноранговому вузлі C, і база
даних знову стане
погодженою.

29. Шардинг і реплікація
Для поліпшення обмеженої
відмовостійкості,
забезпечувану за допомогою
використання прийомів
шардинга, а також для
одержання додаткових
переваг від підвищеної
доступності й
масштабованості реплікації,
можна комбінувати як
шардинг, так і реплікацію, як
показано на рис. 5.12.
Рис. 5.12. Порівняння шардинга й
реплікації, що показує, як набір
даних розподіляється між двома
вузлами з різними підходами.

30. Теорема CAP
Теорема про узгодженість, доступність і стійкості при розбитті (CAP),
також відома як теорема Брюера, виражає потрійне обмеження,
пов'язане з розподіленими системами баз даних. Вона стверджує, що
розподілена система баз даних, яка працює в кластері, може
забезпечити тільки дві з наступних трьох властивостей:
• Погодженість - читання даних з будь-якого вузла приводить до
таких же даних, що знаходяться на декількох вузлах (рис. 5.15).
Рис. 5.15. Погодженість: усі три
користувачі одержують однакові
значення для суми стовпця, навіть
якщо три різні вузли обслуговують
операцію запису.

31. Теорема CAP
Наслідки
З точки зору теореми, розподілені системи в залежності від пари забезпечених властивостей
діляться на три класи:
CA
Розподілена система в якій забезпечена доступність та узгодженість даних не може забезпечувати
стійкість до розбиття.
Прикладом такої системи є програмне забезпечення що підтримує ACID вимоги, наприклад реляційні
бази даних.
AP
Розподілена система в якій не гарантується цілісність результату, зате висока доступність і
збереження працездатності при розділенні.
Звісно такі системи з'явилися значно раніше формулювання CAP теореми, як то наприклад DNS, але
ріст популярності збігається з розповсюдженням даного принципу (зокрема деякі NoSQL системи не
гарантують цілісність результату, посилаючись на дану теорему).
CP
Система що забезпечує цілісність даних на всіх вузлах і здатність працювати при розділенні, але не
гарантує доступність і може не відповідати на запити.
Прикладами таких систем є розподілене програмне забезпечення фінансових систем, де
узгодженість даних має найвищий пріоритет, це наприклад, мережа банкоматів.

32. Доступність
• Доступність. Запит на читання/запис завжди буде підтверджений у
вигляді успіху або відмови (рис. 5.16).
Рис. 5.16. Доступність і стійкість при розбитті: у випадку порушення обміну
даними запити від обох користувачів усе ще обслуговуються (1, 2). Однак у
користувача B запис не виконується, тому що запис із іd = 3 не була скопійована в
одноранговий вузол C. Користувач вчасно був сповіщений (3) про те, що
оновлення не вдалося.
Partition A –
разбиття А; Partition
В – разбиття В
read - читання;
іnsert - вставка;
update - оновлення;
operatіon faіled -
операція не
виконалася;

33. Применение Data Mining для решения бизнес-задач
• Стійкість при розбитті.
Система бази даних може бути відмовостійкою при збоях обміну
даними в процесі розбиття кластера на кілька сховищ даних і при
цьому може обслуговувати запити читання/запису (рис. 5.16).

34. Діаграма Венна з узагальненням теореми CAP
 Наступні сценарії демонструють, чому одночасно можуть
підтримуватися тільки дві із трьох властивостей теореми CAP. Щоб
допомогти цій дискусії, на рис. 5.17 представлена діаграма Венна,
що показує зони перекриття між погодженістю , доступністю й
стійкістю при розбитті.
Рис. 5.17. Діаграма Венна з
узагальненням теореми CAP.
[consіstency - погодженість;
avaіlabіlіty - доступність ;
partіtіon tolerance - стійкість
при розбитті; not possіbble -
не можливо]
Якщо потрібні погодженість (C) і
доступність (A), то доступні вузли
повинні зв'язуватися для забезпечення
погодженості (C). Тому блочне
розбиття (P) неможливе.

35. Діаграма Венна з узагальненням теореми CAP
Якщо потрібні погодженість (C) і блокове розбиття (P), то вузли не
можуть залишатися доступними (A), оскільки вузли стануть
недоступними при досягненні стану погодженості (C). Якщо потрібні
доступність (A) і блокове розбиття (P), то погодженість (C) неможлива
через вимогу до обміну даними між вузлами. Таким чином, база даних
може залишатися доступною (A), але з деякими суперечливими
наслідками (исходами).
У розподіленій базі даних масштабованість і відмовостійкість можуть
бути покращені за допомогою додаткових вузлів, незважаючи на
проблеми з погодженістю (C). Додавання вузлів може також викликати
втрату доступності (A) через затримку, викликану збільшенням обміну
даними між вузлами.

36. Діаграма Венна з узагальненням теореми CAP
Системи розподілених баз даних не можуть бути на 100%
відмовостійкими до розбиття (P). Незважаючи на те, що перебої з
обміном даними є рідкими й тимчасовими, стійкість до розбиття (P)
завжди повинна підтримуватися розподіленою базою даних; тому CAP
звичайно є рішенням між вибором C + P або A + P. Вимоги до системи
продиктують, яке з рішень буде обрано.

37. ACІD
ACІD - це принцип проектування бази даних, пов'язаний з керуванням
транзакціями. Це абревіатура, що позначає:
• атомарність;
• погодженість;
• ізольованість;
• довговічність.
ACІD - це стиль керування транзакціями, який задіює песимістичні
елементи керування паралелізмом доступу для забезпечення
погодженості, підтримуваної шляхом застосування блокувань записів.
ACІD - це традиційний підхід до керування транзакціями бази даних,
тому що він використовується системами керування реляційними
базами даних.
Атомарність гарантує, що всі операції будуть завжди успішно виконані
або взагалі не виконані через збої. Іншими словами, не існує
часткових транзакцій. На рис. 5.18 показані наступні кроки:

38. ACІD
1. Користувач намагається обновити три записи, які є
частиною транзакції.
2. Два записи успішно обновляються до виникнення збою.
3. У результаті база даних анулює будь-які часткові наслідки
виконання транзакції й повертає систему в попередній стан.
Рис. 5.18. Приклад властивості атомарності принципу ACІD є тут очевидним.
[update - оновлення; transactіon - транзакція; RDBMS - СКРБД; amount - сума;
rollback - повернення у вихідний стан ]

39. ACІD
Узгодженість гарантує, що база даних буде завжди залишатися в
несуперечливому стані, гарантуючи, що тільки дані, які відповідають
обмеженням схеми бази даних, можуть бути записані в базу даних.
Таким чином, база даних, яка перебуває в погодженому стані,
залишиться в погодженому стані й після успішної транзакції.
На рис. 5.19:
1. Користувач намагається обновити стовпець загальної суми таблиці, який має
тип float (числа із плаваючої комою) зі значенням varchar.
2. База даних застосовує свою перевірку правильності й відхиляє це оновлення,
тому що це значення порушує умови перевірки обмежень для стовпця.
Рис. 5.19. Приклад
погодженості
ACІD.

40. Применение Data Mining для решения бизнес-задач
Ізольованість гарантує, що результати транзакції не будуть видні
іншим операціям, поки вона не буде завершена. На рис. 5.20:
1. Користувач A намагається
обновити два записи, які є
частиною транзакції.
2. База даних успішно
обновляє перший запис.
3. Однак, перш ніж він зможе
обновити другий запис,
користувач користувач B
спробує також обновити той
же запис. База даних не
дозволяє оновлення
користувачеві B доти, поки
оновлення користувача А не
завершиться успішно або не
буде виконано повністю. Це
відбувається тому, що запис
із іd3 блокується базою даних
до завершення транзакції.

41. Довговічність
Довговічність гарантує, що результати операції будуть постійними. Інакше
кажучи, як тільки транзакція була виконана її не можна скасувати . Це
відбувається незалежно від збою системи.
На рис.5.21:
1. Користувач обновляє
запис, який є частиною
транзакції.
2. База даних успішно
обновляє запис.
3. Відразу після цього
оновлення відбувається
збій живлення. База
даних зберігає свій стан,
поки відсутнє живлення.
4. Живлення
відновляється.
5. База даних обслуговує
запис відповідно до
останнього оновлення по
запиту користувача.
Рис. 5.21. Характеристика
довговічності ACІD

42. BASE
BASE є принципом проектування баз даних на основі теореми CAP і
максимального використання концепцій систем баз даних, які
використовують розподілену технологію. BASE розшифровується як:
• зовсім доступні;
• м'який стан ;
• випадкова погодженість .
Коли база даних підтримує BASE, те це сприяє доступності завдяки
погодженості . Інакше кажучи, база даних A+P з погляду CAP. По суті,
BASE використовує оптимістичні елементи керування паралелізмом,
послабляючи сильні обмеження погодженості , обумовлені
властивостями ACІD.

43. BASE
Якщо база даних "зовсім доступна", то ця база даних завжди буде
підтверджувати запит клієнта, або у формі запитуваних даних, або через
повідомлення про успішне/невдале виконання.
На рис. 5.23 база даних "зовсім доступна", навіть при тому, що вона виявилася
розбитою на фрагменти в результаті збою в мережі.
Рис. 5.23 Користувач A і
користувач B одержують дані,
незважаючи на те, що база
даних розбивається на
фрагменти в результаті збою
мережі.

44. Data Mining для научных исследований
"М'який стан" означає, що база даних може перебувати в неузгодженому стані
при виконанні читання даних; таким чином, результати можуть змінитися, якщо
знову запросити ті ж самі дані. Це пов'язано з тим, що дані можуть бути
оновлені для забезпечення погодженості, навіть якщо користувач не записав
їх у базу даних між двома читаннями. Ця властивість тісно зв'язана з
випадковою погодженістю.
На рис. 5.24:
1. Користувач A обновляє
запис на одноранговому
вузлі A.
2. До того, як інші
однорангові вузли
обновлятся, користувач B
запитує той же запис в
однорангового вузла C.
3. Тепер база даних
перебуває в гнучкому
стані дані, і застарілі
дані повертаються
користувачеві B.
Рис. 5.24. Приклад властивості
"м'якого стану " BASE показаний
тут.

45. BASE
Випадкова погодженість - це стан, при якім зчитування різними
клієнтами відразу після запису в базу даних, можуть не повернути
погоджених результатів. База даних досягає погодженості тільки після
того, як зміни були поширена на всі вузли. Поки база даних перебуває
в процесі досягнення стану остаточної погодженості , вона буде в
м'якому стані. На рис. 5.25:
1. Користувач A обновляє
запис.
2. Запис тільки що обновився
в одноранговий вузол A, але
до того, як інші однорангові
вузли можуть бути оновлені,
користувач B запитує той же
самий запис.
3. Тепер база даних перебуває
в м'якому стані. Застарілі дані
вертаються користувачеві B
від однорангового вузла C.
4. Однак погодженість в
остаточному підсумку
досягається, і користувач C
одержує правильне значення.
Приклад властивості
випадкової погодженості
BASE.

46. BASE і ACІD
BASE наголошує на більш безпосередній погодженості, на відміну від ACІD,
що забезпечує негайну погодженість за рахунок доступності через блокування
записів.
Цей м'який підхід до погодженості дозволяє BASE поєднувати бази даних для
обслуговування декількох клієнтів без затримки хоча й видають неузгоджені
результати.
Таким чином, Base-сумісні бази даних не є корисними для транзакційних
систем, де відсутність погодженості є проблемою.

47. Data Mining для научных исследований
 Химия
Технология Data Mining активно используется в исследованиях органической и
неорганической химии. Одно из возможных применений Data Mining в этой
сфере - выявление каких-либо специфических особенностей строения
соединений, которые могут включать тысячи элементов.
 Далее мы рассмотрим технологии, в основу которых также положено
понятие Mining или "добыча".

48. Web Mining
 Web Mining
 Web Mining можно перевести как "добыча данных в Web". Web Intelligence
или Web Интеллект готов "открыть новую главу" в стремительном развитии
электронного бизнеса. Способность определять интересы и предпочтения
каждого посетителя, наблюдая за его поведением, является серьезным и
критичным преимуществом конкурентной борьбы на рынке электронной
коммерции.
 Системы Web Mining могут ответить на многие вопросы, например, кто из
посетителей является потенциальным клиентом Web-магазина, какая
группа клиентов Web-магазина приносит наибольший доход, каковы
интересы определенного посетителя или группы посетителей.

49. Data Mining для научных исследований
 Технология Web Mining охватывает методы, которые способны на основе
данных сайта обнаружить новые, ранее неизвестные знания и которые в
дальнейшем можно будет использовать на практике. Другими словами,
технология Web Mining применяет технологию Data Mining для анализа
неструктурированной, неоднородной, распределенной и значительной по
объему информации, содержащейся на Web-узлах.
 Согласно таксономии Web Mining , здесь можно выделить два основных
направления: Web Content Mining и Web Usage Mining.

50. Web Mining
 Web Content Mining подразумевает автоматический поиск и извлечение
качественной информации из разнообразных источников Интернета,
перегруженных "информационным шумом". Здесь также идет речь о
различных средствах кластеризации и аннотировании документов.
В этом направлении, в свою очередь, выделяют два подхода: подход,
основанный на агентах, и подход, основанный на базах данных.
Подход, основанный на агентах (Agent Based Approach), включает такие
системы:
 интеллектуальные поисковые агенты (Intelligent Search Agents);
 фильтрация информации / классификация;
 персонифицированные агенты сети.
Примеры систем интеллектуальных агентов поиска:
 Harvest (Brown и др., 1994),
 FAQ-Finder (Hammond и др., 1995),
 Information Manifold (Kirk и др., 1995),
 OCCAM (Kwok and Weld, 1996), and ParaSite (Spertus, 1997),
 ILA (Information Learning Agent) (Perkowitz and Etzioni, 1995),
 ShopBot (Doorenbos и др., 1996).

51. Web Mining
Подход, основанный на базах данных (Database Approach), включает
системы:
 многоуровневые базы данных;
 системы web-запросов (Web Query Systems);
Примеры систем web-запросов:
 W3QL (Konopnicki и Shmueli, 1995),
 WebLog (Lakshmanan и др., 1996),
 Lorel (Quass и др., 1995),
 UnQL (Buneman и др., 1995 and 1996),
 TSIMMIS (Chawathe и др.., 1994).

52. Web Mining
Второе направление Web Usage Mining подразумевает обнаружение
закономерностей в действиях пользователя Web-узла или их группы.
Анализируется следующая информация:
 какие страницы просматривал пользователь;
 какова последовательность просмотра страниц.
Анализируется также, какие группы пользователей можно выделить среди
общего их числа на основе истории просмотра Web-узла.
Web Usage Mining включает следующие составляющие:
 предварительная обработка;
 операционная идентификация;
 инструменты обнаружения шаблонов;
 инструменты анализа шаблонов.

53. Web Mining
При использовании Web Mining перед разработчиками возникает два типа
задач.
Первая касается сбора данных, вторая - использования методов
персонификации. В результате сбора некоторого объема
персонифицированных ретроспективных данных о конкретном клиенте,
система накапливает определенные знания о нем и может рекомендовать
ему, например, определенные наборы товаров или услуг. На основе
информации о всех посетителях сайта Web-система может выявить
определенные группы посетителей и также рекомендовать им товары или
же предлагать товары в рассылках.
Задачи Web Mining согласно можно подразделить на такие категории:
 Предварительная обработка данных для Web Mining.
 Обнаружение шаблонов и открытие знаний с использованием
ассоциативных правил, временных последовательностей, классификации и
кластеризации;
 Анализ полученного знания.

54. Text Mining
Text Mining охватывает новые методы для выполнения семантического
анализа текстов, информационного поиска и управления. Синонимом
понятия Text Mining является KDT (Knowledge Discovering in Text - поиск или
обнаружение знаний в тексте).
 В отличие от технологии Data Mining, которая предусматривает анализ
упорядоченной в некие структуры информации, технология Text Mining
анализирует большие и сверхбольшие массивы неструктурированной
информации.
 Программы, реализующие эту задачу, должны некоторым образом
оперировать естественным человеческим языком и при этом понимать
семантику анализируемого текста. Один из методов, на котором основаны
некоторые Text Mining системы, - поиск так называемой подстроки в строке.

55. Call Mining
По словам Энн Беднарц, "добыча звонков" может стать популярным
инструментом корпоративных информационных систем.
 Технология Call Mining объединяет в себя распознавание речи, ее анализ
и Data Mining. Ее цель - упрощение поиска в аудио-архивах, содержащих
записи переговоров между операторами и клиентами. При помощи этой
технологии операторы могут обнаруживать недостатки в системе
обслуживания клиентов, находить возможности увеличения продаж, а
также выявлять тенденции в обращениях клиентов.
 Среди разработчиков новой технологии Call Mining ("добыча" и анализ
звонков) - компании CallMiner, Nexidia, ScanSoft, Witness Systems. В
технологии Call Mining разработано два подхода - на основе
преобразования речи в текст и на базе фонетического анализа.

56. Call Mining
 Примером реализации первого подхода, основанного на преобразовании
речи, является система CallMiner. В процессе Call Mining сначала
используется система преобразования речи, затем следует ее анализ, в
ходе которого в зависимости от содержания разговоров формируется
статистика телефонных вызовов. Полученная информация хранится в базе
данных, в которой возможен поиск, извлечение и обработка.
 Пример реализации второго подхода - фонетического анализа - продукция
компании Nexidia. При этом подходе речь разбивается на фонемы,
являющиеся звуками или их сочетаниями. Такие элементы образуют
распознаваемые фрагменты. При поиске определенных слов и их
сочетаний система идентифицирует их с фонемами.
 Аналитики отмечают, что за последние годы интерес к системам на основе
Call Mining значительно возрос. Это объясняется тем фактом, что
менеджеры высшего звена компаний, работающих в различных сферах, в
т.ч. в области финансов, мобильной связи, авиабизнеса, не хотят тратить
много времени на прослушивание звонков с целью обобщения информации
или же выявления каких-либо фактов нарушений.
 По словам Дэниэла Хонг, аналитика компании Datamonitor: "Использование
этих технологий повышает оперативность и снижает стоимость обработки
информации".

57. Call Mining
 Типичная инсталляция продукции от разработчика Nexidia обходится в
сумму от 100 до 300 тыс. долл. Стоимость внедрения системы CallMiner по
преобразованию речи и набора аналитических приложений составляет
около 450 тыс. долл.
 По мнению Шоллера, приложения Audio Mining и Video Mining найдут со
временем гораздо более широкое применение, например, при индексации
учебных видеофильмов и презентаций в медиабиблиотеках компаний.
Однако технологии Audio Mining и Video Mining находятся сейчас на уровне
становления, а практическое их применение - на самой начальной стадии.