Коли я повинен використовувати базу даних NoSQL замість реляційної бази даних? Чи добре використовувати обидва на одному сайті?


141

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

Відповіді:


84

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

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

Бази даних NoSQL існують давно - просто термін новий. Деякі приклади - бази даних графіків, об'єктів, стовпців, XML та документів.

Для вашого 2-го питання: Чи добре використовувати обидва на одному веб-сайті?

Чому ні? Обидва служать різним цілям, правда?


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

@RamshVel Ви можете навести приклад бази даних типу "ключ-значення" магазину? Дякую.
Rachael

1
@Rachael, деякі приклади - redis, leveldb і riak .. Є багато тонн навколо, ви можете
погуглювати

76

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

Переваги, як правило, специфічні для вашого використання, але якщо у вас не виникне якась проблема моделювання ваших даних у RDBMS, я не бачу причин, чому ви б обрали NoSQL.

Я сам використовую MongoDB і Riak для конкретних проблем, коли RDBMS не є життєздатним рішенням, для всіх інших речей я використовую MySQL (або SQLite для тестування).

Якщо вам потрібен NoSQL db, про який ви зазвичай знаєте, можливі причини:

  • клієнт хоче 99,999% наявності на високому сайті.
  • ваші дані не мають сенсу в SQL, ви виявляєте, що робите кілька запитів JOIN для доступу до якоїсь інформації.
  • ви порушуєте реляційну модель, у вас є CLOB, які зберігають денормалізовані дані, і ви генеруєте зовнішні індекси для пошуку цих даних.

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

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


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

Я намагаюся не відповідати на те саме питання двічі, перегляньте мою попередню відповідь на дуже схоже запитання stackoverflow.com/questions/3621415/…
Асаф

Я погоджуюся з чудовою відповіддю Асафа, що насправді існує лише кілька сценаріїв, коли вам потрібен NoSQL через RDBMS. Я бачу NoSQL більше як резервний DB або "db надбудови", ніж основний db. Я ще не бачив гарної системи, де основним db був NoSQL.
Джо Смо

38

У Мартіна Фаулера є відмінне відео, яке дає добре пояснення баз даних NoSQL. Посилання йде прямо про його причини використовувати їх, але все відео містить хорошу інформацію.

  1. У вас є велика кількість даних, особливо якщо ви не можете вмістити все це на одному фізичному сервері, оскільки NoSQL був розроблений для того, щоб добре масштабувати.

  2. Невідповідність об'єктно-реляційного імпедансу - Ваші доменні об'єкти не вписуються добре у схему реляційних баз даних. NoSQL дозволяє зберігати ваші дані як документи (або графіки), які можуть набагато ближче до вашої моделі даних.


16

NoSQL - це система бази даних, де дані впорядковуються в документ (MongoDB), пара ключ-значення (MemCache, Redis), форма структури графіка (Neo4J).

Можливо, тут можливі запитання та відповіді на запитання "Коли йти на NoSQL":

  1. Потрібна гнучка схема або мати справу з такими деревами?
    Як правило, в умовах гнучкої розробки ми починаємо проектувати систему, не знаючи всіх вимог наперед, де пізніше впродовж усієї системи баз даних розробки можуть знадобитися часті зміни дизайну, демонструючи MVP (мінімальний життєздатний продукт). Або ви маєте справу зі схемою даних, яка має динамічний характер. наприклад, Системні журнали, дуже точним прикладом є журнали AWS cloudwatch.

  2. Набір даних великий / великий?
    Так, база даних NoSQL є кращим кандидатом для додатків, де базі даних потрібно керувати мільйонами, а то й мільярдами записів без шкоди для продуктивності.

  3. Торгуйте між масштабуванням над послідовністю
    На відміну від RDMS, база даних NoSQL тут і там може втрачати невеликі дані (Примітка: ймовірність .x%), але її легко масштабувати з точки зору продуктивності. Приклад: Це може бути корисним для зберігання людей, які перебувають в Інтернеті, у додатку для обміну миттєвими повідомленнями, жетонах в db, реєстрації статистики трафіку веб-сайтів.

  4. Виконання геолокаційних операцій: MongoDB має хеш-підтримку для виконання операцій GeoQuerying та Geolocation. Мені дуже сподобалася ця особливість MongoDB.

Коротше кажучи, MongoDB чудово підходить для програм, де ви можете зберігати динамічні структуровані дані у великих масштабах.


4
"База даних NoSQL тут і там може втрачати невеликі дані" WTF !? Тепер хто з їх розумного хотів би ризикувати? Це повинно бути помилковим.
Джей Q.

1
@JayQ. Так, це може бути помилковим. Тому я сказав * можливо. Тоді чому ми не можемо використовувати NpSQL DB для транзакційних операцій?
Хришикеш

7

Для відповіді на запитання відсутня якась істотна інформація: Які випадки використання повинна охоплювати база даних? Чи потрібно проводити складний аналіз із наявних даних ( OLAP ) або програма повинна мати можливість обробляти багато транзакцій ( OLTP )? Яка структура даних? Це далеко не час закінчення питання.

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

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

Модель документа (як, наприклад, у MongoDB) не підходить для моделей даних, де існує багато взаємозв'язків між даними. Приєднання має відбуватися на рівні додатків, що є додатковими зусиллями, і чому я повинен програмувати речі, які має робити база даних.

Якщо ви зробите аргумент, що Google та Amazon створили власні бази даних, оскільки звичайні RDBMS вже не можуть обробляти потоки даних, ви можете сказати лише: Ви не Google та Amazon. Ці компанії є головою, приблизно 0,01% сценаріїв, коли традиційні бази даних вже не підходять, але для решти світу вони є.

Що не суттєво: SQL існує вже понад 40 років, і мільйони годин розробки пройшли у великих системах, таких як Oracle або Microsoft SQL. Цього треба досягти за допомогою нових баз даних. Іноді також легше знайти адміністратора SQL, ніж когось для MongoDB. Що підводить нас до питання технічного обслуговування та управління. Тема, яка не зовсім сексуальна, але це частина технологічного рішення.


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

3

Я натрапив на це питання, шукаючи переконливих підстав відхилитися від дизайну RDBMS.

Є чудовий пост Джуліана Брауна, який проливає світло на обмеження розподілених систем. Концепція називається теоремою CAP Brewer, яка узагальнюється:

Три вимоги розподілених систем: Послідовність, Доступність та Толерантність до Розбиття (коротше CAP). Але одночасно їх можна мати лише два.

І ось так я підсумував це для себе:

Вам краще піти на NoSQL, якщо послідовність - це те, що ви жертвуєте.


0

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

НЕ

SQL не є застарілим і в деяких випадках залишається кращим інструментом. Важко виправдати використання документоорієнтованого NoSQL, коли

  • Потрібен OLAP / OLTP
  • Це невеликий проект / проста структура БД
  • Потрібні спеціальні запити
  • Не можна уникнути негайної консистенції
  • Незрозумілі вимоги
  • Брак досвідчених розробників

ДО

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

  • Бігти потрібно в масштабі
  • Зручність розробки (краща інтеграція зі своїм технологічним стеком, відсутність необхідності в ORM тощо)

Більше інформації

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

Примітка: вищевикладене стосується лише документа, орієнтованого на NoSQL. Є й інші типи NoSQL, які потребують інших міркувань.


0

Поводження з великою кількістю операцій з читання запису

Погляньте на бази даних NoSQL, коли вам потрібно швидко масштабувати. І коли вам взагалі потрібно швидко масштабувати?

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

Гнучкість при моделюванні даних

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

Подія консистенції над міцною послідовністю

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

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

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

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

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

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

Ми постійно переживаємо таку поведінку. Особливо на YouTube. Часто ви побачите відео з 10 переглядами та 15 лайками. Як це можливо навіть?

Це не. Фактичних поглядів вже більше, ніж подобається. Просто кількість переглядів непослідовна і потребує короткого часу, щоб оновитись.

Запуск даних Analytics

Бази даних NoSQL також найкраще підходять для використання в аналітиці даних, коли нам доводиться мати справу з припливом величезної кількості даних.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.