Основи баз даних NoSQL - і навіщо вони нам потрібні

Посібник для початківців у світі NoSQL

Організація даних - дуже складне завдання. Коли ми говоримо організувати, ми фактично класифікуємо речі залежно від їх типу та функції.

Одним із варіантів є СУБД - це як аркуш Excel - ви класифікуєте дані у вигляді таблиць. Ви можете формувати взаємозв'язки між таблицями.

А запит питання бази даних, яка дає відповідний відповідь у відповідь. Цією мовою запитів є SQL або мова структурованих запитів.

Наприклад,

select * from Employee_Data;

вибирає всі дані працівника з таблиці Employee_Data.

Реляційні бази даних мають схему , детальну схему роботи таблиць.

Ви використовуєте Amazon, Facebook і стільки мережевих додатків. Вони випускають оновлення, додають нові функціональні можливості і навіть додаткові модулі. Отже, як кожен раз змінювати схему? Чи не трудомістким для таких величезних компаній є присвячення часу та праці зміні схеми?

Тут SQL не міг працювати .

Мінуси RDBMS

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

Я збираюся показати вам приклади, щоб ви мали чітке розуміння.

1. СУБД не може обробляти "різноманітність даних".

Кількість неструктурованих даних продовжує зростати щороку, і керувати ними важко. СУБД не може примусово застосовувати всі типи даних за єдиною схемою таблиць.

Data Silos також є проблемою для розробників.

Відповідно до Tech Target, силос даних - це сховище даних, яке залишається під контролем одного відділу. Він ізольований від решти організації.

Це означає, що коли для тих самих даних існує більше силосів, їх вміст, ймовірно, буде відрізнятися. Це створює плутанину щодо того, яке сховище представляє найсучаснішу версію.

Зростання даних з 2013 по 2020 рік видно на зображенні нижче.

Близько 44 зета-байтів даних буде сформовано у 2020 році.

Обробка таких різноманітних даних, які не пов'язані між собою, може бути набагато складнішою в СУБД.

Приклад: Важко зберігати деталі пацієнта, який має різні стани тіла. Класифікація таких різноманітних даних є складною у СУБД.

2. Важко міняти таблиці та відносини.

Зміна взаємозв’язків між таблицями або додавання нової таблиці може вплинути на існуючі відносини. Це означає зміну схеми.

Зміна схеми могла б означати усунення існуючої та розробку нової схеми.

Для додавання нової функціональності потрібні всі елементи для підтримки нової структури. Зміни неминучі.

Приклад: Кожному додатковому стовпцю потрібні всі попередні рядки, щоб мати значення для цього стовпця. Тоді як у Cassandra (база даних NoSQL), ви можете додати стовпець до певних розділів рядків.

3. СУБД відповідають властивостям ACID бази даних.

Властивостями ACID бази даних є атомність, послідовність, ізоляція та довговічність. ‌

Атомність - підхід "все або нічого". Якщо будь-який оператор у транзакції не вдається, вся транзакція відкочується.

Узгодженість - транзакція повинна відповідати всім протоколам, визначеним системою. Жодної половини завершених транзакцій.

Ізоляція - жодна транзакція не має доступу до будь-якої іншої транзакції, яка знаходиться в проміжному або незавершеному стані. Кожна операція незалежна.

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

Властивості кислоти не є гнучкими.

Наприклад, СУБД відповідає Нормалізації або концепції єдиної точки істини . Для кожної вашої зміни слід забезпечувати суворі властивості кислоти. Також застосовуються правила цілісності сутності та посилальної цілісності.

Теорема CAP

Згідно з Вікіпедією, теорема CAP ( теорема Брюера) стверджує, що розподіленому сховищу даних неможливо одночасно надати більше двох із наступних трьох гарантій:

Послідовність: як C у кислоті.

Доступність : ‌Ресурси повинні бути завжди доступними. Повинна бути відповідь без помилок.

Допуск розділу : Жодної точки (або вузла) відмови.

Важко досягти всіх трьох умов. Треба йти на компроміс між трьома.

БАЗА на допомогу!

‌NoSQL спирається на більш м’яку модель, відому як модель BASE. БАЗА ( Б asically моделі шириною, S часто стан, Е ventual консистенції).

