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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, горизонтальное масштабирование означает добавление большего количества машин, но это также означает, что машины в кластере равны. 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

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

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

Базы данных 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 новый проект и нанимаете нового кандидата - это горизонтальное масштабирование. где новый кандидат - новые машины, а проект - новый трафик / звонки на ваши API.

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

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

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

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

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

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

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

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

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