(no subject)

[109]

архитекторы яндекса считают, что дизайн системы на 10,000 qps ничем не отличается от дизайна системы на 1,000,000 qps. а я было обрадовался возможности интересного разговора.

Comments

[anatolix.livejournal.com]

Я не на нее ссылался, но это не важно. Я тоже легко могу оперировать термином cost-effective как и гугль, это совсем не то же что точные "throughput, latency, data volume", которых обрати внимание с архитектуре гугля нет.

Кроме того точное соотношение "throughput, latency, data volume" можно посчитать уже для детализованной архитектуры - а не на стадии "задумки". Там ты можешь только понять, чем и примерно в какой пропорции ты готов пожертовать, ради чего другого. Что я вообще говоря и описал.
http://anatolix.livejournal.com/48336.html?thread=796112#t796112
И вообще помоему при фиксированном количестве железа фраза "максимизировать throughput" гораздо более точно объясняет, что хочется получить чем просто "cost effective"

По поводу же расширяемости - обрати внимание что в гугле нет документов "вот наша архитектура когда у нас было 100 серверов, вот когда 1000, вот когда 10000, а вот сейчас когда 400000" - у них там одна бумажка. И про map/reduce ихний аналогично.

Из примеров про смену архитектуры можно вспомнить недавний переезд yahoo на hadoop. Машин стало много, нужно чтобы они не выпадали, сделали вот такую систему. Но вообще говоря при переходе они отметили, что производительность выросла в 1.5 раза - поэтому наверное их предыдущее решение нельзя считать cost effective - если бы они так сделали с самого начала было бы лучше.

Про trade-off я про них хорошо понимаю, просто в моем мире они делаются по живой системе. За последние пол года мы поменяли архитектуру поискового кластера по мелочи раз 10, но в сумме она осталась той же самой. Т.е. я их считаю низкоувовневой архитектурой, а не высокоуровневой(в ЖЖ низкоуровневую не обсудишь по хорошему, слишком много подробностей и просто тупо много писать)