Здравствуйте, itslave, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:
G>>Ну конечно же я обязан считать что у всех пипец какие масштабные проекты и все знают о чем пишут
I>Ну как минимум предположить это ты вполне в состоянии
Я стараюсь использовать научный метод — подвергать сомнению все, что не доказано. За несколько лет холиваров не нашлось ни одного человека с проектами масштаба SO. Поэтому я сомневаюсь в компетентности всех пишуших про нагрузки.

G>>Это за какой период времени? Что за сайт? Сколько запросов на фронтэнд сервер приходится в секунду?
I>Это одновременно. Количество реквестов в секунду того же порядка. Сайт — это NDA.
Что такое "одновременно" ? Ключевая входящая метрика нагрузки — RPS, "того же порядка" это не число, количество фронтэндов тоже неизвестно.
Это и дает основание сомневаться.

G>>Если один кривой запрос положит сервак, то он с таким же успехом положит и два, и три, и десять.
G>>Или ты думаешь что действие говнокода ограничено одним сервером?
I>Я думаю что большинство говнокода(кроме особо запущенных случаев) можно перебороть дополнительными ресурсами. А шардирование позволит не допускать особо идиотских кейсов.
Приведи пример чтоли. Не понимаю как шардирование связано с говнокодом.
Например если из-за говнокода применяется линейный поиск по таблице\коллекции, то шардирование потребует на порядок больше денег, чем исправление говнокода. Но на scale up vs scale out не повлияет.

G>>>>Сначала делается апдейт схемы, а потом изменяется код, который со схемой работает. Если отказаться от идеи "одного большого апдейта", то и проблем не будет.
I>>>Ну вот, на время апдейта схемы и кода система лежит.
G>>С чего ты взял?
I>Ну вот расскажи(или кинь линку), как сделать по другому.
Не пойму что сделать по-другому? Что ты делаешь из-за чего у тебя система останавливается?