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

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

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

важное преимущество горизонтальной масштабируемости заключается в том, что он может предоставить администраторам возможность увеличить пропускную способность летать. Другим преимуществом является то, что теоретически горизонтальная масштабируемость ограничена только тем, сколько объектов может быть успешно подключено. Распределенная система хранения данных Cassandra, например, работает поверх сотен товарных узлов, разбросанных по разным дата-центрам. Поскольку товарное оборудование масштабируется горизонтально, Cassandra отказоустойчива и не имеет ни одной точки отказа (SPoF).

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

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

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

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

Couchbase также фантастическая база данных горизонтального масштабирования NoSQL, используемая во многих коммерческих приложениях высокой доступности и играх и, возможно, самый высокий исполнитель в категории. Он автоматически разбивает данные по кластерам, добавление узлов просто, и вы можете использовать товарное оборудование, более дешевые экземпляры vm (например, используя большие, а не высокие Mem, высокие дисковые машины в AWS). Он построен на Membase (Memcached), но добавляет постоянство. Кроме того, в случае вы, каждый узел может выполнять чтение и запись и равен в кластере, только с отказоустойчивой репликацией (не полная репликация набора данных на всех серверах, как в 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 likeNuoDB-это ориентированные на память распределенные системы баз данных, предназначенные для горизонтального масштабирования при сохранении свойств SQL / ACID традиционных СУБД.

для получения дополнительной информации о NuoDB, читать их технической документации на http://goo.gl/uzLIWB.

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

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

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

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

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

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

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

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

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

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

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

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