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

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

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

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

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

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

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

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

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

Вы можете прочитать больше на эту тему в моих предыдущих сообщениях: Scale-out vs Scale-up и Common Principles за альтернативами NOSQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вертикальное масштабирование – также называемое «масштабируемым» подходом – это попытка увеличить пропускную способность одной машины: добавив больше вычислительной мощности. Добавив больше памяти. Больше памяти и т. Д. Резюме:

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

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

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

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

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

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

Вот отличный блог о Couchbase Architecture: http://horicky.blogspot.com/2012/07/couchbase-architecture.html

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

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

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

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

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

Это дает вам два варианта: либо вы увеличиваете ресурсы на сервере, который используете в настоящее время, т. Е. Увеличиваете количество ram, CPU, gpu и других ресурсов. Это известно как вертикальное масштабирование.

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

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

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

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

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

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

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

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

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

Interesting Posts

Вызов универсального метода с аргументом типа, известным только во время выполнения

Запуск кода инициализации AngularJS при загрузке представления

Eclipse продолжает сбой

Notepad ++ как скопировать текст (только), который соответствует выражению регулярного выражения (не всей строки)

В Mac OS X как я могу контролировать, что использует мое интернет-соединение?

Что может привести к перерыву сетевого интерфейса?

Форма перехода к директиве

Как предотвратить очистку вывода терминала при выходе из сеанса SSH?

ASP.NET MVC. Потенциально опасное значение Request.Form было обнаружено у клиента при использовании настраиваемого модуля-шаблона

Как установитьContentView в fragmentе?

Пропуск аутентификации Kerberos с помощью JSch

Сбой соединения openSSH с помощью одноранговой сети

Как сравнить локальную ветвь git с удаленной ветвью?

Лучший способ ограничить доступ по IP-адресу?

Зачем мне нужна транзакция в Hibernate для работы только для чтения?

Давайте будем гением компьютера.