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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

Простыми словами

масштабирование по горизонтали ===> Все тысячи миньонов вместе делают всю работу за вас

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

Ответ 3

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

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

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

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

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

Ответ 4

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

Load-Balancer отвечает за распространение пользовательских запросов (нагрузки) между различными внутренними системами/машинами/узлами в кластере. Каждая из этих серверных машин запускает копию вашего программного обеспечения и, следовательно, может обслуживать запросы. Это всего лишь одна из функций, которые может выполнять балансировка нагрузки. Еще одна очень общая ответственность - "проверка работоспособности", когда балансировщик нагрузки использует протокол "пинг-эхо" или обменивается сообщениями со всеми серверами, чтобы обеспечить их бесперебойную работу.

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

Запрос-ответ также может быть выполнен двумя разными способами:

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

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

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

Сначала нам нужно определить наши бизнес-цели и области, в которых мы хотели бы добавить ценность. Эти цели приведут к возникновению различных требований. Затем мы задаем себе различные вопросы в отношении различных системных свойств.

• Будет ли такой дизайн соответствовать нашим требованиям к производительности?

• Какие характеристики производительности нам интересны? Является ли это общей пропускной способностью системы, где мы заинтересованы в обслуживании максимального количества запросов в любой момент времени? Или это время отклика системы, в котором мы проектируем для отправки ответа клиенту как можно меньше времени? Оба эти и многие другие характеристики производительности связаны друг с другом.

• Будет ли такой дизайн соответствовать нашим требованиям доступности? Является ли система отказоустойчивой? Если да, то какова его степень?

• Является ли такая конструкция надежной? Это влияет на правильность? Мы не должны забывать, что 100% правильность является неявной целью любой системы.

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

Все эти требования должны иметь количественные меры, связанные с ними.

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

• Во-первых, использует load-balancer единственный подход для распределения нагрузки и горизонтального масштабирования системы?

• Разделяют ли различные серверы или узлы друг с другом друг с другом? Если да, то как система обращается к ситуации, когда один или несколько узлов опускаются - постоянно или временно? Если да, то как система обращается к ситуации, когда сеть, соединяющая узлы, опускается, но все узлы работают и работают? Самое главное, нужно ли нам различать эти две ситуации? Как?

• Независимо от того, взаимодействуют ли серверные узлы друг с другом, нужна ли нам система для поддержания согласованных данных по всем узлам? На каком уровне последовательности мы заботимся? Это оно В любой момент времени данные по всем узлам должны быть согласованными. Или позже какой-то момент времени данные по всем узлам будут согласованы. Если да, то что это "позже"? Когда и как все узлы сходятся к согласованному состоянию? Как мы получим "полный порядок" операций по всем узлам? У нас есть глобальные часы? Если мы полагаемся на каждые локальные часы node, то как мы синхронизируем часы всех машин. Они могут легко казаться регрессией, или машина с неработоспособностью часов может присоединиться к кластеру. Как следствие, мы можем игнорировать последние данные и рассматривать старые/устаревшие данные как самые последние.
• Какую настройку кластера нам нужно разрабатывать? Является ли это "копией" кластера, где данные на каждом node реплицируются в некоторые или любые другие node. В случае с первым, каков фактор репликации и как мы это решаем? Или это осколок кластера, где кластер разделен на различные осколки или юниты. Осколок представляет собой определенную группу узлов. Каждый осколок заботится о конкретном разделе данных. Данные по осколкам не реплицируются, но каждый осколок может принимать стратегию репликации внутри себя. Независимо от того, какую распределенную систему мы разрабатываем, она в идеале должна быть в состоянии ответить на вышеупомянутые и многие другие подобные вопросы.

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

Вертикальное масштабирование - также называемое "масштабируемым" подходом - попытка увеличить емкость одной машины: Добавляя больше вычислительной мощности Добавляя больше хранилища Больше памяти и т.д. Краткое описание:

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

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

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

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

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