SQL проти NoSQL – що слід використовувати для наступного проекту?

Одне з найбільш часто задаваних питань – яку базу даних я повинен використовувати …


SQL означає структуровану мову запитів. Вперше він був розроблений у 1970-х роках командою дослідників IBM, бази даних NoSQL, з іншого боку, вперше були використані в 1998 році Карло Строцці.

Найпоширеніша відмінність цих двох систем баз даних (DB) полягає в тому, що SQL є реляційним, а NoSQL – нереляційним..

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

Структура бази даних

Поговоримо про структурування.

SQL

SQL база даних має певну структуру схеми.

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

Кожна таблиця в базі даних SQL може бути пов’язана. тобто можна мати зв’язки між таблицями. Ці відносини можуть бути один до багатьох, багато до багатьох або один до одного. Тип відносин, які ви реалізуєте, залежить від того, що вам потрібно.

Наприклад, розглянемо гіпотетичну ситуацію; у нас є компанія з користувачами, і користувачі можуть робити замовлення на продукцію. Тоді ми могли б вирішити, що користувачі можуть створювати кілька замовлень, але кожне замовлення може створювати лише один користувач. Це було б одна до багатьох відносин, тобто один користувач до багатьох замовлень. Отже, структура таблиці для обох таблиць буде виглядати аналогічно нижче.

У нашій БД ми могли б мати таблицю користувачів, структуровану як показано нижче,

користувальницький таблиця
—————————————————-
id | назва | електронною поштою
—————————————————–
1 Ідріс [захищено електронною поштою]

Також у нас може бути таблиця замовлень

таблиць замовлень
———————————————————————————
id | user_id | номер замовлення
———————————————————————————
1 1 20000001

User_id в таблиці замовлень полегшує відображення кожного замовлення в таблиці замовлень тому користувачеві, якому він належить. У випадку відносин «один на один» ми можемо мати order_id також на table_ user_table, якщо ми вирішимо отримати користувача за його відповідним ідентифікатором замовлення.

Бо, як правило, багато залучається додаткова таблиця під назвою Зведена таблиця. Це дозволяє зіставити кілька записів між собою. Використовуючи вищевказаний екземпляр. Ми б мали,

користувальницький таблиця
————————————————————————————-
id | назва | електронною поштою
————————————————————————————-
1 Ідріс [захищено електронною поштою]

і таблиця замовлень буде

таблиць замовлень
———————————————————
id | номер замовлення
———————————————————
1 2000001

і тоді таблиця Зворотна буде зберігати обидва ідентифікатори як зовнішні ключі.

users_orders_table
——————————————————————————
id | order_id | ідентифікатор користувача
——————————————————————————
1 1 1

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

NoSQL

NoSQL бази даних були побудовані таким чином, щоб вони були більш гнучкими, ніж SQL БД, а також містили більшу кількість даних.

У БД NoSQL немає заздалегідь визначеної схеми чи таблиць. Є колекції, і в кожній колекції є документи. Це дає змогу зберігати дані в різних формах у міру їх надходження. Ви можете вибрати в одній колекції декілька різних документів з різними полями. Також можливо вручну налагодити відносини між колекціями. Однак вони не підходять для такої мети. Натомість ви можете зберегти все, що потрібно для одного запиту, в одній колекції.

Якщо ви людина SQL, ви можете вважати Колекції як таблиці, а Документи – як рядки з таблицями. Однак для стовпців даних, які ви можете додати до таблиці, немає обмежень.

Повертаючись до нашої раніше визначеної гіпотетичної інстанції компанії з користувачами та замовленнями.

Колекцію користувачів можна визначити як,

{id: 1, name: ‘idris’, email: ‘[захищено електронною поштою]‘}

І колекцію замовлень можна визначити як,

{id: 1, order_number: 2000001, user_id: 1}

Однак у цьому випадку ми хочемо уникнути необхідності вручну приєднуватися до обох Колекцій (чого ми не повинні в цьому випадку). Ми можемо зберегти записи до колекції, яка отримує найбільшу кількість читань. Я вирішив (для цього прикладу), що буде колекцією замовлень.

{id: 1, order_number: 200001, user {id: 1, name: ‘idris’, email: ‘[захищено електронною поштою]‘}}

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

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

