Сценарії використання NoSQL або коли використовувати NoSQL [закрито]

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

1. Чи варто використовувати NoSQL для даних користувачів? Наприклад, профілі, імена користувачів + паролі тощо.
2. Чи варто використовувати NoSQL для важливого вмісту? Наприклад, статті, повідомлення в блогах, інвентаризація продуктів тощо.

Я припускаю, що ні? І я відчуваю, що NoSQL - це лише для швидко доступних речей, з яких нормально втрачати дані. Але я також читав, що додатки NoSQL мають вбудовану надмірність, щоб я не втрачав дані?

Крім того, якщо вищезгадані 2 приклади погані, чи можете ви надати мені конкретні випадки використання для бізнесу, де я використовував би NoSQL? Я бачу багато загальних описів, але не багато реальних прикладів. Єдине, про що я можу придумати, - це обмін повідомленнями користувачів та аналітика.

Дякую!

Це справді своєрідне питання "це залежить". Деякі загальні моменти:

• NoSQL, як правило, добре підходить для неструктурованих / "без схемних" даних - зазвичай вам не потрібно чітко визначати схему на передній панелі, а можна просто включати нові поля без будь-якої церемонії
• NoSQL, як правило, надає перевагу денормалізованій схемі через відсутність підтримки JOIN у світі RDBMS. Таким чином, у вас зазвичай є сплющене, денормоване представлення ваших даних.
• Використання NoSQL не означає, що ви можете втратити дані. У різних БД є різні стратегії. наприклад, MongoDB - ви можете фактично вибрати, на якому рівні відшкодувати продуктивність та потенціал втрати даних - найкраща продуктивність = більший обсяг для втрати даних.
• Масштабувати рішення NoSQL часто дуже просто. Додавання більшої кількості вузлів для копіювання даних - це один із способів: а) запропонувати більшу масштабованість і б) запропонувати більше захисту від втрати даних, якщо один вузол опуститься вниз. Але знову ж таки, залежить від NoSQL DB / конфігурації. NoSQL не обов'язково означає "втрату даних", як ви робите висновок.
• IMHO, складні / динамічні запити / звітності найкраще обслуговуються з RDBMS. Часто функціональність запитів для БД NoSQL обмежена.
• Це не повинно бути 1 чи іншим вибором. Мій досвід використовував RDBMS спільно з NoSQL для певних випадків використання.
• У баз даних NoSQL часто бракує можливості виконувати атомні операції в декількох "таблицях".

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

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

Я думаю, що Nosql є "придатнішим" у цих сценаріях принаймні (більше додаткових вітається)

1. Легко масштабувати горизонтально просто додаючи більше вузлів.

2. Запит на великий набір даних

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

3. Вузьке місце вводу / виводу диска

   Якщо веб-сайт повинен надсилати результати різним користувачам на основі інформації в реальному часі користувачів, ми, мабуть, говоримо про десятки або сотні тисяч запитів на читання / запис SQL в секунду. Тоді введення / виведення диска стане серйозним вузьким місцем.