Что для вас означает масштабируемость?

Я смотрю на масштабируемость с двух точек зрения:

Увеличение масштаба

Если я добавлю больше оперативной памяти к компьютеру, на котором что-то работает, насколько я получу дополнительную производительность и емкость? Если одно приложение, которое у меня есть, может обрабатывать на 300 дополнительных подключений и работает на 15 % быстрее, когда я добавляю 2 ГБ ОЗУ на свой сервер, а другое приложение может обрабатывать только 100 дополнительных подключений и работает на 5 % быстрее, приложение A явно более масштабируемо.

Масштабирование

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

Это, кстати, один из основных дисков n-tier.

Масштабируемость означает способность справляться с ростом в любой из этих двух областей:

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

2) Способность обрабатывать все большую и большую нагрузку, которая может быть несколькими одновременными запросами в веб-разработке или большими наборами данных для простого веб-сайта, управляемого базой данных, например. не могли бы вы создать приложение, которое обрабатывает таблицы с сотнями тысяч строк, которое все еще рассматривается как «быстрое»?

Вообще для меня масштабируемость означает возможность роста.

Я не думаю, что масштабируемость имеет смысл без контекста.

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

(Хорошо, поэтому ответ на все эти вопросы обычно «Да»; затем добавьте к этим вопросам слово «Как».)

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

Или представьте сайт социальной сети, на котором реализована захватывающая новая функция, позволяющая вам видеть, находятся ли ваши друзья в сети, и общаться с ними через приятный пользовательский интерфейс Ajax. Внезапно, без увеличения пользовательской базы, количество HTTP-запросов, обрабатываемых вашими серверами в день, подскочило в двадцать раз, и ваши заботы о масштабируемости вашей базы данных отошли на второй план. (Если, конечно, вы не задействовали базу данных в своем чат-приложении. Хорошая мысль!)

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

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

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

Просто чтобы добавить к сообщению @Lou Franco.

PLINQ даже имеет причудливую «суперлинейную» производительность в некоторых сценариях с ограниченными накладными расходами (согласно некоторым их демонстрациям). Попробуйте.

Если вы разбираетесь в C++, Microsoft также планирует выпустить функции параллелизма, которые, по-видимому, не связаны с затратами во время выполнения, и дополнительные инструменты параллелизма на основе задач, которые помогут вам лучше звонить.

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

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

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

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

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

Могу ли я обрабатывать больше (трафик, данные, обработка), добавляя больше стандартного оборудования? даже используя «облачные серверы» amazon ec2, google app engine и подобные?

Масштабируемость означает, что я могу втиснуть n ресурсов в систему, и она будет расти как в пространстве, так и во времени между O(log(n)) и O(n log n). Это несколько нереально, но именно так я думаю о «масштабируемости».

Ух!, громко сказано....

Я определяю его по-новому для каждого проекта, потому что это зависит от того, чего хочет клиент.

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