Наскільки модель даних впливає на масштабованість та продуктивність у так званій базі даних «NoSQL»?


13

Ніколи не можна говорити про так звану базу даних "NoSQL", не принісши теорему CAP (узгодженість, доступність, розділ: виберіть дві). Якщо вам потрібно вибрати, скажімо, між MongoDB (розділ, послідовність) та CouchDB (доступність, розділ), перше, що вам потрібно подумати, - це "чи потрібні мені правильні дані чи мені весь час потрібен доступ?".

Ці нові бази даних були зроблені для секціонування. Але що робити, якщо я цього не роблю ? Що робити, якщо я просто думаю, що це досить круто, щоб мати ключ / значення, стовпець, документ, будь-яку базу даних замість реляційної, і просто створити один екземпляр сервера і ніколи не розбивати його? У такому випадку не було б у мене і доступності, і послідовності? MongoDB не потрібно було б нічого тиражувати, тому воно буде доступне. А CouchDB мав би лише одне джерело даних, тому це було б досить послідовно.

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

Я прав тут? Чи можу я змінити базу даних AP або CP на мережу змінного струму, не створивши більше одного екземпляра? Або є щось, чого мені не вистачає?

Давайте поставимо питання зворотньо. Що робити, якщо я візьму реляційну базу даних, скажімо MySQL, і поставлю її в конфігурацію master / slaves. Я не використовую транзакції ACID Якщо мені потрібно негайно синхронізувати будь-яке записування до підлеглого, чи не це зробить це базою даних CP? А що робити, якщо я синхронізую її з деякими заздалегідь заданими інтервалами, і не має значення, чи читає клієнт застарілі дані з підлеглого. Хіба це не зробить це базою даних AP? Чи не означає це, що якщо я відмовлюся від відповідності ACID, я все-таки можу використовувати модель relanal для розділеної бази даних?

По суті: чи масштабність щодо того, що ви готові відмовитись у теоремі CAP, більше, ніж основна модель даних? Чи має колона, документ, ключове значення, що б не сприяло збільшенню масштабності за реляційною моделлю? Чи можемо ми створити реляційну базу даних, розроблену з нуля для толерантності до розділів? (Можливо, воно вже існує). Чи можемо ми зробити базу даних NoSQL ACID сумісною?

Вибачте, це багато питань, але останнім часом я багато читав про базу даних NoSQL, і мені здається, що найбільша перевага їх використання полягає в тому, що вони краще підходять до "форми" ваших даних, а не просто до розділу, CAP і відмова від відповідності ACID. Зрештою, не всі мають стільки даних, що їм потрібно їх розділити. Чи є користь від продуктивності / масштабування від того, щоб не використовувати реляційну модель, перш ніж я навіть подумати про розподіл своїх даних?

Відповіді:


8

Чи використовує базу даних NoSQL посилення масштабованості, навіть якщо ви не уточнюєте дані? Добре давайте визначити масштабованість. Якщо ви посилаєтесь на масштабованість, оскільки це стосується систем баз даних / бекенду, якщо у вас є вертикальне та горизонтальне масштабування, де горизонтальне масштабування IS поглиблює дані, то це стає тривіальним питанням, оскільки тоді відповідь буде абсолютно ні, тому що єдиний варіант, який вам залишився - це вертикальне масштабування (тобто покращення обладнання). Якщо ж ви говорите про масштабованість у більш широкому розумінні, маючи на увазі гнучкість програми, значення даних тощо ... То це зовсім інше питання з низкою відповідей. І як ви вже згадували, це часто зводиться до того, що ви робите з даними та як вони повинні зберігатися. Дозвольте мені перед цим все передбачити з твердженням, що в більшості випадків ви все-таки використовуєте RDBMS, а NoSQL повинен заповнити ніші. Далі наведено опис конкретного екземпляра, коли база даних NoSQL була б більш корисною з огляду на конкретні вимоги, і де ми можемо ігнорувати горизонтальне масштабування.

Візьмемо для прикладу ідею, що ви створюєте хмарну систему зберігання файлів, схожу на диск Google, Dropbox або вікно, але замість того, щоб використовувати фактичну файлову систему, ви вирішите, що вам було б вигідніше віртуалізувати файлову систему. Тепер у вас є проблема, оскільки ваша модель даних раптом є структурою дерева, яка буде жахливо неефективною в RDBMS (незважаючи на те, що так все індексується). Тому що тепер у вас є 3 стовпчикова таблиця з ім'ям, користувачем та батьківським. Користувач - це іноземний ключ до таблиці користувачів, а Parent - це власний посилання на нульовий зовнішній ключ (зведений через те, що в кореневій директорії не може бути батьківського). Отже, що є первинним ключем? У цьому випадку це складний ключ у всіх стовпцях ... Що раптом робить Батька найгіршим ворогом.

