Скажем так про совсем ничем я наверное загнул, но по сравнению с переходом 100 -> 10K, переход 10K-1M действительно не оказывает серьезных влияний на архитектуру.
Вместо того, чтобы делать умное лицо лучше бы привел антипример в виде системы с 1M qps, и я тебе покажу какую-нибудь систему на 10K qps с похожей архитектурой.
P.S. Интересный разговор обычно предполагает, что оба оппонента: 1) Пользуются доказательствами своих точек зрения, а не просто утверждают что "это позиция бред, а аргументы приводить не буду" 2) Не используют вырванные из контекста фразы, не превращают обобщающие формулировки(со словами "обычно") в точные и не допускающие исключений, и не используют излишние обобщения вида "anatolix -> архитекторы яндекса" 3) Пытаются что-то вместе понять или хотя бы доказать друг-другу, а не найти повод написать в своем блоге "смотрите(ссылка) какая глупость. какой он дурак что написал. и какой я умный по сравнению с ним". Если подобная позиция останется то разговора похоже, действительно, не получиться.
извини. я совершенно не считаю, что ты дурак и совершенно не хотел этого сказать. всё, что я хотел выразить - это разочарование отсутствием конкретики.
ибо я как раз сейчас занимаюсь проектированием oltp системы на 6000 "тяжёлых" запросов в секунду и всё время наблюдаю, как изменения в требованиях к трём параметрам (throughput, latency, data volume) коренным образом меняют дизайн.
Мы с тобой живем видимо в разных вселенных, ипоэтому друг друга не понимаем. Давай я тебе попробую объяснить как устроена моя вселенная, а ты попробуешь понять, почему я не хочу тебе сказать точную цифру и более того считаю данный вопрос бессмысленным.
Ну вот например вопросы, откуда у тебя взялась цифра в 6000 запросов? Если ты поймешь, что почти бесплатно можно сделать 60K тыс запросов, но тебе нужнро 6K, значит ли это, что ты не будешь ее масштабировать до этого предела? А не изменится ли у тебя эта цифра в 6000 запросов? (в моем мире нагрузка все еще каждый год удваивается - если вчера просили 6000, то это значит, что если не заложишься на вчетверо больше - через год будешь переделывать). А еще в моем мире постоянно бывают как бонусы так и анусы зависящие от внешних причин: типа "Intel сделал машину в 1.5 раза быстрей - все новые машины такие". Или "извините чуваки у нас проблемы с местом куда ставить сервера - новых машин не будет до марта, нужно на старых тянуть нагрузку на 20% больше нормы".
На мой взгляд не имеет смысла фиксировать конкретные параметры вида throughput, latency, data volume - вообще. Например, у меня у поиска есть 1 неизменный параметр - 95% ответов должно быть быстрей секунды - можно считать, что поведение пользователя не изменится, они не любят тормоза. Всем остальным можно управлять. Объем данных можно регулировать подстегивая или предерживая робота - который сколько скажешь столько и нагребет. Машины можно заказывать. Сетевым траффиком рулить придерживая полет фантазии людей из search quality по поводу того какие данные им нужны в метапоиске, или даже компрессируя траффик. Загрузкой CPU можно рулить изменяя сложность формулы ранжирования, etc.
Вообщем мой point такой: я могу менять большую часть факторов по ходу, знаю что буду их менять, и значительная часть из них может измениться сама вне зависимости от моего желания. В такой постановке не вижу смысла фиксировать характеристики системы.
Нужно указать порядки(что я помоему сделал) и общее направление какими параметрами ради каких можно жертвовать.
ага, уже "почти", а не совсем. теперь, если это "почти" транслируется в сто килобаксов бабла - наплюём на сто килобаксов? хочу в россию. и это только один порядок величины, а я говорил про два.
если ты можешь всеми регуляторами двигать - что я могу сказать, кроме "хорошо тебе" или там "опять хочу в россию". думаю, что такое редко бывает. хотя с другой стороны, мне мало чем можно двигать, потому что параметров меньше, что в свою очередь дизайн упрощает.
У тебя, кстати, какие вообще задачи, что ты можешь так точно предсказать поток запросов? Как юзеры себя поведут обычно 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, но в сумме она осталась той же самой. Т.е. я их считаю низкоувовневой архитектурой, а не высокоуровневой(в ЖЖ низкоуровневую не обсудишь по хорошему, слишком много подробностей и просто тупо много писать)
imho скачок как раз между 100 и 10K (между фиговинкой и аренды гробика) существенно меньше, чем между 10K и 1M (нужно *строить* datacenter), а это уже недвижимость если ссаноконтейнерами не разбрасываться.
Извини конечно, но речь идет о запросах в секунду.
Так для информации у гугля сейчас не на порядок больше чем 10K поисковых запросов в секунду, а 50-100 запросов в секунду это некоторая граница "хорошего сайта" (достаточно для того, чтобы выдержать slashdot эффект).
1M запросов в секунду я вообще сомневаюсь, что сейчас у кого-нибудь есть. Но возможно у adsence столько показов есть, вместе со всем интернетом, но и то не уверен.
а откуда такая информация? Я маленько знаю как устроен CERN-овский кластер, там конечно 200.000 серверов которые при линейной масштабируемости это потянут, но мне казалось всегда, что они берут и считают свой кусочек задачи каждый а меняются ифнфой достаточно редко, а не на каждый чих.
Ты славно срезал, это верно. Однако чувак имел ввиду совершенно правильную мысль: за некоторым пределом система уже масштабируется достаточно близко к линии, иначе она и на 10к оказалась случайно и временно на коленке. Замени 10к величной х, не понимая впрямую.
мнэ... это ж не бесплатно всё. достаточно легко спроектировать линейную масштабируемость, если money is not an object. да плюнуть и растереть. вот только оказывается, что если такой money-unaware design соскалировать линейно же обратно с 1М в 10К, и сказать "а теперь - экономить!", то неожиданно обнаружится, что цену-то можно сократить раза в два, и часть компонентов не нужна оказывается.
и весь практически мой пойнт был в том, что 10к нельзя заменить величиной х. для каждого нового порядка величины (ну хорошо, двух порядков) свои законы.
и разработки лишних (или более сложных) компонентов. и надёжность падает при увеличении количества и сложности компонентов, за что тоже нужно платить, в конечном счёте деньгами.
Если у тебя 10K запросов в секунду и каждый приносит тебе хотя бы по 1 центу, то за секунду набегает стольник, а час работы системы окупит зарплату разработчика за год. И на надёжности при таком раскладе ты не будешь экономить, ты будешь в надёжность вкладывать.
Ты много знаешь дизайнов, которые скалировались на порядки в обратную сторону? Ок, которые делали это экономически/технически удачно, без порождения монстроидов.
ещё раз: если мы проделаем мысленный эксперимент, описанный мной, и обнаружим, что scaled down system имеет кучу ненужного и её на самом деле можно было сделать в два раза дешевле - это и означает, что системы не масштабируются "просто так", for free. это и означает, что эффективный (в смысле, как минимум, cost-effective) дизайн системы на 10,000 отличается от дизайна на 1,000,000.
![[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:20 am (UTC)(no subject)
Date: 2008-02-21 07:33 pm (UTC)(no subject)
Date: 2008-02-21 02:13 pm (UTC)Вместо того, чтобы делать умное лицо лучше бы привел антипример в виде системы с 1M qps, и я тебе покажу какую-нибудь систему на 10K qps с похожей архитектурой.
(no subject)
Date: 2008-02-21 02:37 pm (UTC)1) Пользуются доказательствами своих точек зрения, а не просто утверждают что "это позиция бред, а аргументы приводить не буду"
2) Не используют вырванные из контекста фразы, не превращают обобщающие формулировки(со словами "обычно") в точные и не допускающие исключений, и не используют излишние обобщения вида "anatolix -> архитекторы яндекса"
3) Пытаются что-то вместе понять или хотя бы доказать друг-другу, а не найти повод написать в своем блоге "смотрите(ссылка) какая глупость. какой он дурак что написал. и какой я умный по сравнению с ним".
Если подобная позиция останется то разговора похоже, действительно, не получиться.
(no subject)
Date: 2008-02-21 07:19 pm (UTC)ибо я как раз сейчас занимаюсь проектированием oltp системы на 6000 "тяжёлых" запросов в секунду и всё время наблюдаю, как изменения в требованиях к трём параметрам (throughput, latency, data volume) коренным образом меняют дизайн.
(no subject)
Date: 2008-02-21 08:11 pm (UTC)Ну вот например вопросы, откуда у тебя взялась цифра в 6000 запросов? Если ты поймешь, что почти бесплатно можно сделать 60K тыс запросов, но тебе нужнро 6K, значит ли это, что ты не будешь ее масштабировать до этого предела? А не изменится ли у тебя эта цифра в 6000 запросов? (в моем мире нагрузка все еще каждый год удваивается - если вчера просили 6000, то это значит, что если не заложишься на вчетверо больше - через год будешь переделывать).
А еще в моем мире постоянно бывают как бонусы так и анусы зависящие от внешних причин: типа "Intel сделал машину в 1.5 раза быстрей - все новые машины такие". Или "извините чуваки у нас проблемы с местом куда ставить сервера - новых машин не будет до марта, нужно на старых тянуть нагрузку на 20% больше нормы".
На мой взгляд не имеет смысла фиксировать конкретные параметры вида throughput, latency, data volume - вообще. Например, у меня у поиска есть 1 неизменный параметр - 95% ответов должно быть быстрей секунды - можно считать, что поведение пользователя не изменится, они не любят тормоза. Всем остальным можно управлять. Объем данных можно регулировать подстегивая или предерживая робота - который сколько скажешь столько и нагребет. Машины можно заказывать. Сетевым траффиком рулить придерживая полет фантазии людей из search quality по поводу того какие данные им нужны в метапоиске, или даже компрессируя траффик. Загрузкой CPU можно рулить изменяя сложность формулы ранжирования, etc.
Вообщем мой point такой: я могу менять большую часть факторов по ходу, знаю что буду их менять, и значительная часть из них может измениться сама вне зависимости от моего желания. В такой постановке не вижу смысла фиксировать характеристики системы.
Нужно указать порядки(что я помоему сделал) и общее направление какими параметрами ради каких можно жертвовать.
Для задачи числомолотилки я в принипе именно это и указал
http://anatolix.livejournal.com/48336.html?thread=796112#t796112
(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, но в сумме она осталась той же самой. Т.е. я их считаю низкоувовневой архитектурой, а не высокоуровневой(в ЖЖ низкоуровневую не обсудишь по хорошему, слишком много подробностей и просто тупо много писать)
(no subject)
Date: 2008-02-21 07:32 pm (UTC)(no subject)
Date: 2008-02-21 08:23 pm (UTC)(no subject)
Date: 2008-02-21 08:38 pm (UTC)Так для информации у гугля сейчас не на порядок больше чем 10K поисковых запросов в секунду, а 50-100 запросов в секунду это некоторая граница "хорошего сайта" (достаточно для того, чтобы выдержать slashdot эффект).
1M запросов в секунду я вообще сомневаюсь, что сейчас у кого-нибудь есть. Но возможно у adsence столько показов есть, вместе со всем интернетом, но и то не уверен.
(no subject)
Date: 2008-02-21 10:31 pm (UTC)(no subject)
Date: 2008-02-22 09:15 am (UTC)Если бы парни всей земли в месте
Date: 2008-02-22 11:04 am (UTC)Re: Если бы парни всей земли в месте
Date: 2008-02-22 03:39 pm (UTC)(no subject)
Date: 2008-02-21 04:33 pm (UTC)Замени 10к величной х, не понимая впрямую.
(no subject)
Date: 2008-02-21 07:32 pm (UTC)и весь практически мой пойнт был в том, что 10к нельзя заменить величиной х. для каждого нового порядка величины (ну хорошо, двух порядков) свои законы.
(no subject)
Date: 2008-02-21 08:56 pm (UTC)(no subject)
Date: 2008-02-21 10:06 pm (UTC)(no subject)
Date: 2008-02-21 10:24 pm (UTC)(no subject)
Date: 2008-02-22 02:18 pm (UTC)(no subject)
Date: 2008-02-22 02:21 pm (UTC)(no subject)
Date: 2008-02-22 04:42 pm (UTC)(no subject)
Date: 2008-02-22 05:34 pm (UTC)(no subject)
Date: 2008-02-22 10:53 pm (UTC)y_s> И на надёжности при таком раскладе ты не будешь экономить, ты будешь в надёжность вкладывать.
Яша, мы тебя любим!
(no subject)
Date: 2008-02-21 10:24 pm (UTC)Ок, которые делали это экономически/технически удачно, без порождения монстроидов.
(no subject)
Date: 2008-02-22 10:48 pm (UTC)