ага, уже "почти", а не совсем. теперь, если это "почти" транслируется в сто килобаксов бабла - наплюём на сто килобаксов? хочу в россию. и это только один порядок величины, а я говорил про два.
если ты можешь всеми регуляторами двигать - что я могу сказать, кроме "хорошо тебе" или там "опять хочу в россию". думаю, что такое редко бывает. хотя с другой стороны, мне мало чем можно двигать, потому что параметров меньше, что в свою очередь дизайн упрощает.
У тебя, кстати, какие вообще задачи, что ты можешь так точно предсказать поток запросов? Как юзеры себя поведут обычно xz - станет сервис популярным и это его добьет - обидно будет.
P.S. Вообще да, килобаксы это порядок стоимости одного сервера. мегабаксы - вот тут считаем уже.
В контексте директ зарабатывает 1M$ в день, и проблемы в prime time на час это те самые 100K.
Плюс в любом случае у нас запас по мощности должен быть в идеале в 1/3, чтобы работать без одного DC, если его враги взорвут - по сравнению с этим 100K это просто копейки.
про регуляторы: обычно всегда можно двигать всем. вопрос только в том сколько это стоит.
Т.е. например всегда есть выбор положить систему вообще или не обслуживать часть пользователей. Прикол просто в том, что и для тебя и для меня это очень дорогое решение. Тем не менее если выбор будет между полной неработоспособностью и неработой для половины пользователей со стабильностью для всех остальных я его не задумываясь сделаю.
Точно так же твикаются все остальные параметры. Да в ТЗ написано, так-то, заказчик хочет то-то, но жизнь она сложней. Задумайся над гипотетической ситуацией "через час система полностью прекратит работу, какими параметрами я готов пожертвовать, чтобы этого избежать" и ты поймешь, что очень большое количество регуляторов которые ранее были недоступны, сейчас можно крутить.
И самое важное: на разговаривали про _АРХИТЕКТУРУ_ системы. Конкретный заказ машин к разработке архитектуры имеет косвенное отношение.
Повторю своий вопрос, который я задал в прошлый раз не совсем точно: "Если ты поймешь, что почти бесплатно можно сделать _АРХИТЕКТУРУ_ для 60K тыс запросов, но тебе нужно 6K, значит ли это, что ты не будешь ее масштабировать до этого предела?"
Ты же согласен, что не смотря на то, что про превратить систему 1M в 10K убиранием машин почти всегда можно?
я именно про архитектуру, которая будет иметь лишние компоненты, для которых нужно лишнее железо, плюс понижение надёжности, которое нужно компенсировать увеличением redundancy, то есть опять лишнее железо.
процитирую, что ли, сам себя:
ещё раз: если мы проделаем мысленный эксперимент, описанный мной, и обнаружим, что scaled down system имеет кучу ненужного и её на самом деле можно было сделать в два раза дешевле - это и означает, что системы не масштабируются "просто так", for free. это и означает, что эффективный (в смысле, как минимум, cost-effective) дизайн системы на 10,000 отличается от дизайна на 1,000,000.
Мы с тобой помоему разные вещи понимаем под дизайном. Для меня дизайн это детализованная основная идея системы. Новые компоненты можно поселить и не на выделенные машины, с redundancy, что-нибудь придумать в виде хака и т.п.
Но основных компонентов там будет _примерно_ "столько-же умножить 100", запросы будут ходить похожим образом. Возможно добавится level чего-нибудь. И вообще если любому не сильно подготовленному человеку показать этот дизайн он скажет что второй вырос из первого. А не то что "это 2 совершенно по разному спроектированные системы".
Что реализация на практике отличается я согласен, для того чтобы хотя бы электричество и охлаждение для 100 раз большего количества машин обеспечить это отдельное совершенно развлечение.
ну, во-первых, я считаю, ты отлично проиллюстрировал мой пойнт, перейдя от "ровно в 100 раз" и "абсолютно линейно" к "примерно в 100 раз" и "а может, N * ln(N), да и то не всегда".
во-вторых, продолжающаяся настойчивость в повторении того, что дизайн на N должен быть таким же, как на 100N (раньше было в точности, теперь приблизительно) и нежелание формулировать требования к системе в явном виде заставляет меня предположить, что ты и не решал никогда задачи, сформулированные как "сделать эффективный дизайн, который обеспечит throughput A, latency B на объёме данных C". а решал ты задачи, сформулированные (явно или неявно) как "сделать дизайн, который будет скалироваться в сотни раз без особых изменений".
Даже в том котором был до яндекса - я никогда не писал систем которые в одном месте внедрят и больше трогать никогда в жизни не будут, и объем и тип данных никогда не изменится.
Более того в продуктовой компании не вижу в этом подходе смысла(возможно у консалтеров имеет - типа "после нас хоть потоп" или "за новую архитектуру платите новые деньги, так для нас даже лучше, что старая не реюзается" ). Мне кажется ты свою систему тоже напишешь и к тебе прибегут и скажут "отлично у тебя получилось. Давай еще такую же на в десятеро большее количество запросов". Что ты будешь делать - совершенно новую архитектуру? А потом снова ее тестировать тянет ли она?
А еще возвращаясь к первоначальной дискуссии в первом топике - там мы проектировали что-то GFS-о подобное, или поиско-подобное. http://anatolix.livejournal.com/48336.html?thread=793040#t793040 Практически уверен, что у людей в гугле не было задачи "написать систему которая вот столько понянет, но наиболее эффективно", а была, чтобы "вот это эффективно масштабировалось".
Поэтому я собственно и не понимал(и сейчас не понимаю) твои требования точно привести количество запросов и объем данных, и мне кажется, что эти запросы (как и последующий переход на личности) в том месте были не уместны.
P.S. (Извини не удержался ;) Поэтому мне кажется, что "ты не решал задачи вида 'сделать дизайн, который будет скалироваться в сотни раз без особых изменений' " именно в терминах которых нужно проектировать поисковики и серьезные распределенные FS и БД
(расстроенно уходит) я совсем не хотел переходить на личности. извини ещё раз.
что я пытался сделать, так это найти общий язык и какие-нибудь общие примитивы (например - throughput, latency, data volume), опираясь на которые можно дальше беседу строить. а вместо этого уже который пост вижу только hand waving и мифические "скалироваться в сотни раз без особых изменений". я на таком языке разговаривать не в состоянии, несмотря на горячее желание.
далее, статья "THE GOOGLE CLUSTER ARCHITECTURE", на которую ты сам же вроде и ссылался, постоянно оперирует термином cost-effective. cost, cost, cost. и это очевидно. невероятно же тут то, что все мои аргументы про cost-effective были так же просто hand waved.
Поэтому мне кажется, что "ты не решал задачи вида 'сделать дизайн, который будет скалироваться в сотни раз без особых изменений' " именно в терминах которых нужно проектировать поисковики и серьезные распределенные FS и БД
я такие задачи не решал никогда, потому что задачи так не стоят никогда. потому что в формулировке задачи всегда есть словосочетание "cost-effective". и потому что "скалироваться в сотни раз без изменений" и "cost-effective" are mutually exclusive. потому что любая серьёзная архитектура - это комплекс большого числа trade-offов, и без осознания того, какой же trade-off мы совершаем данным архитектурным решением особо много не наархитектуришь. sheesh.
Я не на нее ссылался, но это не важно. Я тоже легко могу оперировать термином 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, но в сумме она осталась той же самой. Т.е. я их считаю низкоувовневой архитектурой, а не высокоуровневой(в ЖЖ низкоуровневую не обсудишь по хорошему, слишком много подробностей и просто тупо много писать)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
109![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2008-02-21 10:02 pm (UTC)ага, уже "почти", а не совсем. теперь, если это "почти" транслируется в сто килобаксов бабла - наплюём на сто килобаксов? хочу в россию. и это только один порядок величины, а я говорил про два.
если ты можешь всеми регуляторами двигать - что я могу сказать, кроме "хорошо тебе" или там "опять хочу в россию". думаю, что такое редко бывает. хотя с другой стороны, мне мало чем можно двигать, потому что параметров меньше, что в свою очередь дизайн упрощает.
(no subject)
Date: 2008-02-22 08:58 am (UTC)P.S. Вообще да, килобаксы это порядок стоимости одного сервера. мегабаксы - вот тут считаем уже.
В контексте директ зарабатывает 1M$ в день, и проблемы в prime time на час это те самые 100K.
Плюс в любом случае у нас запас по мощности должен быть в идеале в 1/3, чтобы работать без одного DC, если его враги взорвут - по сравнению с этим 100K это просто копейки.
(no subject)
Date: 2008-02-22 10:55 pm (UTC)вот, кстати, ещё: http://109.livejournal.com/396572.html?thread=1497116
(no subject)
Date: 2008-02-22 10:57 pm (UTC)(no subject)
Date: 2008-02-22 09:06 am (UTC)Т.е. например всегда есть выбор положить систему вообще или не обслуживать часть пользователей. Прикол просто в том, что и для тебя и для меня это очень дорогое решение. Тем не менее если выбор будет между полной неработоспособностью и неработой для половины пользователей со стабильностью для всех остальных я его не задумываясь сделаю.
Точно так же твикаются все остальные параметры. Да в ТЗ написано, так-то, заказчик хочет то-то, но жизнь она сложней. Задумайся над гипотетической ситуацией "через час система полностью прекратит работу, какими параметрами я готов пожертвовать, чтобы этого избежать" и ты поймешь, что очень большое количество регуляторов которые ранее были недоступны, сейчас можно крутить.
(no subject)
Date: 2008-02-22 10:35 am (UTC)Конкретный заказ машин к разработке архитектуры имеет косвенное отношение.
Повторю своий вопрос, который я задал в прошлый раз не совсем точно:
"Если ты поймешь, что почти бесплатно можно сделать _АРХИТЕКТУРУ_ для 60K тыс запросов, но тебе нужно 6K, значит ли это, что ты не будешь ее масштабировать до этого предела?"
Ты же согласен, что не смотря на то, что про превратить систему 1M в 10K убиранием машин почти всегда можно?
(no subject)
Date: 2008-02-22 11:02 pm (UTC)процитирую, что ли, сам себя:
ещё раз: если мы проделаем мысленный эксперимент, описанный мной, и обнаружим, что scaled down system имеет кучу ненужного и её на самом деле можно было сделать в два раза дешевле - это и означает, что системы не масштабируются "просто так", for free. это и означает, что эффективный (в смысле, как минимум, cost-effective) дизайн системы на 10,000 отличается от дизайна на 1,000,000.
(no subject)
Date: 2008-02-23 11:27 am (UTC)Но основных компонентов там будет _примерно_ "столько-же умножить 100", запросы будут ходить похожим образом. Возможно добавится level чего-нибудь. И вообще если любому не сильно подготовленному человеку показать этот дизайн он скажет что второй вырос из первого. А не то что "это 2 совершенно по разному спроектированные системы".
Что реализация на практике отличается я согласен, для того чтобы хотя бы электричество и охлаждение для 100 раз большего количества машин обеспечить это отдельное совершенно развлечение.
(no subject)
Date: 2008-02-23 09:31 pm (UTC)во-вторых, продолжающаяся настойчивость в повторении того, что дизайн на N должен быть таким же, как на 100N (раньше было в точности, теперь приблизительно) и нежелание формулировать требования к системе в явном виде заставляет меня предположить, что ты и не решал никогда задачи, сформулированные как "сделать эффективный дизайн, который обеспечит throughput A, latency B на объёме данных C". а решал ты задачи, сформулированные (явно или неявно) как "сделать дизайн, который будет скалироваться в сотни раз без особых изменений".
(no subject)
Date: 2008-02-26 04:31 pm (UTC)Даже в том котором был до яндекса - я никогда не писал систем которые в одном месте внедрят и больше трогать никогда в жизни не будут, и объем и тип данных никогда не изменится.
Более того в продуктовой компании не вижу в этом подходе смысла(возможно у консалтеров имеет - типа "после нас хоть потоп" или "за новую архитектуру платите новые деньги, так для нас даже лучше, что старая не реюзается" ). Мне кажется ты свою систему тоже напишешь и к тебе прибегут и скажут "отлично у тебя получилось. Давай еще такую же на в десятеро большее количество запросов". Что ты будешь делать - совершенно новую архитектуру? А потом снова ее тестировать тянет ли она?
А еще возвращаясь к первоначальной дискуссии в первом топике - там мы проектировали что-то GFS-о подобное, или поиско-подобное.
http://anatolix.livejournal.com/48336.html?thread=793040#t793040
Практически уверен, что у людей в гугле не было задачи "написать систему которая вот столько понянет, но наиболее эффективно", а была, чтобы "вот это эффективно масштабировалось".
Поэтому я собственно и не понимал(и сейчас не понимаю) твои требования точно привести количество запросов и объем данных, и мне кажется, что эти запросы (как и последующий переход на личности) в том месте были не уместны.
P.S. (Извини не удержался ;)
Поэтому мне кажется, что "ты не решал задачи вида 'сделать дизайн, который будет скалироваться в сотни раз без особых изменений' " именно в терминах которых нужно проектировать поисковики и серьезные распределенные FS и БД
(no subject)
Date: 2008-02-28 01:57 am (UTC)что я пытался сделать, так это найти общий язык и какие-нибудь общие примитивы (например - throughput, latency, data volume), опираясь на которые можно дальше беседу строить. а вместо этого уже который пост вижу только hand waving и мифические "скалироваться в сотни раз без особых изменений". я на таком языке разговаривать не в состоянии, несмотря на горячее желание.
далее, статья "THE GOOGLE CLUSTER ARCHITECTURE", на которую ты сам же вроде и ссылался, постоянно оперирует термином cost-effective. cost, cost, cost. и это очевидно. невероятно же тут то, что все мои аргументы про cost-effective были так же просто hand waved.
Поэтому мне кажется, что "ты не решал задачи вида 'сделать дизайн, который будет скалироваться в сотни раз без особых изменений' " именно в терминах которых нужно проектировать поисковики и серьезные распределенные FS и БД
я такие задачи не решал никогда, потому что задачи так не стоят никогда. потому что в формулировке задачи всегда есть словосочетание "cost-effective". и потому что "скалироваться в сотни раз без изменений" и "cost-effective" are mutually exclusive. потому что любая серьёзная архитектура - это комплекс большого числа trade-offов, и без осознания того, какой же trade-off мы совершаем данным архитектурным решением особо много не наархитектуришь. sheesh.
(no subject)
Date: 2008-02-28 11:03 am (UTC)Кроме того точное соотношение "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, но в сумме она осталась той же самой. Т.е. я их считаю низкоувовневой архитектурой, а не высокоуровневой(в ЖЖ низкоуровневую не обсудишь по хорошему, слишком много подробностей и просто тупо много писать)