Тепер замість цього подумайте, як би ви це помістили в якійсь формі зберігання документів? Замість того, щоб боротися з даними, ви можете працювати з ними і зберігати їх як структуру дерева, що, в свою чергу, скоротить ваш час розробки, а також зменшить витрати на обслуговування. Якщо ви зменшуєте витрати, чи не дозволяє це масштабувати різний вид? Плюс у цьому випадку ви правильно створюєте систему з нуля, що повинно дати більшу гнучкість самому додатку. В даний час я запускаю це на одному сервері за допомогою MongoDB, що, як ви пояснили, дає мені доступну, послідовну модель, яка не сильно відрізняється, ніж дивитися на різницю MySQL або Postgres.

Щонайменше, у MongoDB ви можете визначити, скільки серверів вам потрібно зв’язати, щоб запит був успішним, так, ви можете перетворити його на послідовну, доступну модель, якщо ви повідомлите всі запити для зв'язку з усіма екземплярами сервера.

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

Я правильно зрозумів ваше запитання?

Редагувати: чи більше сповільнить дані? Так. На скільки це сповільнить справи? Я, чесно кажучи, не маю достатнього досвіду, щоб дати адекватну відповідь. Ключ / значення: По суті таблиця пошуку з великою кількістю даних, пов'язаних з ключем пошуку. Це дійсно буде дуже швидко, оскільки ви можете шукати речі лише за ключем. Стовпець / сім'я: По суті набагато більш структурований магазин ключів / цінностей. Ви можете запитувати лише на основі стовпця, і це теж має бути дуже швидким. Документ: схема стилю агрегації. Тут ви хочете об'єднати подібні дані разом. Для такого типу баз даних денормалізація нормальна і очікувана. Залежно від того, чи багато ви пишете чи читаєте, ви можете впорядкувати свої дані так, щоб вони розподілялися по декількох фрагментах для розподілу записів або зчитувань (зауважте, що ви можете створити гібридний підхід, який підходить як для вас, так і взагалі потрібно вибрати оптимізацію для тієї чи іншої) Графік: Сила цього полягає в тому, що він може створювати та руйнувати відносини дуже швидко. Якщо у вас є деякі дані, де у вас є стосунки, які потрібно змінювати між даними (подумайте, деяка форма механізму рекомендацій), тоді вам слід скористатися цим.

Спосіб зберігання даних у будь-якій із цих баз даних впливатиме на ефективність роботи (подібно до того, що якщо ви неправильно зберігаєте дані в деяких RDBMS, це вплине на продуктивність). Тож сподіваємось зробити це більш зрозумілим: вам потрібно знати, яку систему баз даних слід використовувати, а також як зберігати дані в цій системі баз даних.


Так, такої відповіді я очікував. В якості точності я мав на увазі масштабованість як здатність системи обробляти все більшу кількість завдань без задухи, більше, ніж чиста проблема апаратної масштабованості (можливо, це був не правильний термін). Наприклад, Nginx може обробляти більше одночасних запитів, ніж Apache, завдяки своїй архітектурі на основі подій. І тому запитання було начебто "На машині з фіксованим обладнанням, чи використовує базу даних, що не стосуються, дозволяє мені обслуговувати більше користувачів, перш ніж я досягти межі?"
Лоран Буро-Рой

У такому випадку це залежатиме від системи баз даних, яку ви використовуєте. На прикладі моєї вище хмарної файлової системи я використовую Redis для фактичного зберігання файлів, і вони можуть похвалитися тим, що можуть обробляти 100 000 запитів в секунду (тому що він був створений як запам'ятовуючий ключ / сховище). Тепер я фактично не перевіряв свою програму, щоб побачити, з чим вона насправді може працювати, але саме так пише веб-сайт Redis. Слід пам’ятати, що за кадром, що дані представлені по-різному, залежно від різних типів бази даних, яку ви використовуєте. Заповніть ніші належним дб.
harageth

1
Я відредагував свою відповідь, тому що це було простіше, ніж додавати більше коментарів.
harageth

2
+1 це фантастичний старт у P.SE, сподіваємось, ви будете тримати час і продовжувати додавати якісний контент, як цей!
Джиммі Хоффа

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