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

:

: 8

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 год
-----------------------