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

I>Здравствуйте, gandjustas, Вы писали:
I> Например на проектах, на которых работают 99% пишущих в этой теме, это верно.
I>имха цифра в 99% необоснованно завышена.
Только почему-то за все время не объявился никто, у кого проект по нагрузке превосходил бы SO.
Есть отдельные личности с data-intensive задачами, но трафика SO даже близко ни у кого нет.

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

G>>И как это связано? Из-за плохих программистов горизонтальное масштабирование становится дешевле?
I>Именно. Можно взять середнячков и зарядить их педалить бизнес логику по спеке, не особо задумываясь над тем как оно работает изнутри. И ессна ж они налажают, и тупо дешевле поставить еще пару серваков, чем вылизывать код.
Это на стоимость scale up vs scale out не влияет.

G>>И в чем проблема с zero-downtime update? На любой взрослой базе даже проблемы такой нет
I>Ну давай не будем голословными. Вводная: у тебя пару лямов активных сессий, которые упираются в одну бд в десятки терабайт и необходходимо залить новую версию софта, которая интродюсит изменение схемы данных, которая в свою очередь связана с миграцией данных которая выполняется часы.
Я уже рассказывал, возможно прямо в этой теме.
Сначала делается апдейт схемы, а потом изменяется код, который со схемой работает. Если отказаться от идеи "одного большого апдейта", то и проблем не будет.