Масштабируемость — это свойство системы справляться с растущим объемом работы. Одно из определений для программных систем указывает, что это может быть достигнуто путем добавления ресурсов в систему. [1]
В экономическом контексте масштабируемая бизнес-модель подразумевает, что компания может увеличить продажи при увеличении ресурсов. Например, система доставки посылок масштабируема, поскольку можно доставить больше посылок, добавив больше транспортных средств. Однако, если бы все посылки сначала проходили через один склад для сортировки, система не была бы такой масштабируемой, поскольку один склад может обрабатывать только ограниченное количество посылок. [2]
В вычислительной технике масштабируемость является характеристикой компьютеров, сетей, алгоритмов , сетевых протоколов , программ и приложений. Примером может служить поисковая система , которая должна поддерживать растущее число пользователей и число индексируемых ею тем . [3] Webscale — это подход к компьютерной архитектуре, который переносит возможности крупных компаний облачных вычислений в корпоративные центры обработки данных. [4]
В распределенных системах существует несколько определений, согласно авторам, некоторые рассматривают концепции масштабируемости как часть эластичности , другие как отдельные. По словам Марка Брукера: «система масштабируется в диапазоне, где предельная стоимость дополнительной рабочей нагрузки почти постоянна». Бессерверные технологии соответствуют этому определению, но вам нужно учитывать общую стоимость владения, а не только стоимость инфраструктуры. [5]
В математике масштабируемость в основном относится к замкнутости относительно скалярного умножения .
В промышленном проектировании и производстве масштабируемость относится к способности процесса, системы или организации справляться с растущей рабочей нагрузкой, адаптироваться к растущим требованиям и поддерживать операционную эффективность. Масштабируемая система может эффективно управлять возросшими объемами производства, новыми линейками продукции или расширяющимися рынками без ущерба для качества или производительности. В этом контексте масштабируемость является жизненно важным фактором для предприятий, стремящихся оправдать ожидания клиентов, оставаться конкурентоспособными и достичь устойчивого роста. Факторы, влияющие на масштабируемость, включают гибкость производственного процесса, адаптивность рабочей силы и интеграцию передовых технологий. Внедряя масштабируемые решения, компании могут оптимизировать использование ресурсов, сократить расходы и оптимизировать свои операции. Масштабируемость в промышленном проектировании и производстве позволяет предприятиям реагировать на меняющиеся рыночные условия, извлекать выгоду из появляющихся возможностей и процветать в постоянно меняющемся глобальном ландшафте. [ необходима цитата ]
Система управления инцидентами (ICS) используется агентствами по реагированию на чрезвычайные ситуации в Соединенных Штатах. ICS может масштабировать координацию ресурсов от пожара на обочине дороги с одним двигателем до лесного пожара на межгосударственном уровне. Первый ресурс на месте происшествия устанавливает командование, имея полномочия заказывать ресурсы и делегировать ответственность (управление пятью-семью офицерами, которые снова делегируют полномочия семи и так далее по мере разрастания инцидента). По мере расширения инцидента более старшие офицеры принимают на себя командование. [6]
Масштабируемость можно измерить по нескольким параметрам, например: [7]
Ресурсы делятся на две основные категории: горизонтальные и вертикальные. [8]
Горизонтальное масштабирование (вне/внутрь) означает добавление или удаление узлов, например, добавление нового компьютера в распределенное программное приложение. Примером может служить масштабирование с одного веб-сервера до трех. Высокопроизводительные вычислительные приложения, такие как сейсмический анализ и биотехнологии , масштабируют рабочие нагрузки горизонтально для поддержки задач, которые когда-то потребовали бы дорогих суперкомпьютеров . Другие рабочие нагрузки, такие как крупные социальные сети, превышают возможности самого большого суперкомпьютера и могут обрабатываться только масштабируемыми системами. Использование этой масштабируемости требует программного обеспечения для эффективного управления ресурсами и обслуживания. [7]
Вертикальное масштабирование (вверх/вниз) означает добавление ресурсов к (или удаление ресурсов из) одного узла, обычно включающее добавление процессоров, памяти или хранилища к одному компьютеру. [7]
Преимущества масштабирования включают в себя избежание увеличения сложности управления, более сложное программирование для распределения задач между ресурсами и решения таких проблем, как пропускная способность, задержка, синхронизация между узлами. Более того, некоторые приложения не масштабируются горизонтально .
Виртуализация сетевых функций определяет эти термины по-разному: масштабирование наружу/внутрь — это возможность масштабирования путем добавления/удаления экземпляров ресурсов (например, виртуальной машины), тогда как масштабирование вверх/вниз — это возможность масштабирования путем изменения выделенных ресурсов (например, памяти/ЦП/емкости хранилища). [9]
Масштабируемость баз данных требует, чтобы система базы данных могла выполнять дополнительную работу с учетом больших аппаратных ресурсов, таких как дополнительные серверы, процессоры, память и хранилище. Рабочие нагрузки продолжали расти, и требования к базам данных следовали за ними.
Алгоритмические инновации включают блокировку на уровне строк и секционирование таблиц и индексов. Архитектурные инновации включают архитектуры «ничего общего» и «всего общего» для управления конфигурациями нескольких серверов.
В контексте масштабируемого хранилища данных масштабируемость определяется как максимальный размер кластера хранения, который гарантирует полную согласованность данных, то есть существует только одна допустимая версия хранимых данных во всем кластере, независимо от количества избыточных физических копий данных. Кластеры, которые обеспечивают «ленивую» избыточность путем обновления копий асинхронным способом, называются «в конечном итоге согласованными» . Этот тип масштабируемого дизайна подходит, когда доступность и скорость реагирования оцениваются выше согласованности, что справедливо для многих веб-сервисов размещения файлов или веб-кэшей ( если вам нужна последняя версия, подождите несколько секунд, пока она распространится ). Для всех классических приложений, ориентированных на транзакции, такой дизайн следует избегать. [10]
Многие кластеры хранения с открытым исходным кодом и даже коммерческие масштабируемые кластеры, особенно те, которые построены на основе стандартного оборудования ПК и сетей, обеспечивают только конечную согласованность, например, некоторые базы данных NoSQL, такие как CouchDB и другие, упомянутые выше. Операции записи делают другие копии недействительными, но часто не ждут их подтверждений. Операции чтения обычно не проверяют каждую избыточную копию перед ответом, потенциально пропуская предыдущую операцию записи. Большой объем трафика сигналов метаданных потребует специализированного оборудования и коротких расстояний для обработки с приемлемой производительностью (т. е. действуя как некластеризованное устройство хранения или база данных). [ необходима цитата ]
Если ожидается высокая согласованность данных, обратите внимание на следующие индикаторы: [ необходима ссылка ]
Индикаторы для в конечном итоге согласованных конструкций (не подходят для транзакционных приложений!): [ необходима ссылка ]
Часто советуют сосредоточиться на проектировании системы на масштабируемости оборудования, а не на емкости. Обычно дешевле добавить новый узел в систему, чтобы добиться повышения производительности, чем участвовать в настройке производительности для повышения емкости, которую может обрабатывать каждый узел. Но этот подход может иметь убывающую отдачу (как обсуждалось в инженерии производительности ). Например: предположим, что 70% программы можно ускорить, если распараллелить и запустить на нескольких ЦП вместо одного. Если — это часть вычисления, которая является последовательной, а — это часть, которая может быть распараллелена, максимальное ускорение , которого можно достичь с помощью процессоров P, определяется в соответствии с законом Амдаля :
Подставляя значение для этого примера, используя 4 процессора, получаем
Удвоение вычислительной мощности до 8 процессоров дает
Удвоение вычислительной мощности ускорило процесс всего лишь примерно на одну пятую. Если бы вся задача была параллелизуема, скорость также удвоилась бы. Поэтому добавление большего количества оборудования не обязательно является оптимальным подходом.
В распределенных системах вы можете использовать универсальный закон масштабируемости (USL) для моделирования и оптимизации масштабируемости вашей системы. USL был придуман Нилом Дж. Гюнтером и количественно определяет масштабируемость на основе таких параметров, как конкуренция и согласованность. Конкуренция относится к задержке из-за ожидания или очередей для общих ресурсов. Согласованность относится к задержке для того, чтобы данные стали согласованными. Например, наличие высокой конкуренции указывает на последовательную обработку, которая может быть распараллелена, в то время как наличие высокой согласованности предполагает чрезмерные зависимости между процессами, побуждая вас минимизировать взаимодействия. Кроме того, с помощью USL вы можете заранее рассчитать максимальную эффективную емкость вашей системы: масштабирование вашей системы за пределами этой точки является пустой тратой. [11]
В высокопроизводительных вычислениях есть два общих понятия масштабируемости:
{{cite journal}}
: CS1 maint: DOI inactive as of June 2024 (link)