Чому бази даних noSQL більш масштабовані, ніж SQL?

Останнім часом я багато читав про noSQL СУБД. Я розумію теорему CAP , правила ACID, правила BASE та основну теорію. Але не знайшли жодних ресурсів щодо того, чому noSQL масштабується легше, ніж RDBMS (наприклад, у випадку системи, яка вимагає багато серверів БД)?

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

Чи може хто-небудь пояснити, як noSQL / SQL впливає на масштабованість?

бази даних noSQL відмовляються від великої кількості функціональних можливостей, які надає база даних SQL за своєю суттю.

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

Бази даних noSQL не мають усього цього. Якщо вам потрібен цей матеріал, вам потрібно зробити це самостійно, але якщо вам НЕ потрібен (і багато додатків, які цього не роблять), хлопчик, як вам пощастило. БД не повинен виконувати всі ці складні операції та блокування на більшій частині набору даних, тому розділити річ на багатьох серверах / дисках / будь-якому іншому, і це дуже швидко.

Не про NoSQL проти SQL, а про BASE проти ACID.

Масштабованість має бути розбита на складові:

• Масштабування читання = обробляти більші обсяги операцій зчитування
• Масштабування запису = обробляти більші обсяги операцій запису

Бази даних, сумісні з кислотами (як традиційні RDBMS), можуть масштабувати читання. Вони за своєю суттю не менш ефективні, ніж бази даних NoSQL, оскільки (можливі) вузькі місця продуктивності вводяться через речі, яких NoSQL (іноді) не вистачає (наприклад, приєднання та де обмеження), які ви не можете використовувати. Кластеризовані SQL RDBMS можуть масштабувати зчитування, вводячи додаткові вузли в кластер. Існують обмеження щодо масштабування масштабування операцій зчитування, але вони накладаються труднощами масштабування записів, коли ви вводите більше вузлів у кластер.

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

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

Щоб збільшити масштаб операцій запису або кількості вузлів у кластері за певний момент, ви повинні мати можливість розслабити деякі вимоги до кислотної кислоти:

• Видалення Atomicity дозволяє скоротити тривалість, за яку таблиці (набори даних) заблоковані. Приклад: MongoDB, CouchDB.
• Випадання консистенції дозволяє масштабувати записи по вузлах кластера. Приклади: ріак, кассандра.
• Зниження довговічності дає змогу відповідати на записи команд, не передаючи на диск. Приклади: memcache, redis.

Бази даних NoSQL зазвичай відповідають моделі BASE замість моделі ACID. Вони відмовляються від вимог A, C та / або D, а натомість покращують масштабованість. Деякі, як-от Кассандра, дозволяють вам увімкнути гарантії ACID, коли вони вам потрібні. Однак не всі бази даних NoSQL постійно масштабуються.

У API SQL відсутній механізм для опису запитів, де вимоги ACID послаблені. Ось чому бази даних BASE - це все NoSQL.

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

Оновлення (2019-09-17):

Ландшафт баз даних змінився з моменту опублікування цієї відповіді. Поки все ще існує дихотомія між світом RDBMS ACID та світом NoSQL BASE, лінія стала нечіткішою. Бази даних NoSQL додають такі функції зі світу RDBMS, як підтримка API SQL та підтримка транзакцій. Зараз є навіть бази даних, які обіцяють масштабування SQL, ACID та запису масштабів, наприклад, Cloud Cloud Spanner, YugabyteDB або CockroachDB. Зазвичай диявол є в деталях, але для більшості цілей це "достатньо кислоти". Для більш глибокого занурення в технологію баз даних та про те, як вона розвивалася, ви можете подивитися на цю слайд-колоду (до нотаток про слайди додається пояснення).

Це правда, що бази даних NoSQL (MongoDB, Redis, Riak, Memcached тощо) не підтримують зовнішні ключові обмеження, і атомні операції повинні бути більш чітко вказані. Правда також, що бази даних SQL (SQL Server, Oracle, PostgreSQL тощо) можна масштабувати, щоб обробляти дуже великі вимоги до продуктивності досвідченими DBA.

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

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

Від IBM developerWorks: Постачання масштабованості даних на рівні хмари за допомогою баз даних NoSQL

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

Системи NoSQL мають ряд спільних функцій дизайну:

• Можливість горизонтального масштабування пропускної здатності на багатьох серверах.
• Простий інтерфейс або протокол рівня виклику (на відміну від прив'язки SQL).
• Підтримка більш слабких моделей узгодженості, ніж транзакції ACID у більшості традиційних RDBMS.
• Ефективне використання розподілених індексів та оперативної пам’яті для зберігання даних.
• Можливість динамічно визначати нові атрибути або схему даних.

Чому реляційні бази даних можуть бути не оптимальними для масштабування

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

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

Інший приклад: для веб-сайтів із великим обсягом, таких як eBay, Amazon, Twitter або Facebook, масштабованість та висока доступність є важливими вимогами, які не можна порушувати. Для цих додатків навіть найменший збій може мати значні фінансові наслідки та вплинути на довіру клієнтів.

На DBA.SE: Що означає горизонтальне масштабування?

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

Горизонтальне масштабування використовується, коли у вас є можливість запускати кілька екземплярів на серверах одночасно. Зазвичай набагато складніше переходити з 1 сервера на 2 сервери, тоді це переходити від 2 до 5, 10, 50 і т.д.

Після вирішення питань запуску паралельних екземплярів ви можете скористатись великими перевагами таких середовищ, як Amazon EC2, хмарний сервіс Rackspace, GoGrid тощо, оскільки ви можете збільшувати і зменшувати екземпляри на основі попиту, зменшуючи необхідність оплати за потужність сервера ви використовуєте не тільки для покриття цих пікових навантажень.

Реляційні бази даних - один із найскладніших елементів паралельного виконання повного читання / запису.