В основному доступні: гарантує доступність даних. Буде відповідь на будь-який запит (може бути і помилкою).

М'який стан : стан системи може змінюватися з часом.

Потенційна узгодженість: система врешті-решт стане послідовною, як тільки вона перестане отримувати вхідні дані.

Бази даних NoSQL відмовляються від вимог A, C та / або D, а натомість вони покращують масштабованість.

NoSQL

Це коли на допомогу прийшов NoSQL. ‌ Це бази даних " Не тільки SQL" або " Нереляційні ".

Характеристики NoSQL:

  • Схема безкоштовна
  • Врешті-решт послідовний (як у властивості BASE)
  • Реплікація сховищ даних, щоб уникнути єдиної точки відмови.
  • Може обробляти різноманітність даних та величезні обсяги даних.

Типи баз даних NoSQL

Бази даних NoSQL можна розділити на чотири основні категорії:

Магазини ключових цінностей - Riak, Voldemort та Redis

Магазини широких колон - Кассандра та HBase.

Бази даних документів - MongoDB

Графічні бази даних - Neo4J та HyperGraphDB.

Слова праворуч - це приклади типів типів баз даних NoSQL.

1. Магазини ключових цінностей

У сховищі значень ключа використовується хеш-таблиця, в якій існує унікальний ключ і вказівник на певний елемент даних.

Уявіть, що сховища значень ключів схожі на телефонний каталог, де імена особи та їх номери зіставляються разом.

Сховища значень ключів не мають мови запитів за замовчуванням. Ви отримуєте дані за допомогою команд отримання, введення та видалення . Ось чому він має високу продуктивність.

Додатки : Корисно для зберігання інформації про коментарі та сеанси. ‌Pinterest використовує Redis для зберігання списків користувачів, послідовників, непідписаних, дощок.

2. Широкі магазини колон

У базі даних сховища стовпців стовпці кожного рядка містяться в цьому рядку.

Кожне сімейство стовпців є контейнером рядків таблиці RDBMS. Ключ ідентифікує рядок , що складається з декількох колон.

Рядки не повинні мати однакову кількість стовпців. Стовпці можна додати до будь-якого рядка в будь-який час без необхідності додавати його до інших рядків. Це розділений рядковий магазин.

Як стовпчаста база даних зберігає дані?

Додатки : Spotify використовує Cassandra для зберігання атрибутів і метаданих профілю користувача.

3. Бази даних документів

StoresДокументи зберігають дані, використовуючи документи JSON, XML або BSON (двійкове кодування JSON).

Це як база даних ключ-значення, але сховище документів складається з напівструктурованих даних .

Один документ - це зберігання записів та їх даних.

‌Це не підтримує відносини та не приєднується.

Якщо ми хочемо зберегти дані про клієнта та їх замовлення, ми можемо використовувати для цього сховища документів.

Застосування: SEGAвикористовує MongoDB для обробки 11 мільйонів ігрових рахунків, побудованих на MongoDB.

4. Графічні бази даних

Odes Вузли та взаємозв'язки є найважливішими складовими баз даних графіків. Вузол є об'єкт. Відносини представляють , як два вузла пов'язані.

‌У RDBMS додавання іншого відношення призводить до багатьох змін у схемі.

База даних графіків вимагає збереження даних лише один раз (вузли). Різні типи відносин (країв) задаються до збережених даних.

Взаємозв'язки між вузлами визначені заздалегідь, тобто вони не визначаються під час запиту.

Подолання довготривалих стосунків відбувається швидше.

Важко змінити відношення між двома вузлами. Це призведе до регресивних змін у базі даних.

Приклад : Це зображення, як працює MySQL, де йому доводиться виконувати багато операцій, щоб знайти правильний результат для Аліси.

База даних граф , який зумовлює відносини.

Це частина основної інформації, яка вам знадобиться для початку вивчення NoSQL. Винайдено нові бази даних для конкретних цілей.

Дізнайтеся тип даних, які створює ваша програма, і тоді легко вибрати потрібну базу даних.

Я пишу історії про уроки життя, кодування та технології. Щоб читати більше, слідкуйте за мною у Twitter та Medium.