Дмитрий Бородин (spb_borodin) wrote,
Дмитрий Бородин
spb_borodin

Categories:

(#2) Как устроены крупные соц.сети изнутри. Часть 2 - разбор комментариев.

Это продолжение статьи http://spb-borodin.livejournal.com/596.html Ответы на многие поступившие вопросы. Рекомендую сначала прочитать первую часть.

Нужен ли мне это мастер-класс?

Есть два момента - сможете ли вы немедленно применить знания и будет ли он вам просто интересен.

Признаки, когда вы не сможете немедленно применить полученные знания, только со временем:



  • Вы не профессиональный программист (менее 3х лет опыта работы).
  • Вы плохо понимаете ООП (учить азам программирования я не буду), не в состоянии сделать, скажем, форум. Не знаете, что означают слова паттерн и memcache.
  • Нет хотя бы нескольких запущенных проектов.
  • У вас нет хотя бы собственного VDS.
  • Вы не стартапщик.
  • Web 2.0 вам не интересен.
  • Вы делаете какой-то совершенно иной проект, а не те, о которых я упоминаю.
  • Вы вообще не можете сделать проект, на котором когда-нибудь возможно появление более 50.000 уников в сутки.
Будет ли вам интересно, если вы делаете какой-то небольшой проект и вы точно знаете, что он не станет очень крупным? 

Ответ - скорее всего да. Я совсем не зацикливаюсь на точном воспроизведении чего-либо. Цель - научись слушателей необходимым паттернам программирования, без которых в хайлоде точно нечего делать. Но эти сведения полезны сами по себе. Их можно применить и в традиционном программировании. Освоив материал вы научитесь самостоятельно и по иному проектировать. Вы освоите альтернативу транзакциям и блокировкам, узнаете, как безопасно программировать код, который выполняется параллельно в много потоков (веб-скрипты) и оперирует одними и теми же данными. Иные подходы заключаются в том, что до этого вы никогда сами не догадаетесь, если только не перенимать у тех, кто уже имеет крупные проекты - там то все придумано (самостоятельно тоже можно, но весьма долго).


Мастер класс посвящен тому, как именно нужно хранить и оперировать данными. Там не будет почти ничего, привязанного к какому-либо языку программирования или конкретной базе. Я призываю быть выше языков, баз, операционных систем, скоростных характеристик железа и т.д. Разумеется важно принимать в расчет стоимость проекта, но на порядок более важно - в принципе сделать его не зависимым от железа.

Для каких проектов и их разработчиков мастер-класс не пригодится?

  • Не веб2.0 проекты, например, поисковые системы или бизнес-логика.
  • Твиттер.
  • Сайт-визитка.
  • Интранет сайты.
  • Чат (если там не будет профалов, друзей и т.д.).

99% программистам мой мастер класс не нужен. Я нигде не утверждал, что это панацея от всех бед :) Но имеется 1% активных молодых и талантливых программистов, которые хотят развиваться. Именно для них проводится обучение.

В первые полгода разработки и роста вашего стартапа вам будет очень сложно. Мастер класс тоже не из легких. Ведь на нем я буду рассказывать о многих не знакомых вещах для программиста, никогда не имевшего опыта общения с архитектурой крупного проекта.


Для каких типов проектов в точности пригодится данная архитектура?

Существуют проекты, которые можно разработать под одну гребенку. Т.е. создать на абсолютно одинаковой платформе. Таким проектами являются - соц. сети (Фейсбук), блоги (ЖЖ), веб-магазины, СМИ, Википедия, 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-150 SQL серверов - это не у нас. Это у контакта их столько. Точно я этого не знаю, просто прикидка. Наш проект - 1 млн ежедневно и 10 млн регистраций. У Контакта - 20 и 100. Простейшая экстраполяция позволяет делать подобные прикидки.

В Лицемере менее 100 серверов и разумеется не все они с SQL.

Рубисты слишком сильно заняты самоутверждением, что не хотят читать внимательно.

Еще одна проблема, связана с
RabbitMQ. Возможно, у наших программистов и сисадминов кривые руки, но заставить этот сервер очередей работать вменяемо не удается. Он выдерживает мультипоточную запись в очередь на скорости 3000-5000 сообщений, а чтение - 500-1000 сообщений/секунду. Это ужасно медленно. Перейти на RabbitMQ не удается, т.к. не понятно, как его настроить. По рекламным проспектам тот должен держать 200.000-800.000 сообщений в секунду.

Наш проект легко меняет сервер очередей. Изначально мы жили на MemcacheQ, а теперь используем Redis. Будьте выше физических ограничений каких-то конкретных сервисов.


* * *

Спасибо за внимание и за комментарии, на остальное дам ответ в следующей части.


-----------------------
http://php.spb.ru - Запись на мастер-класс по #Highload на 2013 год
-----------------------


Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 59 comments
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →