Одне з найважливіших рішень, які приймає розробник, у тому, яку базу даних використовувати. Протягом багатьох років опції були обмежені різними варіантами реляційних баз даних, які підтримували мову структурованих запитів (SQL). До них відносяться MS SQL Server, Oracle, MySQL, PostgreSQL, DB2 та багато інших.
За останні 15 років на ринку з'явилося багато нових баз даних у рамках підходу No-SQL. До них відносяться сховища ключів-значень, такі як Redis та Amazon DynamoDB, широкі колонкові бази, такі як Cassandra та HBase, сховища документів, такі як MongoDB та Couchbase, а також графові бази даних та пошукові системи, такі як Elasticsearch та Solr.
У цій статті ми спробуємо розібратися в SQL і NoSQL, не залазячи до їхнього функціоналу.
Крім того, ми трохи повеселимося у процесі.
Пояснюємо бабусі SQL
Бабуся, уяви, що я не єдиний твій онук. Натомість мама та тато любили один одного як кролики, у них було 100 дітей, потім вони усиновили ще 50.
Отже, ти любиш усіх нас і не хочеш забути жодного з наших імен, днів народжень, смаків улюбленого морозива, розмірів одягу, хобі, імен подружжя, імен нащадків та інших важливих фактів. Однак давай подивимося правді у вічі. Тобі 85 років, і стара добра пам'ять просто не в змозі впоратися.
На щастя, я, будучи найрозумнішим із твоїх онуків, можу допомогти. Тому я приходжу до тебе додому, дістаю кілька аркушів паперу і прошу тебе спекти печиво перед тим, як ми почнемо.
На одному аркуші паперу ми складаємо список під назвою «онуки». Кожен онук записаний з якоюсь істотною інформацією про нього, включаючи унікальний номер, який тепер позначатиме, яким онуком він являється. Крім того, заради організованості ми виписуємо іменовані атрибути у верхній частині списку, щоб ми завжди знали, яку інформацію містить цей список.
id
ім'я
день народження
останній візит
розмір одягу
favorite ice-cream
прийнята
1
Джиммі
09-22-1992
09-01-2019
L
М'ятний шоколад
false
2
Джессіка
07-21-1992
02-22-2018
M
Кам'яниста дорога
правда
…продовжуємо список!
Список онуків
Через деякий час ти в усьому розумієшся і ми майже закінчили зі списком! Однак ти повертаєшся до мене і кажеш: «Ми забули додати місце для подружжя, хобі, онуків!» Але ні, ми не забули! Це слідує далі і вимагає нового аркуша паперу.
Отже, я витягаю ще один аркуш паперу, і на ньому ми називаємо список подружжя. Ми знову додаємо атрибути, які нам важливі, на початок списку і починаємо додавати у рядках.
id
grandchild_id
ім'я
день народження
1
2
Джон
06-01-1988
2
9
Фернанда
03-05-1985
…більше подружжя!
Список подружжя
На цьому етапі я пояснюю бабусі, що якщо вона хоче знати, хто з ким одружується, то їй потрібно лише зіставити id в списку онуків с grandchild_id у списку подружжя.
Після пари десятків печива мені треба подрімати. «Можеш продовжити, бабусю?» Я йду, щоб подрімати.
Я повертаюся за кілька годин. А ти крута, бабусю! Все виглядає чудово, за винятком списку хобі. У списку близько 1000 хобі. Більшість із них повторюються; що трапилося?
grandchild_id
хобі
1
велосипедах
4
велосипедах
3
велосипедах
7
біг
11
велосипедах
…продовжуємо!
Вибач, зовсім забув сказати! Використовуючи один список, можна відстежувати лише хобі. Потім в іншому списку нам слід відстежити онуків, які займаються цим хобі. Ми збираємось назвати це "Загальний список". Бачачи, що тобі це не подобається, я починаю переживати і повертаюся до списку.
id
хобі
1
велосипедах
2
біг
3
плавання
…більше хобі!
Список хобі
Як тільки у нас є наш список хобі, ми створюємо наш другий список і називаємо його «Захоплення онуків».
grandchild_id
hobby_id
4
1
3
1
7
2
…більше!
Загальний список хоббі онуки
Після всієї цієї роботи у бабусі тепер є крута система запам'ятовування для стеження за всією її напрочуд великою родиною. А потім - щоб затримати мене довше - вона ставить чарівне запитання: "Де ти навчився все це робити?"
Реляційні бази даних
Реляційна база даних - це набір формально описаних таблиць (у нашому прикладі це листи), з яких можна отримати доступ до даними або зібрати їх у різний спосіб без необхідності реорганізації таблиць бази даних. Існує багато різних типів реляційних баз даних, але, на жаль, список на аркуші паперу не є однією з них.
Відмінна риса найпопулярніших реляційних баз даних - мова запитів SQL (Structured Query Language). Завдяки ньому, якщо бабуся перенесе свою систему запам'ятовування до комп'ютера, вона зможе швидко отримати відповідь на такі питання, як: «Хто не відвідував мене минулого року, одружений і не має жодних захоплень?»
Одна з найпопулярніших систем керування базами даних SQL це MySQL з відкритим вихідним кодом. Вона реалізована в першу чергу як система управління реляційними базами даних (RDBMS) для програмних програм на базі веб-технологій.
Деякі ключові особливості MySQL:
- Вона досить відома, широко використовується та ретельно протестована.
- Є багато кваліфікованих розробників, які мають досвід роботи з SQL та реляційними базами даних.
- Дані зберігаються у різних таблицях, що дозволяє легко встановлювати зв'язок з використанням первинних та зовнішніх ключів (ідентифікаторів).
- Він простий у використанні та ефективний, що робить його ідеальним для великих та малих підприємств.
- Вихідний код знаходиться на умовах GNU General Public License.
Тепер забудь ВСІ.
Пояснюємо бабусі NoSQL
Бабуся, у нас величезна родина. У ній 150 онуків! Багато з них одружені, мають дітей, чимось захоплюються та інше. У твоєму віці неможливо пам'ятати про всіх нас. Що тобі потрібно, так це система запам'ятовування!
На щастя, я, НЕ бажаючи, щоб ти забула мій день народження та улюблений смак морозива, можу допомогти. Тому я біжу до найближчої крамниці, беру зошит і повертаюся до тебе додому.
Перший крок, який я роблю, це пишу "Внуки" великими жирними літерами на обкладинці зошита. Потім я перегортаю на першу сторінку і починаю писати все, що ти маєш пам'ятати про мене. За кілька хвилин сторінка виглядає приблизно так.
{
"_id":"dkdigiye82gd87gd99dg87gd",
"name":"Cody",
"birthday":"09-12-2006",
"last_visit":"09-02-2019",
"clothing_size":"XL",
"favorite_ice_cream":"Fudge caramel",
"adopted":false,
"hobbies":[
"video games",
"computers",
"cooking"
],
"spouse":null,
"kids":[
],
"favorite_picture":"file://scrapbook-103/christmas-2010.jpg",
"misc_notes":"Prefers ice-cream cake on birthday instead of chocolate cake!"
}
Я: "Здається все готове!"
бабуся: "Почекай, а як же інші онуки?"
Я: "Так точно. Тоді виділяємо по сторінці кожного.”
бабуся: "А мені потрібно буде записувати всю ту ж інформацію для всіх, як я робила для тебе?"
Я: “Ні, тільки якщо ти хочеш Давай покажу."
Забравши у бабусі ручку, я перегортаю сторінку і швидко записую інформацію про мого найнелюбнішого двоюрідного брата.
{
"_id":"dh97dhs9b39397ss001",
"name":"Tanner",
"birthday":"09-12-2008",
"clothing_size":"S",
"friend_count":0,
"favorite_picture":null,
"remember":"Born on same day as Cody but not as important"
}Щоразу, коли бабусі треба щось згадати про одного з онуків, їй треба тільки перейти на потрібну сторінку в записнику онуків. Вся інформація про них буде зберігатися прямо там, на їхній сторінці, яку вона може швидко змінити та оновити.
Коли все вже зроблено, вона ставить чарівне запитання: «Де ти навчився все це робити?»
Бази даних NoSQL
існує безліч баз даних NoSQL ("не тільки SQL"). У прикладах ми показали базу даних документів. Бази даних NoSQL моделюють дані способами, що унеможливлюють табличні відносини, що використовуються в реляційних базах даних. Ці бази даних стали популярними на початку 2000-х років серед компаній, яким була потрібна хмарна кластеризація баз даних через їхні явні вимоги до масштабування (наприклад, Facebook). У таких додатках узгодженість даних була набагато менш важливою, ніж продуктивність та масштабованість.
Спочатку бази даних NoSQL часто використовувалися для нішевих завдань управління даними. В основному, коли справа доходила до Інтернету та хмарних додатків, бази даних NoSQL обробляли та розподіляли значні обсяги даних. Інженерам, що працюють з NoSQL, також сподобалася гнучка схема даних (або її повна відсутність), так що були можливі швидкі зміни в програмах, що оновлюються.
Ключові особливості NoSQL:
- Дуже гнучкий спосіб зберігання даних
- Горизонтальне масштабування до кластерів
- Можлива послідовність на сталість/розповсюдження
- Документи, що ідентифікуються за допомогою унікальних ключів
Детальне порівняння
MySQL вимагає певної та структурованої схеми.
NoSQL дозволяє зберігати будь-які дані в документі.
MySQL підтримує величезну спільноту.
У NoSQL є невелика спільнота, що швидко зростає.
NoSQL відрізняється простотою масштабування.
MySQL потребує більшої керованості.
MySQL використовує SQL, який застосовується у багатьох типах баз даних.
NoSQL — база даних на основі дизайну з популярними реалізаціями.
MySQL використовує стандартну мову запитів (SQL).
NoSQL не використовує стандартну мову запитів.
MySQL має багато відмінних інструментів звітування.
У NoSQL є кілька інструментів звітності, які складно стандартизувати.
MySQL може видати проблеми з продуктивністю великих даних.
NoSQL забезпечує відмінну продуктивність великих даних.
Думки 8base
У компанії , в якій я працюю, ми забезпечуємо робочу сферу кожного проекту реляційною базою даних Aurora MySQL, яка розміщується на AWS. Хоча NoSQL є логічним вибором, коли вимоги вашої програми вимагають високої продуктивності та масштабованості, ми вважаємо, що сувора узгодженість даних, що забезпечується СУБД, необхідна для створення SaaS-додатків та іншого програмного забезпечення для бізнесу.
Для стартапів і розробників, які створюють такі бізнес-додатки, які потребують звітності, цілісності транзакцій та чітко визначених моделей даних, вкладатися в роботу з реляційними базами даних — це, на нашу думку, правильний вибір.
Дізнайтесь більше про розробку з Aurora, Serverless та GraphQL за допомогою 8base.com .
Джерело: habr.com