Как сделать так, чтобы мои приложения хорошо масштабировались?

Джефф и Джоэл обсуждают масштабирование в Подкаст Stack Overflow # 19.

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

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

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

Используйте это, чтобы сосредоточить свои усилия на разработке

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

Сначала создайте максимально простой код, затем профилируйте систему и оптимизируйте только тогда, когда есть очевидная проблема с производительностью.

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

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

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

Один из способов приблизиться к этому:

    for each car {
       determine my position;  
       for each car {  
         add my position to this car's map;  
       }
    }

Это кажется простым: посмотрите на позицию первой машины, добавьте ее на карту каждой другой машины. Затем посмотрите на положение второй машины, добавьте ее на карту всех остальных автомобилей. И Т. Д.

Но есть проблема масштабируемости. Когда есть 2 машины, эта стратегия требует 4 шага «добавить мою позицию»; когда есть 3 машины, нужно 9 шагов. Для каждого «обновления местоположения» вы должны прокручивать весь список автомобилей - и каждая машина нуждается в обновлении своего местоположения.

Игнорирование того, сколько других вещей нужно сделать с каждой машиной (например, может потребоваться фиксированное количество шагов для вычисления положения отдельной машины), для N автомобилей для запуска этого алгоритма требуется N² "посещений автомобилей".. Это не проблема, когда у вас 5 машин и 25 ступенек. Но когда вы добавите машины, вы увидите, что система увязнет. 100 автомобилей сделают 10 000 шагов, а 101 автомобиль сделает 10 201 шаг!

Лучшим подходом было бы отменить вложенность циклов for.

    for each car {  
      add my position to a list;  
    }  
    for each car {    
      give me an updated copy of the master list;  
    }

При этой стратегии количество шагов кратно N, а не N². Таким образом, на 100 машин потребуется в 100 раз больше работы, чем на 1 машину, а НЕ в 10 000 раз больше работы..

Эта концепция иногда выражается в «нотации большого O» - количество необходимых шагов составляет «большое O из N» или «большое O из N²».

Обратите внимание, что эта концепция касается только масштабируемости, а не оптимизации количества шагов для каждой машины. Здесь нас не волнует, 5 шагов или 50 шагов на машину - главное, чтобы N машин делали (X * N) шагов, а не (X * N²).

FWIW, большинство систем будут наиболее эффективно масштабироваться, игнорируя это до тех пор, пока это не станет проблемой - закон Мура все еще действует, и если ваш трафик не растет быстрее, чем закон Мура, обычно дешевле просто купить коробку большего размера (по 2 или 3 тысячи долларов за штуку). поп), чем платить разработчикам.

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

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