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


699

Я сталкивался со многими базами данных NoSQL и базами данных SQL. Существуют различные параметры для измерения сильных и слабых сторон этих баз данных, и масштабируемость является одним из них. В чем разница между горизонтальным и вертикальным масштабированием этих баз данных?


2
en.wikipedia.org/wiki/Scalability - этот термин применяется ко всем программным продуктам / системам
Томаш Нуркевич

5
Обратите особое внимание на раздел базы данных en.wikipedia.org/wiki/Scalability#Database_scalability
user454322

Ответы:


1261

Горизонтальное масштабирование означает, что вы масштабируете, добавляя больше машин в пул ресурсов, тогда как вертикальное масштабирование означает, что вы масштабируете, добавляя больше мощности (ЦП, ОЗУ) к существующей машине .

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

                  Горизонтальное масштабирование / визуализация вертикального масштабирования

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

При горизонтальном масштабировании часто проще динамически масштабировать, добавляя больше машин в существующий пул. Вертикальное масштабирование часто ограничивается мощностью одной машины, масштабирование сверх этой емкости часто приводит к простоям и имеет верхний предел.

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

Сетки данных в памяти, такие как GigaSpaces XAP , Coherence и т. Д., Часто оптимизируются как для горизонтального, так и для вертикального масштабирования просто потому, что они не привязаны к диску. Горизонтальное масштабирование посредством разделения и вертикальное масштабирование благодаря поддержке многоядерных процессоров.

Вы можете прочитать больше на эту тему в моих предыдущих постах: Масштабирование против Масштабирования и Общие принципы, стоящие за альтернативами NOSQL


1
Есть также Couchbase, Riak, HBase, CitrusLeaf и Infinispan, чтобы завершить список немного дальше (есть и другие).
scalabl3

3
@Nati Shalom Базы данных NOSQL масштабируются горизонтально?
Бхушан Фираке

2
@BillyMoon Я слышал, что это может быть возможно с Mysql Galera
Сэм Стоилинга

9
я немного запутался здесь ... добавление большего количества машин - это то же самое, что и добавление большего количества процессоров / оперативной памяти ... то, чем они отличаются, потому что когда мы добавляем новую машину, она идет с процессором и оперативной памятью, пожалуйста, исправьте меня, если я я не прав
Субхам Трипати

8
@ SubhamTripathi Как объяснено здесь, вертикальное масштабирование ограничено одним сервером (или небольшой группой серверов) и имеет практический верхний предел (то есть вы не можете выйти за пределы, скажем, 512 ГБ ОЗУ). Горизонтальное масштабирование, с другой стороны, может происходить практически бесконечно.
спрашивает

200

Горизонтальное масштабирование ===> Тысячи миньонов сделают всю работу за вас.

Вертикальное масштабирование ===> Один большой халк сделает всю работу за вас.

введите описание изображения здесь


Очень хорошая аналогия!
Никита Куртин

20

Давайте начнем с необходимости масштабирования, которое увеличивает ресурсы, чтобы ваша система теперь могла обрабатывать больше запросов, чем раньше.

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

Это дает вам два варианта. Либо вы увеличиваете ресурсы на сервере, который используете в данный момент, то есть увеличиваете объем оперативной памяти, процессора, графического процессора и других ресурсов. Это известно как вертикальное масштабирование.

Вертикальное масштабирование обычно дорого. Это не делает систему отказоустойчивой, т. Е. Если вы масштабируете приложение, работающее с одним сервером, если этот сервер выходит из строя, ваша система выключается. Также количество потоков остается неизменным при вертикальном масштабировании. Вертикальное масштабирование может потребовать выключения вашей системы в тот момент, когда происходит процесс. Увеличение ресурсов на сервере требует перезагрузки и выключения вашей системы.

Другое решение этой проблемы - увеличение количества серверов, присутствующих в системе. Это решение широко используется в технологической отрасли. Это в конечном итоге уменьшит частоту запросов в секунду на каждом сервере. Если вам нужно масштабировать систему, просто добавьте другой сервер, и все готово. Вам не потребуется перезапускать систему. Количество потоков в каждой системе уменьшается, что приводит к высокой пропускной способности. Чтобы разделить запросы одинаково для каждого сервера приложений, необходимо добавить балансировщик нагрузки, который будет работать в качестве обратного прокси-сервера для веб-серверов. Вся эта система может называться одним кластером. Ваша система может содержать большое количество запросов, которые требуют большего количества кластеров, подобных этому.

Надеюсь, вы получите всю концепцию внедрения масштабирования в систему.


9

Существует еще одна архитектура, которая не была упомянута - это службы баз данных на основе SQL, которые обеспечивают горизонтальное масштабирование без сложного разделения вручную. Эти сервисы выполняют сегментирование в фоновом режиме, поэтому они позволяют запускать традиционную базу данных SQL и масштабироваться, как если бы вы работали с механизмами NoSQL, такими как MongoDB или CouchDB. Мне знакомы две службы: EnterpriseDB для PostgreSQL и Xeround для MySQL. Я видел подробное сообщение от Xeround, в котором объясняется, почему масштабирование в базах данных SQL сложно и как они делают это по-разному - относитесь к этому с недоверием, так как это сообщение поставщика. Также проверьте запись в облачной базе данных Википедии, есть хорошее объяснение SQL против NoSQL и сервиса против собственного размещения, список поставщиков и опции масштабирования для каждой комбинации. ;)


