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

G>Только почему-то за все время не объявился никто, у кого проект по нагрузке превосходил бы SO.
G>Есть отдельные личности с data-intensive задачами, но трафика SO даже близко ни у кого нет.
Ну они канечно же тебе были обязаны отрепортать в личку — и писатели топика, и читатели

G>Что такое "конкурентных сессий" ? Сколько запросов приходилось на фронт-енд?
Количество уникальных юзверей, зашедших на сайт. Которым необходимо права доступа разграничивать и все такое.

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

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