Чому NoSQL швидше, ніж SQL?

Нещодавно мене запитали:

Чому NoSQL швидше, ніж SQL?

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

Я щось пропускаю про NoSQL?

Навколо існує багато рішень NoSQL, кожне з яких має свої сильні та слабкі сторони, тому наступне потрібно сприймати із зерном солі.

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

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

Більше того, у багатьох рішеннях NoSQL неможливо робити довільні приєднання, отже, довільні запити. Деякі бази даних, наприклад CouchDB, вимагають заздалегідь продумати запити, які вам знадобляться, та підготувати їх всередині БД.

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

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

Тож якщо хтось задає вам таке питання на співбесіді, це повинна бути відповідь.

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

Відсутні функції залежать від конкретного продукту, загалом повні властивості ACID або навіть операції приєднання не підтримуються. Це ціна на підвищення продуктивності.

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

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

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

Подивіться цю статтю, яка порівнює використання дискового простору MySQL та використання MongoDB: http://blog.trackerbird.com/content/mysql-vs-mongodb-disk-space-usage

Яка база даних NoSQL? Яка база даних SQL? Якщо хтось скаже вам, що NoSQL швидше, ніж SQL, тоді вам слід піти. Або ще краще дивіться це відео:

http://www.youtube.com/watch?v=b2F-DItXtZs

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

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

NoSql підтримується колонками, орієнтованими на стовпці, де RDBMS - це база даних, орієнтована на рядки ... І скажімо, наприклад, у нас є таблиця Employee з ім'ям, віком, продажем, адресою, EmployeeId і т. Д ... ми поміщаємо ту саму таблицю в MySql (підтримка RDBMS) та HBase (Підтримка NoSQL). Якщо замовник / клієнт пише запит, щоб отримати середній реквізит про вік або продаж із записів співробітників 1Lakh ... що відбувається?

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

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

Для прикладу візьмемо цей приклад, у вас є модель клієнта з багатьма замовленнями та багатьма предметами, пов’язаними з кожним замовленням, тоді вони також мають багато збережених товарів для наступних покупок ... якщо ви великий магазин електронної комерції, скажімо, 10 мільйонів клієнтів і 50 мільйонів замовлень. І цей замовник заходить у свою панель приладів, на якій відображаються ці точні дані, скільки роботи потрібно буде виконати в базі даних sql, щоб знайти клієнта, приєднатись до замовлень та кожної позиції та збережених позицій. У базі даних sql всі ці дані, швидше за все, потрібно буде якось з'єднати ... або ти можеш створити колекцію в базі даних ур під назвою usercache та зберегти ці дані саме тим, як ти їх використовуєш у реальному житті. Таким чином, це справді може бути один запит у одному полі [id], щоб повернути всі ці дані. Крім цього, база даних nosql не робить '

То чи може sql db запитувати одне поле Id так само швидко, якщо не швидше, ніж nosql? Так, але чи може база даних sql повертати всі потрібні вам дані, запитуючи одну таблицю та одне поле? Ні, якщо ви не зробите щось на зразок збереження даних у Json у великому текстовому полі. Але тепер ці дані не підлягають запиту для подальшого використання.