Однак для програми, яка вимагає великої кількості записів (приблизно 10000 записів в секунду) в такому масштабі, не годиться мати опцію NoSQL, де потрібно записати одні й ті самі дані у кілька локацій. У цій ситуації, швидше за все, підходить варіант SQL, коли у вас є відносини, які існують до всіх таблиць, і одні і ті ж дані не потрібно записувати в кілька локацій повторно, оновлення даних в одному місці може бути доступне до інших таблиць через вихід відносини. Це, звичайно, не означає, що кожна з цих баз даних не може обробляти масштаб.

Масштабування

Давайте вивчимо, як працює масштабування.

SQL

SQL БД не можна масштабувати горизонтально, а лише вертикально. Що це навіть означає?

Горизонтальне масштабування означає розділення даних з однієї БД на кілька баз даних, щоб полегшити навантаження. Однак дані SQL не можуть бути розділені на окремі БД через сувору природу. Правильним масштабуванням SQL БД є збільшення простору процесора, пам’яті та диска існуючого сервера БД, і це означає, що масштабувати його по вертикалі.

горизонтальне масштабування

вертикальне масштабування


NoSQL

Бази даних NoSQL можна масштабувати як по горизонталі, так і по вертикалі. Це пов’язано з гнучкістю в його зберіганні даних. Таким чином, це дозволяє розділити його дані на декілька баз даних, як це стосується горизонтального масштабування. При необхідності його також можна масштабувати вертикально.

Тут слід зазначити ключову річ: Що стосується масштабування, то і SQL, і NoSQL Бази даних можна ефективно масштабувати. Однак для SQL БД вертикальне масштабування може бути обмеженням; на одному сервері БД буде обмежено кількість обчислювальної потужності, яку він може нести.

Тут також важливо зазначити, що для більшості застосунків, які ви будуєте, ви можете не враховувати максимум обчислювальних можливостей вашого сервера, але корисно це пам’ятати. Однак для великих бізнес-додатків, що впроваджують SQL, популярним варіантом подолати це обмеження є Sharding.

Що таке Шардінг?

Шардінг – це процес розбиття великих столів на невеликі шматки, які називаються осколками. Шардування може бути здійснено горизонтальним поділом бази даних. Це не слід плутати з горизонтальним та вертикальним масштабуванням. Горизонтальний розподіл відноситься до процесу зберігання рядків таблиці у кількох вузлах бази даних. З іншого боку, вертикальний розподіл вимагає збереження стовпців таблиці на різних вузлах. Це дозволяє базі даних ефективно масштабувати та підвищувати продуктивність.

Приклади бази даних

SQL

  • MySQL – дуже популярна база даних з відкритим кодом. Легко вибирати базу даних для багатьох розробників PHP, однак також можна використовувати з Node.js, C #, C ++, Java, Perl, Ruby та Python.
  • MSSQL – Microsoft SQL забезпечує велику стабільність, оскільки його розвиток здійснюється безпосередньо від Microsoft, які також пропонують певну підтримку в плані відновлення після аварій.
  • MariaDB – Це було створено на MySQL виробниками MySQL, маючи намір зберегти MariaDB як безкоштовну вічну версію.
  • PostgresSQL – дуже популярна база даних з відкритим кодом. Гордість себе як найдосконаліша база даних з відкритим кодом у світі
  • Oracle – зазвичай адаптований до корпоративних рішень Oracle з деякими обмеженнями у його безкоштовній версії.

NoSQL

  • MongoDB – це, мабуть, найбільш відомий NoSQL DB, поширений серед розробників додатків, які працюють зі стеком MERN (MongoDB, Express, React, Node) або стеком MEAN (MongoDB, Express, Angular, Node).
  • Firebase – Введена в 2011 році та придбана Google у 2014 році, широко використовується розробниками веб-та мобільних додатків.
  • Apache Couch DB – БД NoSQL на основі документа, який зберігає дані як JSON.
  • Редіс: Це БД NoSQL, напевно, найбільш відомий своїм використанням у зберіганні даних із додатковим часом життя. Він також добре відомий своєю швидкістю.

Висновок

Ви можете створювати будь-які програми за допомогою бази даних SQL або NoSQL. Це залежить від ваших вимог. Якщо ви розглядаєте базу даних, де ви маєте більше читань і менше записів, NoSQL може бути хорошим варіантом. Якщо ви все-таки розглядаєте можливість створення програми з більшою кількістю записів, ніж прочитаних, SQL може бути кращим рішенням. Щодо масштабованості, коли ваш додаток набуває дуже масштабного масштабу, ви можете скористатися обома БД.

МЕТИ:

  • База даних

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map