В качестве еще одного источника данных я отправляю еще одну публикацию поставщика от Clustrix: clustrix.com/blog/bid/259950/scale-up-vs-scale-out
clieu

Как насчет Amazon RDS?
Раджа Нагендра Кумар

1
Я знаю, что это старый пост ... только некоторые обновления ... Xeround закрыл магазин. Параметры горизонтального масштабирования в PostreSQL на самом деле не являются параметрами горизонтального масштабирования - это просто параметры репликации БД, в которых вы можете создавать некоторые операции для реплицируемой БД.
Дхармендар Кумар 'DK'

8

Да, горизонтальное масштабирование означает добавление большего количества машин, но это также означает, что машины в кластере равны. MySQL может масштабироваться горизонтально с точки зрения чтения данных посредством использования реплик, но как только он достигнет емкости сервера mem / disk, вы должны начать разделять данные между серверами. Это становится все более сложным. Часто поддержание согласованности данных между репликами является проблемой, поскольку скорости репликации часто слишком медленные, чтобы не отставать от скорости изменения данных.

Couchbase также является фантастической базой данных горизонтального масштабирования NoSQL, используемой во многих коммерческих приложениях и играх с высокой доступностью и, возможно, самой высокой производительностью в категории. Он автоматически распределяет данные по кластеру, добавляя узлы просто, и вы можете использовать обычное оборудование, более дешевые экземпляры VM (например, Large вместо High Mem, High Disk на AWS). Он построен на основе Membase (Memcached), но добавляет постоянство. Кроме того, в случае Couchbase каждый узел может выполнять операции чтения и записи и являются равными в кластере с единственной отказоустойчивой репликацией (не полная репликация набора данных на всех серверах, как в mySQL).

Что касается производительности, вы можете увидеть отличный тест Cisco: http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server

Вот отличный пост в блоге об архитектуре Couchbase: http://horicky.blogspot.com/2012/07/couchbase-architecture.html


6

Традиционные реляционные базы данных были разработаны как системы клиент-серверных баз данных. Их можно масштабировать по горизонтали, но этот процесс сложен и подвержен ошибкам. Базы данных NewSQL, такие как NuoDB, являются распределенными системами баз данных, ориентированными на память, и предназначены для горизонтального масштабирования при сохранении свойств SQL / ACID традиционных СУБД.

Для получения дополнительной информации о NuoDB, прочитайте их технический технический документ .


5

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

Но подход отличается от баз данных noSQL (таких как mongodb, CouchDB или IBM Cloudant) тем, что разделение данных не является частью горизонтального масштабирования. В базах данных noSQL данные затеняются при горизонтальном масштабировании.


1

У вас есть компания и есть только 1 работник, но в то время вы получили 1 новый проект и нанимаете нового кандидата - это горизонтальное масштабирование. где новый кандидат - новые машины, а проект - новый трафик / звонки на ваши API.

Где как 1 проект с парнем IIT / NIT, обрабатывающим все запросы к вашему API / трафику. Если в любое время будет больше запросов к вашему API, тогда уволите его и замените его на парня с высоким IQ NIT / IIT - это вертикальное масштабирование.


0

Добавление большого количества балансировщиков нагрузки создает дополнительные издержки и задержку, что является недостатком горизонтального масштабирования в базах данных nosql. Это как вопрос, почему люди говорят, что RPC не рекомендуется, поскольку он не является надежным.

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

С другой стороны, сложные транзакционные запросы имеют высокую производительность, если используются базы данных sql, такие как oracle. NoSql может быть использован для больших данных и горизонтальной масштабируемости путем шардинга.


0

Принятым ответом является определение базового определения горизонтального и вертикального масштабирования. Но в отличие от распространенного мнения, что горизонтальное масштабирование баз данных возможно только с Cassandra, MongoDB и т. Д. Я хотел бы добавить, что горизонтальное масштабирование также очень возможно с любой традиционной RDMS; это тоже без использования сторонних решений.

Я знаю много компаний, особенно SaaS, которые делают это. Это делается с помощью простой логики приложения. В основном вы берете набор пользователей и делите их на несколько серверов БД. Так, например, у вас обычно есть «мета» база данных / таблица, в которой будут храниться клиенты, сервер БД / строки подключения и т. Д., И таблица, в которой хранится сопоставление клиент / сервер.

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

Теперь некоторые могут сказать, что это сродни горизонтальному разделению, а не «истинному» горизонтальному масштабированию, и они будут в некотором смысле правильными. Но конечный результат заключается в том, что вы масштабировали свою БД на нескольких серверах БД.

Единственное различие между двумя подходами к горизонтальному масштабированию заключается в том, что один подход (MongoDB и т. Д.) Масштабирования выполняется самим программным обеспечением БД. В этом смысле вы «покупаете» масштабирование. В другом подходе (для горизонтального масштабирования СУБД) масштабирование строится с помощью кода / логики приложения.

Купить против сборки

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.