(#2) Как устроены крупные соц.сети изнутри. Часть 2 - разбор комментариев.
Это продолжение статьи http://spb-borodin.livejournal.com/596.html Ответы на многие поступившие вопросы. Рекомендую сначала прочитать первую часть.
Нужен ли мне это мастер-класс?
Есть два момента - сможете ли вы немедленно применить знания и будет ли он вам просто интересен.
Признаки, когда вы не сможете немедленно применить полученные знания, только со временем:
Ответ - скорее всего да. Я совсем не зацикливаюсь на точном воспроизведении чего-либо. Цель - научись слушателей необходимым паттернам программирования, без которых в хайлоде точно нечего делать. Но эти сведения полезны сами по себе. Их можно применить и в традиционном программировании. Освоив материал вы научитесь самостоятельно и по иному проектировать. Вы освоите альтернативу транзакциям и блокировкам, узнаете, как безопасно программировать код, который выполняется параллельно в много потоков (веб-скрипты) и оперирует одними и теми же данными. Иные подходы заключаются в том, что до этого вы никогда сами не догадаетесь, если только не перенимать у тех, кто уже имеет крупные проекты - там то все придумано (самостоятельно тоже можно, но весьма долго).
Мастер класс посвящен тому, как именно нужно хранить и оперировать данными. Там не будет почти ничего, привязанного к какому-либо языку программирования или конкретной базе. Я призываю быть выше языков, баз, операционных систем, скоростных характеристик железа и т.д. Разумеется важно принимать в расчет стоимость проекта, но на порядок более важно - в принципе сделать его не зависимым от железа.
Для каких проектов и их разработчиков мастер-класс не пригодится?
В первые полгода разработки и роста вашего стартапа вам будет очень сложно. Мастер класс тоже не из легких. Ведь на нем я буду рассказывать о многих не знакомых вещах для программиста, никогда не имевшего опыта общения с архитектурой крупного проекта.
Для каких типов проектов в точности пригодится данная архитектура?
Существуют проекты, которые можно разработать под одну гребенку. Т.е. создать на абсолютно одинаковой платформе. Таким проектами являются - соц. сети (Фейсбук), блоги (ЖЖ), веб-магазины, СМИ, Википедия, Formsprings, онлайн или флеш игры и т.д.
Освоив азы проектирования крупных масштабируемых проектов вы заметите, что между ними нет разницы. Конечно, они очень сложны в деталях и мелочах. Но их базовая архитектура может быть воспроизведена совершенно одинаково. Цель мастер-класса - обучить этому слушателей, чтобы вы лично тоже самое смогли увидеть. Правда, одной лекции будет конечно мало, но надо с чего-то начать.
Наша компания создала разные проекты, на практике проверив эти утверждения: СМИ, приложения для соц.сетех (Фейсбук, ВКонтакте, Мой мир - не флеш), самостоятельная соц.сеть, флеш-игры и др.
Разница только в вывеске. В одном случае сущностью USER называется пользователь соц.сети, в другом случае USER - это статья с комментариями в СМИ или ветка обсуждения в гигантском блоге. Нет разницы в архитектуре подобных проектов.
Делать клоны проектов глупо! А если второй Фейсбук невозможен - зачем это все? За 4 года раскрутки все ваши технологии устареют.
Совершенно верно, ни в коем случае не делайте клонов. Придумывайте другие идеи.
Крупные проекты появляются часто и на разработку уходит мало времени. Очевидно, они должны иметь масштабирование, иначе не выдержат нагрузки. И технологии масштабирования вам пригодятся не через 4 года (Фейсбук долго рос до 500 млн), а сразу. С нуля.
Суть технологии вы должны заложить до того, как пойдете в базу создавать свою первую табличку. По ходу жизни ваш проект будет легко меняться и развиваться. И я гарантирую, что при правильном подходе вы не придете к разбитому корыту - ступору, когда все криво, плохо и надо переписать и весь код, и изменить архитектуру базы. Именно это часто случается с многими проектами. Я просто призываю не наступать хотя бы на грабли, связанные с базой. Вам не придется ее менять. При правильно реализованном масштабировании вы далее по ходу развития проекта будете заниматься именно программированием функционала, а не судорожно соображать - "О Боже, если в этой табличке будет больше записей, все накроется".
Итак, не нужно пинять на годы раскрутки Фейсбука, сейчас проекты растут очень быстро.
Обычный проект, написанный традиционным программистом, врядли выдержит больше 25.000 - 50.000 уников в сутки. Чтобы не доводить до крайностей - просто заложите масштабируемость. Уже 10.000-20.000 уников в сутки на вашем проекте будет достаточно, чтобы с рекламы окупить второй-третий сервер и все пойдет развиваться... Если ваш проект настолько ужасен, что не окупит хотя бы собственный хостинг - не надо с этой проблемой идти ко мне. Да, тогда я соглашусь - масштабирование вам не нужно.
Внедрение масштабирования неоправданно дорого и не подойдет для мелких проектов!
Это заблуждение. Да, мы пачками закупаем сервера. Но это не значит, что ваш мелкий сайт (стартап) на 1.000 уников в сутки потребует инвестиций в железо, сервера, админов и т.д.
Честное горизонтальное масштабирование - это паттерны относительно оперирования данных. А не какое железо купить. Вы до сих пор хранили пользователей ТАК. А с масштабированием будете делать ЭДАК. И это все. Никаких дополнительных денег ни на что не нужно. Разработка не будет дольше по времени или сложнее по придумыванию архитектуры вашего проекта.
Затраты будут на обучение и опыт. Быстрее, чем за полгода-год, понять, что Фейсбук и ЖЖ по сути одно и тоже - сложно. Но надо же с чего то начать. Приняв наш паттерн в своем стартапе вам будет сложно. Никто не говорил, что обучение легко. Зато потом будет очень легко и вы будете придумывать архитектуру любого проекта за пять минут.
Не смотрите, что мы пачками покупаем сервера и нагрузка тут же туда перетекает. Для крупных веб-проектов нет проблемы докупить железа. Скажем, если наше посещаемость увеличится в 10 раз, то наш доход возрастет в 100 раз. Мы просто жаждем докупить железа, т.к. это означает, что оно пойдет на более высокую посещаемость! Просьба не писать финансовые опасения и под этим предлогом не делать ваш стартап. Есть варианты получать сервера бесплатно, с дохода от проекта.
О ненужности JOIN, EXPLAIN и другого. О ненужности обдумывания выбора базы, языка и оптимизации железа.
Не надо столько категорично придираться к моим словам.
Конечно, оно нужно. Просто в очень мизерных масштабах, по сравнению с традиционным программированием. Первое, что нужно освоить - это выкинуть данные слова из головы, как главные инструменты. Они - крайне не существенны, но изредка применяются. Обычно, программист уделяет очень много времени ООП, структуре таблиц, индексах, EXPLAIN, делает почти все запросы с JOIN и т.д. При разработке масштабируемого проекта на базу данных тратится 1% рабочего времени. И Explain, конечно, можно применять, это полезно. Но запросы столь просты (по primary key), что на практике его почти никогда не используют. Ну, может раз в месяц. Банально лень проверять то, что и так будет работать.
Традиционный программист имеет много тараканов в голове, которые не позволяют проектировать по иному. С этим и идет борьба. Сколько бы рвотных пакетиков в меня не кидали, я не изменю мнение. Ведь я же не сказки рассказываю, а только о процессе разработки у нас.
Тоже самое про мой тезис, что не нужно думать о выборе базы и языка. И особенная жесть - выбор фреймфорка. Ужасная глупость состоит в том, что вместо обдумывания честного горизонтального масштабирования (единственный важный вопрос), программист занимается чем угодно второстепенным:
Вы должны придумать такую архитектуру проекта, которую можно реализовать на любом языке, любой базе и любом слабом железе. Это - возможно, лично проверил. Кто хочет научится тому же - подходите :)
Только после того, как вы осознали о важности оперирования данными, чтобы проект был способен принять сотню млн регистраций и несколько млн посетителей в день, можно заняться второстепенными вопросами - язык, база и т.д.
Необходимо быть выше физических особенностей базы или железа. У вас сервер без RAID? Да это не важно! Схема масштабируема и подстраиваться под любой тормозной жесткий диск. Данные не влезают в память одного SQL сервера? Нет проблем - часть данных тут же мигрирует на соседний сервер.
Задача сисадминов сидеть заниматься тюнингом системы. Задача программиста сделать так, чтобы проект был в принципе не зависимым ни от кого. Правильное масштабирование - это когда лично сисадмин правя конфиги и запуская скрипты переносит нагрузку по частям проекта, как он сам решил. Без участия программистов! Они близко не подходят к продакшен серверам. В особо важных моментах программисты изучают статистику работы проекта и дают указания сисадмину что-то сделать.
Ruby vs PHP. Страшное прошлое Лицемера.
Любимая тема всех рубистов - посмеяться на пхпистами. Не знаю почему так сложилось, но каждый раз, когда вижу рубистов - они ржут над пхп. Видимо, других тем нет. А над ними никто не смеется, наверно, просто не знают об их существовании. У меня прямо рефлекс выработался: кто-то смеется над пхп? А, рубисты!
И так первое, что сделали рубисты - посмеялись над выбором языка.
Этот антипаттерн, описан мною выше. Я знаю, что в php есть утечки памяти, чуть более прожорлив конкурентов. Это меня не волнует. При правильном масштабировании все будет работать и с говнокодом.
Опять таки - не надо придираться к словам! Я не призываю говнокодить. Наш проект не идеален, в нем появляется говнокод. Это редко приводит к плохим последствиям, т.к. код тут же легко исправляется более квалифицированным программистом. Если же накосячить в базе, т.е. выбрать не правильную модель хранения данных - последствие будет ужасающее. Придется тормозить проект и обновлять несколько десятков серверов с большими базами данных.
Некоторое время назад я плотно программировал на TCL и занимался сайтом о нем. Так же, как с php.spb.ru, 10 лет назад о TCL было довольно мало материалов на русском языке. Я занимался его популяризацией. TCL разработан где-то лет 20 (или 30) назад и намного круче PHP или какого-то там Руби. Люди втирают мне про Руби или Питон, сами не зная о том, что есть еще более редкие и более продвинутые языки. Причем их разработали 20 лет назад! Мелочно и глупо.
Вторая тема воя рубистов - по поводу прошлого Лицемера.
Он когда-то был на Руби и на Флеше. Т.е. мы запустили наш проект, когда в Лицемере было уже 0,5 млн юзеров ежедневно. Мы разработали проект (2-3 программиста за 3 месяца) и без всяких нагрузочных тестирований или проверок - кинули его в бой. Поверьте, это сложнее, чем просто набирать нагрузку с нуля. Наш проект выдержал! 6 августа 2010 года мы один раз переключили старый Лицемер на новый и более к старому не возвращались. Прошло 3,5 месяца и нагрузка в проекте уже 1 млн пользователей каждый день.
На конференции по Highload выступал разработчик старого Лицемера, вещал о какой-то железной дороге... Весь зал с рубистами очень долго ржал над темой - кому в здравом уме потребовалось перевести "успешно работающий проект" на PHP?
Давайте это разберем:
В Лицемере менее 100 серверов и разумеется не все они с SQL.
Рубисты слишком сильно заняты самоутверждением, что не хотят читать внимательно.
Еще одна проблема, связана с RabbitMQ. Возможно, у наших программистов и сисадминов кривые руки, но заставить этот сервер очередей работать вменяемо не удается. Он выдерживает мультипоточную запись в очередь на скорости 3000-5000 сообщений, а чтение - 500-1000 сообщений/секунду. Это ужасно медленно. Перейти на RabbitMQ не удается, т.к. не понятно, как его настроить. По рекламным проспектам тот должен держать 200.000-800.000 сообщений в секунду.
Наш проект легко меняет сервер очередей. Изначально мы жили на MemcacheQ, а теперь используем Redis. Будьте выше физических ограничений каких-то конкретных сервисов.
* * *
Спасибо за внимание и за комментарии, на остальное дам ответ в следующей части.
-----------------------
http://php.spb.ru - Запись на мастер-класс по #Highload на 2013 год
-----------------------
Нужен ли мне это мастер-класс?
Есть два момента - сможете ли вы немедленно применить знания и будет ли он вам просто интересен.
Признаки, когда вы не сможете немедленно применить полученные знания, только со временем:
- Вы не профессиональный программист (менее 3х лет опыта работы).
- Вы плохо понимаете ООП (учить азам программирования я не буду), не в состоянии сделать, скажем, форум. Не знаете, что означают слова паттерн и memcache.
- Нет хотя бы нескольких запущенных проектов.
- У вас нет хотя бы собственного VDS.
- Вы не стартапщик.
- Web 2.0 вам не интересен.
- Вы делаете какой-то совершенно иной проект, а не те, о которых я упоминаю.
- Вы вообще не можете сделать проект, на котором когда-нибудь возможно появление более 50.000 уников в сутки.
Ответ - скорее всего да. Я совсем не зацикливаюсь на точном воспроизведении чего-либо. Цель - научись слушателей необходимым паттернам программирования, без которых в хайлоде точно нечего делать. Но эти сведения полезны сами по себе. Их можно применить и в традиционном программировании. Освоив материал вы научитесь самостоятельно и по иному проектировать. Вы освоите альтернативу транзакциям и блокировкам, узнаете, как безопасно программировать код, который выполняется параллельно в много потоков (веб-скрипты) и оперирует одними и теми же данными. Иные подходы заключаются в том, что до этого вы никогда сами не догадаетесь, если только не перенимать у тех, кто уже имеет крупные проекты - там то все придумано (самостоятельно тоже можно, но весьма долго).
Мастер класс посвящен тому, как именно нужно хранить и оперировать данными. Там не будет почти ничего, привязанного к какому-либо языку программирования или конкретной базе. Я призываю быть выше языков, баз, операционных систем, скоростных характеристик железа и т.д. Разумеется важно принимать в расчет стоимость проекта, но на порядок более важно - в принципе сделать его не зависимым от железа.
Для каких проектов и их разработчиков мастер-класс не пригодится?
- Не веб2.0 проекты, например, поисковые системы или бизнес-логика.
- Твиттер.
- Сайт-визитка.
- Интранет сайты.
- Чат (если там не будет профалов, друзей и т.д.).
В первые полгода разработки и роста вашего стартапа вам будет очень сложно. Мастер класс тоже не из легких. Ведь на нем я буду рассказывать о многих не знакомых вещах для программиста, никогда не имевшего опыта общения с архитектурой крупного проекта.
Для каких типов проектов в точности пригодится данная архитектура?
Существуют проекты, которые можно разработать под одну гребенку. Т.е. создать на абсолютно одинаковой платформе. Таким проектами являются - соц. сети (Фейсбук), блоги (ЖЖ), веб-магазины, СМИ, Википедия, Formsprings, онлайн или флеш игры и т.д.
Освоив азы проектирования крупных масштабируемых проектов вы заметите, что между ними нет разницы. Конечно, они очень сложны в деталях и мелочах. Но их базовая архитектура может быть воспроизведена совершенно одинаково. Цель мастер-класса - обучить этому слушателей, чтобы вы лично тоже самое смогли увидеть. Правда, одной лекции будет конечно мало, но надо с чего-то начать.
Наша компания создала разные проекты, на практике проверив эти утверждения: СМИ, приложения для соц.сетех (Фейсбук, ВКонтакте, Мой мир - не флеш), самостоятельная соц.сеть, флеш-игры и др.
Разница только в вывеске. В одном случае сущностью USER называется пользователь соц.сети, в другом случае USER - это статья с комментариями в СМИ или ветка обсуждения в гигантском блоге. Нет разницы в архитектуре подобных проектов.
Делать клоны проектов глупо! А если второй Фейсбук невозможен - зачем это все? За 4 года раскрутки все ваши технологии устареют.
Совершенно верно, ни в коем случае не делайте клонов. Придумывайте другие идеи.
Крупные проекты появляются часто и на разработку уходит мало времени. Очевидно, они должны иметь масштабирование, иначе не выдержат нагрузки. И технологии масштабирования вам пригодятся не через 4 года (Фейсбук долго рос до 500 млн), а сразу. С нуля.
Суть технологии вы должны заложить до того, как пойдете в базу создавать свою первую табличку. По ходу жизни ваш проект будет легко меняться и развиваться. И я гарантирую, что при правильном подходе вы не придете к разбитому корыту - ступору, когда все криво, плохо и надо переписать и весь код, и изменить архитектуру базы. Именно это часто случается с многими проектами. Я просто призываю не наступать хотя бы на грабли, связанные с базой. Вам не придется ее менять. При правильно реализованном масштабировании вы далее по ходу развития проекта будете заниматься именно программированием функционала, а не судорожно соображать - "О Боже, если в этой табличке будет больше записей, все накроется".
Итак, не нужно пинять на годы раскрутки Фейсбука, сейчас проекты растут очень быстро.
Обычный проект, написанный традиционным программистом, врядли выдержит больше 25.000 - 50.000 уников в сутки. Чтобы не доводить до крайностей - просто заложите масштабируемость. Уже 10.000-20.000 уников в сутки на вашем проекте будет достаточно, чтобы с рекламы окупить второй-третий сервер и все пойдет развиваться... Если ваш проект настолько ужасен, что не окупит хотя бы собственный хостинг - не надо с этой проблемой идти ко мне. Да, тогда я соглашусь - масштабирование вам не нужно.
Внедрение масштабирования неоправданно дорого и не подойдет для мелких проектов!
Это заблуждение. Да, мы пачками закупаем сервера. Но это не значит, что ваш мелкий сайт (стартап) на 1.000 уников в сутки потребует инвестиций в железо, сервера, админов и т.д.
Честное горизонтальное масштабирование - это паттерны относительно оперирования данных. А не какое железо купить. Вы до сих пор хранили пользователей ТАК. А с масштабированием будете делать ЭДАК. И это все. Никаких дополнительных денег ни на что не нужно. Разработка не будет дольше по времени или сложнее по придумыванию архитектуры вашего проекта.
Затраты будут на обучение и опыт. Быстрее, чем за полгода-год, понять, что Фейсбук и ЖЖ по сути одно и тоже - сложно. Но надо же с чего то начать. Приняв наш паттерн в своем стартапе вам будет сложно. Никто не говорил, что обучение легко. Зато потом будет очень легко и вы будете придумывать архитектуру любого проекта за пять минут.
Не смотрите, что мы пачками покупаем сервера и нагрузка тут же туда перетекает. Для крупных веб-проектов нет проблемы докупить железа. Скажем, если наше посещаемость увеличится в 10 раз, то наш доход возрастет в 100 раз. Мы просто жаждем докупить железа, т.к. это означает, что оно пойдет на более высокую посещаемость! Просьба не писать финансовые опасения и под этим предлогом не делать ваш стартап. Есть варианты получать сервера бесплатно, с дохода от проекта.
О ненужности JOIN, EXPLAIN и другого. О ненужности обдумывания выбора базы, языка и оптимизации железа.
Не надо столько категорично придираться к моим словам.
Конечно, оно нужно. Просто в очень мизерных масштабах, по сравнению с традиционным программированием. Первое, что нужно освоить - это выкинуть данные слова из головы, как главные инструменты. Они - крайне не существенны, но изредка применяются. Обычно, программист уделяет очень много времени ООП, структуре таблиц, индексах, EXPLAIN, делает почти все запросы с JOIN и т.д. При разработке масштабируемого проекта на базу данных тратится 1% рабочего времени. И Explain, конечно, можно применять, это полезно. Но запросы столь просты (по primary key), что на практике его почти никогда не используют. Ну, может раз в месяц. Банально лень проверять то, что и так будет работать.
Традиционный программист имеет много тараканов в голове, которые не позволяют проектировать по иному. С этим и идет борьба. Сколько бы рвотных пакетиков в меня не кидали, я не изменю мнение. Ведь я же не сказки рассказываю, а только о процессе разработки у нас.
Тоже самое про мой тезис, что не нужно думать о выборе базы и языка. И особенная жесть - выбор фреймфорка. Ужасная глупость состоит в том, что вместо обдумывания честного горизонтального масштабирования (единственный важный вопрос), программист занимается чем угодно второстепенным:
- холивары о более подходящем языке программирования,
- обсуждение особенностей баз данных,
- проработка клиентского функционала,
- выбор фреймворка.
Вы должны придумать такую архитектуру проекта, которую можно реализовать на любом языке, любой базе и любом слабом железе. Это - возможно, лично проверил. Кто хочет научится тому же - подходите :)
Только после того, как вы осознали о важности оперирования данными, чтобы проект был способен принять сотню млн регистраций и несколько млн посетителей в день, можно заняться второстепенными вопросами - язык, база и т.д.
Необходимо быть выше физических особенностей базы или железа. У вас сервер без RAID? Да это не важно! Схема масштабируема и подстраиваться под любой тормозной жесткий диск. Данные не влезают в память одного SQL сервера? Нет проблем - часть данных тут же мигрирует на соседний сервер.
Задача сисадминов сидеть заниматься тюнингом системы. Задача программиста сделать так, чтобы проект был в принципе не зависимым ни от кого. Правильное масштабирование - это когда лично сисадмин правя конфиги и запуская скрипты переносит нагрузку по частям проекта, как он сам решил. Без участия программистов! Они близко не подходят к продакшен серверам. В особо важных моментах программисты изучают статистику работы проекта и дают указания сисадмину что-то сделать.
Ruby vs PHP. Страшное прошлое Лицемера.
Любимая тема всех рубистов - посмеяться на пхпистами. Не знаю почему так сложилось, но каждый раз, когда вижу рубистов - они ржут над пхп. Видимо, других тем нет. А над ними никто не смеется, наверно, просто не знают об их существовании. У меня прямо рефлекс выработался: кто-то смеется над пхп? А, рубисты!
И так первое, что сделали рубисты - посмеялись над выбором языка.
Этот антипаттерн, описан мною выше. Я знаю, что в php есть утечки памяти, чуть более прожорлив конкурентов. Это меня не волнует. При правильном масштабировании все будет работать и с говнокодом.
Опять таки - не надо придираться к словам! Я не призываю говнокодить. Наш проект не идеален, в нем появляется говнокод. Это редко приводит к плохим последствиям, т.к. код тут же легко исправляется более квалифицированным программистом. Если же накосячить в базе, т.е. выбрать не правильную модель хранения данных - последствие будет ужасающее. Придется тормозить проект и обновлять несколько десятков серверов с большими базами данных.
Некоторое время назад я плотно программировал на TCL и занимался сайтом о нем. Так же, как с php.spb.ru, 10 лет назад о TCL было довольно мало материалов на русском языке. Я занимался его популяризацией. TCL разработан где-то лет 20 (или 30) назад и намного круче PHP или какого-то там Руби. Люди втирают мне про Руби или Питон, сами не зная о том, что есть еще более редкие и более продвинутые языки. Причем их разработали 20 лет назад! Мелочно и глупо.
Вторая тема воя рубистов - по поводу прошлого Лицемера.
Он когда-то был на Руби и на Флеше. Т.е. мы запустили наш проект, когда в Лицемере было уже 0,5 млн юзеров ежедневно. Мы разработали проект (2-3 программиста за 3 месяца) и без всяких нагрузочных тестирований или проверок - кинули его в бой. Поверьте, это сложнее, чем просто набирать нагрузку с нуля. Наш проект выдержал! 6 августа 2010 года мы один раз переключили старый Лицемер на новый и более к старому не возвращались. Прошло 3,5 месяца и нагрузка в проекте уже 1 млн пользователей каждый день.
На конференции по Highload выступал разработчик старого Лицемера, вещал о какой-то железной дороге... Весь зал с рубистами очень долго ржал над темой - кому в здравом уме потребовалось перевести "успешно работающий проект" на PHP?
Давайте это разберем:
- Старый проект был не масштабируемый. Разработчик постоянно вырубал проект, чтобы распилить таблицы на шарды. Руками. Т.е. число шардов было прописано в коде. Я учу, как не наступать на эти грабли, о настоящем честном горизонтальном масштабировании и миграции данных.
- Из-за не масштабируемости проекта на нем было невозможно решать целый класс задач, нужных в веб 2.0. Я расскажу об этих задачах особо, в другой статье. Это основные причины, почему пришлось выкинуть руби. Если бы там был пхп - он бы тоже пошел в корзину. Дело не в языке! Кратко, о невозможных задачах в старом Лицемере:
- Просто вывести список друзей (фио, аватар, город и т.д.), естественно, серверными методами, а не через апи контакта.
- Рейтинги по друзьям и прочие операции с ними.
- Френдлента
- Флеш. Думаю, не нуждается в пояснениях убогость GUI, юзабилити, скорость внедрения во флеше. Мы первое крупное приложение контакта на iframe. Нам было плевать на тотальное засилье флеша и некоторые баги в АПИ. Теперь все больше и больше приложений будет не на флеше.
- Старый проект был просто ужасающе мизерным по функционалу, поэтому затруднительно сравнивать их в этом плане.
- Кроме PostgreSQL и RabbitMQ в нем не было ничего. Реально голый сервер.
- Кода на руби было не много. Изначально мы думали - нанять ли программеров на руби. Не хочу переходить на личности и быть некорректным... но некоторые наши программисты знают Руби и сделали заключение о сплошном говнокоде. Типа mysql_connect() в каждом файле (относительный пример для PHP). Извините, это не мои слова.
- Лицемер был тотально дырявым. Как и во всех играх, просто отсутствовали проверки на что либо, защита от накрутки и т.д. По инету тоннами висят советы, как открыть Firebug и за 5 минут накрутить миллион монет.
- Сейчас новый Лицемер и ВКурсе - это полноценная соц.сеть. Да, в оболочке приложения для Контакта/Фейсбука/Моего мира. Но там есть полный перечень веб 2.0 функционала:
- Невозможные задачи решаются сами, по-умолчанию. Смысл правильной архитектуры в том, что более нет технически невыполнимых или сложных задач. Все легко и просто!
- Любые рейтинги по друзьям или топы по каким-то параметрам.
- Полноценная френдлента (вкладки: друзья, слежение за темами, слежение за комментами друзей и т.д.)
- Полноценный анкетный поиск.
- Геолокация.
- Шардинг и неизменность архитектуры базы при росте.
В Лицемере менее 100 серверов и разумеется не все они с SQL.
Рубисты слишком сильно заняты самоутверждением, что не хотят читать внимательно.
Еще одна проблема, связана с RabbitMQ. Возможно, у наших программистов и сисадминов кривые руки, но заставить этот сервер очередей работать вменяемо не удается. Он выдерживает мультипоточную запись в очередь на скорости 3000-5000 сообщений, а чтение - 500-1000 сообщений/секунду. Это ужасно медленно. Перейти на RabbitMQ не удается, т.к. не понятно, как его настроить. По рекламным проспектам тот должен держать 200.000-800.000 сообщений в секунду.
Наш проект легко меняет сервер очередей. Изначально мы жили на MemcacheQ, а теперь используем Redis. Будьте выше физических ограничений каких-то конкретных сервисов.
* * *
Спасибо за внимание и за комментарии, на остальное дам ответ в следующей части.
-----------------------
http://php.spb.ru - Запись на мастер-класс по #Highload на 2013 год
-----------------------