Різниця між масштабуванням по горизонталі та вертикалі для баз даних [закрито]

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

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

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

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

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

Хорошими прикладами горизонтального масштабування є Cassandra, MongoDB, Google Cloud Spanner .., а хорошим прикладом вертикального масштабування є MySQL - Amazon RDS (хмарна версія MySQL). Це дає простий спосіб вертикального масштабування шляхом переходу від невеликих до великих машин. Цей процес часто передбачає простої.

Сітки даних в пам'яті, такі як GigaSpaces XAP , когерентність тощо., Часто оптимізуються як для горизонтального, так і для вертикального масштабування просто тому, що вони не прив'язані до диска. Горизонтальне масштабування через розділення та вертикальне масштабування через багатоядерну підтримку.

Більше про цю тему ви можете прочитати в моїх попередніх публікаціях: « Розширення проти масштабування» та «Загальні принципи за альтернативами NOSQL»

Масштабування горизонтально ===> Тисячі міньйонів зроблять роботу разом за вас.

Масштабування по вертикалі ===> Один великий лук зробить всю роботу за вас.

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

Коли ви зрозумієте, що ваша система стає повільною і не в змозі обробити поточну кількість запитів, вам потрібно масштабувати систему.

Це надає вам два варіанти. Або ви збільшуєте ресурси на сервері, який ви використовуєте в даний час, тобто збільшуєте об'єм оперативної пам'яті, процесора, GPU та інших ресурсів. Це відомо як вертикальне масштабування.

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

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

Сподіваюся, ви отримаєте всю концепцію введення масштабування в систему.

Існує додаткова архітектура, про яку не згадувалося - сервіси баз даних на базі SQL, що дозволяють горизонтальне масштабування без складності ручного різкості. Ці сервіси роблять різкісні зображення у фоновому режимі, тому вони дозволяють запускати традиційну базу даних SQL і масштабувати, як би ви працювали з движками NoSQL, такими як MongoDB або CouchDB. Дві сервіси, з якими я знайомий, це EnterpriseDB для PostgreSQL та Xeround для MySQL. Я побачив поглиблений пост від Xeround, в якому пояснюється, чому масштабування на базі даних SQL є складним і як вони роблять це по-різному - ставитеся до цього із зерном солі, оскільки це посада постачальника. Ознайомтеся також із записом хмарних баз даних Вікіпедії, є приємне пояснення SQL порівняно з NoSQL та сервіс у порівнянні з власною організацією, список постачальників та параметри масштабування для кожної комбінації. ;)

Так, масштабування по горизонталі означає додавання більшої кількості машин, але це також означає, що машини кластери рівні. MySQL може горизонтально масштабувати з точки зору зчитування даних за допомогою використання реплік, але як тільки він досягне місткості пам’яті / диска сервера, вам доведеться розпочати розширювати дані на серверах. Це стає все більш складним. Часто збереження послідовних даних у репліках є проблемою, оскільки частоти тиражування занадто повільні, щоб не відставати від швидкості зміни даних.

Couchbase - це також фантастична база даних по горизонтальному масштабуванню NoSQL, яка використовується у багатьох комерційних додатках та іграх із високою доступністю та, мабуть, найвищий показник у цій категорії. Він автоматично розбиває дані по кластеру, додавання вузлів є простим, і ви можете використовувати товарне обладнання, дешевші екземпляри vm (наприклад, використовуючи Large замість High Mem, High Disk на AWS). Він побудований за допомогою Membase (Memcached), але додає стійкості. Крім того, у випадку Couchbase кожен вузол може читати і записувати, і вони рівні в кластері, з лише відмовою реплікації (не повна реплікація набору даних на всіх серверах, як у mySQL).

Виходячи з продуктивності, ви можете побачити відмінний орієнтир Cisco: http://blog.couchbase.com/understanding-performance-benchmark-publisher-cisco-and-solarflare-using-couchbase-server

Ось чудовий пост у блозі про Couchbase Architecture: http://horicky.blogspot.com/2012/07/couchbase-architecture.html

Традиційні реляційні бази даних були розроблені як системи баз даних клієнт / сервер. Їх можна масштабувати горизонтально, але процес цього має тенденцію бути складним та схильним до помилок. Бази даних NewSQL на зразок NuoDB - це орієнтована на пам'ять системи баз даних, розроблена для масштабування горизонтально, зберігаючи властивості SQL / ACID традиційних RDBMS.

Для отримання додаткової інформації про NuoDB прочитайте їх технічну документацію .

Бази даних SQL, такі як Oracle, db2, також підтримують горизонтальне масштабування через кластер спільного диска. Наприклад, Oracle RAC, purescale IBM DB2 або видання Sybase ASE Cluster. Новий вузол може бути доданий до системи Oracle RAC або системи Purecale DB2 для досягнення горизонтального масштабування.

Але підхід відрізняється від баз даних noSQL (наприклад, mongodb, CouchDB або IBM Cloudant) полягає в тому, що розширення даних не є частиною горизонтального масштабування. У базах даних noSQL дані знижуються під час горизонтального масштабування.

У вас є компанія, і є лише 1 працівник, але ви отримали 1 новий проект на той момент, ви наймаєте нового кандидата - це горизонтальне масштабування. де новий кандидат - нові машини, а проект - новий трафік / дзвінки до ваших api.

Де, як 1 проект, з хлопцем IIT / NIT, який обробляє всі запити на ваш api / трафік. Якщо в будь-який час більше запитів на ваш api, тоді звільніть його і замініть його на високому IQ NIT / IIT хлопця - це вертикальне масштабування.

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

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

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

Прийнята відповідь є місцем у базовому визначенні горизонтального проти вертикального масштабування. Але на відміну від загальноприйнятої думки, що горизонтальне масштабування баз даних можливе лише за допомогою Кассандри, MongoDB тощо. Я хотів би додати, що горизонтальне масштабування також дуже можливо з будь-якими традиційними RDMS; це теж без використання сторонніх рішень.

Мені відомо багато компаній, спеціально на базі SaaS, які роблять це. Це робиться за допомогою простої логіки програми. Ви в основному приймаєте набір користувачів і ділите їх на декілька серверів БД. Так, наприклад, ти зазвичай маєш "мета" базу даних / таблицю, яка б зберігала клієнтів, сервер DB / рядки підключення тощо та таблицю, в якій зберігається відображення клієнта / сервера.

Потім просто направляйте запити кожного клієнта на сервер БД, на який вони відображені.

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

Єдина різниця між двома підходами до горизонтального масштабування полягає в тому, що один підхід (MongoDB тощо) масштабування проводиться самим програмним забезпеченням БД. У цьому сенсі ви "купуєте" масштабування. В іншому підході (для горизонтального масштабування RDBMS) масштабування будується за допомогою коду / логіки програми.