Масштабируемость

Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Найти источники:  «Масштабируемость»  -  новости  · газеты  · книги  · ученый  · JSTOR ( март 2012 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

Масштабируемость - это свойство системы справляться с растущим объемом работы за счет добавления в систему ресурсов. ^[1]

В экономическом контексте масштабируемая бизнес-модель подразумевает, что компания может увеличить продажи при увеличении ресурсов. Например, система доставки пакетов является масштабируемой, потому что можно доставить больше пакетов, добавив больше средств доставки. Однако, если бы все пакеты сначала прошли через один склад для сортировки, система не была бы масштабируемой, потому что один склад может обрабатывать только ограниченное количество пакетов. ^[2]

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

В математике масштабируемость в основном относится к замыканию при скалярном умножении .

Примеры [ править ]

Система управления инцидентами (ICS) используется агентствами экстренного реагирования в США. ICS может масштабировать координацию ресурсов от однодвигательного придорожного пожара до межгосударственного лесного пожара. Первый ресурс на сцене устанавливает команду с полномочиями распоряжаться ресурсами и делегировать ответственность (управление пятью-семью офицерами, которые снова будут делегировать до семи, и далее по мере роста инцидента). По мере развития инцидента командование принимает более старшие офицеры. ^[5]

Размеры [ править ]

Масштабируемость можно измерить по нескольким параметрам, например: ^[6]

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

Домены [ править ]

• Протокол маршрутизации считается масштабируемым относительно размера сети, если размер необходимой таблицы маршрутизации на каждом узле растет как O (журнал N ), где N есть число узлов в сети. Некоторые ранние одноранговые (P2P) реализации Gnutella имели проблемы с масштабированием. Каждый запрос узел затоплены свои запросы на все узлы. Спрос на каждого однорангового узла увеличивался пропорционально общему количеству одноранговых узлов, быстро превышая их возможности. Другие системы P2P, такие как BitTorrentхорошо масштабируется, потому что спрос на каждого однорангового узла не зависит от количества одноранговых узлов. Ничего не централизовано, поэтому система может неограниченно расширяться без каких-либо ресурсов, кроме самих узлов.
• Масштабируемая онлайн- система обработки транзакций или система управления базами данных - это система, которую можно модернизировать для обработки большего количества транзакций путем добавления новых процессоров, устройств и хранилища, и которую можно легко и прозрачно обновлять, не выключая ее.
• Распределенный характер системы доменных имен позволяет ей работать эффективно, обслуживая миллиарды хостов во всемирном Интернете .

Горизонтальное (масштабирование) и вертикальное масштабирование (масштабирование) [ править ]

Ресурсы делятся на две большие категории: горизонтальные и вертикальные. ^[7]

По горизонтали или по горизонтали [ править ]

Горизонтальное масштабирование (выход / вход) означает добавление дополнительных узлов (или удаление узлов) в систему, например добавление нового компьютера к распределенному программному приложению. Примером может быть масштабирование с одного веб-сервера до трех. Высокопроизводительные вычислительные приложения, такие как сейсмический анализ и биотехнология , масштабируют рабочие нагрузки по горизонтали для поддержки задач, которые раньше требовали дорогостоящих суперкомпьютеров . Другие рабочие нагрузки, такие как крупные социальные сети, превышают возможности самого большого суперкомпьютера и могут обрабатываться только масштабируемыми системами. Для использования этой масштабируемости требуется программное обеспечение для эффективного управления ресурсами и их обслуживания. ^[6]

Вертикально или в увеличенном масштабе [ править ]

Вертикальное масштабирование (вверх / вниз) означает добавление ресурсов к одному узлу (или удаление ресурсов из него), как правило, с добавлением ЦП, памяти или хранилища к одному компьютеру. ^[6]

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

Виртуализация сетевых функций определяет эти термины по-разному: масштабирование / увеличение - это возможность масштабирования путем добавления / удаления экземпляров ресурсов (например, виртуальной машины), тогда как масштабирование вверх / вниз - это возможность масштабирования путем изменения выделенных ресурсов (например, памяти / ЦП. /вместимость склада). ^[8]

Масштабируемость базы данных [ править ]

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

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

Сильная или возможная согласованность (хранение) [ править ]

В контексте горизонтально масштабируемого хранилища данных масштабируемость определяется как максимальный размер кластера хранилища, который гарантирует полную согласованность данных, то есть существует только одна допустимая версия хранимых данных во всем кластере, независимо от количества избыточных физических копий данных. . Кластеры, обеспечивающие «ленивую» избыточность за счет асинхронного обновления копий, называются «согласованными в конечном итоге» . Этот тип горизонтально масштабируемого дизайна подходит, когда доступность и скорость реагирования оцениваются выше, чем согласованность, что верно для многих веб-служб хостинга файлов или веб-кешей ( если вам нужна последняя версия, подождите несколько секунд, чтобы она распространялась ). Для всех классических приложений, ориентированных на транзакции, этого следует избегать. ^[9]

Многие кластеры хранения с открытым исходным кодом и даже коммерческие горизонтально масштабируемые кластеры, особенно построенные на основе стандартного оборудования ПК и сетей, обеспечивают только конечную согласованность. Идентифицируйте некоторые базы данных NoSQL, такие как CouchDB и другие, упомянутые выше. Операции записи делают другие копии недействительными, но часто не ждут их подтверждения. Операции чтения обычно не проверяют каждую избыточную копию перед ответом, что может привести к пропуску предыдущей операции записи. Большой объем сигнального трафика метаданных потребует специализированного оборудования и небольших расстояний, которые будут обрабатываться с приемлемой производительностью (т.е. действовать как некластеризованное запоминающее устройство или база данных).

Если ожидается высокая согласованность данных, обратите внимание на следующие индикаторы:

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

Индикаторы для в конечном итоге согласованных проектов (не подходящих для транзакционных приложений!):

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

Настройка производительности в сравнении с масштабируемостью оборудования [ править ]

Часто рекомендуется сосредоточить проектирование системы на масштабируемости оборудования, а не на емкости. Обычно дешевле добавить новый узел в систему для повышения производительности, чем участвовать в настройке производительности для повышения пропускной способности, которую может обрабатывать каждый узел. Но этот подход может иметь убывающую отдачу (как обсуждается в области проектирования производительности ). Например: предположим, что 70% программы можно ускорить, если распараллелить ее и запустить на нескольких процессорах вместо одного. Если - это доля последовательных вычислений, и - это доля, которая может быть распараллелена, максимальное ускорение, которое может быть достигнуто с помощью P-процессоров, задается в соответствии с законом Амдала :${\ displaystyle \ alpha}$${\displaystyle 1-\alpha }$

${\displaystyle {\frac {1}{\alpha +{\frac {1-\alpha }{P}}}}.}$

Подстановка значения для этого примера с использованием 4 процессоров дает

${\displaystyle {\frac {1}{0.3+{\frac {1-0.3}{4}}}}=2.105.}$

Удвоение вычислительной мощности до 8 процессоров дает

${\displaystyle {\frac {1}{0.3+{\frac {1-0.3}{8}}}}=2.581.}$

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

Слабое против сильного масштабирования [ править ]

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

• Сильное масштабирование определяется как изменение времени решения в зависимости от количества процессоров при фиксированном общем размере задачи.
• Слабое масштабирование определяется как изменение времени решения в зависимости от количества процессоров при фиксированном размере задачи на процессор . ^[10]

См. Также [ править ]

Ссылки [ править ]

Внешние ссылки [ править ]

Поищите информацию о масштабируемости в Викисловаре, бесплатном словаре.

• Архитектура высокомасштабируемого сервера на базе NIO - статья о написании масштабируемого сервера на Java (java.net).
• Ссылки на разнообразные учебные ресурсы - страница, созданная проектом memcached .
• Масштабируемое определение - от Linux Information Project (LINFO)
• Масштаб в распределенных системах Б. Клиффорд Нейман, В: Readings in Distributed Computing Systems , IEEE Computer Society Press, 1994