?

Log in

Previous Entry | Next Entry

Это продолжение статьи 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 год
-----------------------


Comments

( 59 comments — Leave a comment )
shushlyakov
Nov. 18th, 2010 05:25 pm (UTC)
Да, именно то что мне нужно. но не с питера я:(
spb_borodin
Nov. 18th, 2010 05:49 pm (UTC)
Через 3 месяца будет в Москве мастер-класс.
(no subject) - shushlyakov - Nov. 19th, 2010 06:58 am (UTC) - Expand
(no subject) - nergalic - Dec. 24th, 2010 06:27 pm (UTC) - Expand
mitric
Nov. 18th, 2010 09:08 pm (UTC)
С удовольствим бы пришел, даже исходя из академического интереса.
spb_borodin
Dec. 9th, 2010 12:17 pm (UTC)
так ты придешь? :)
(no subject) - mitric - Dec. 9th, 2010 10:22 pm (UTC) - Expand
l_o_n_g
Nov. 19th, 2010 09:03 pm (UTC)
>Я знаю, что в php есть утечки памяти
Дима, будь добр, тки пальцем в то место, где течет? а то у нас как-то не текло (если только за собой не убирать созданные объекты), может мы что-то делали не так?
spb_borodin
Nov. 19th, 2010 11:30 pm (UTC)
Текучесть есть из-за некоторых кривонаписанных PECL модулей. Про утечки в чистом php не знаю, не видел... Вернее, чистого php не видел .-)

Часто нет утечек даже, если запустить цикл на 10 млн итераций и внутри создать/уничтожить пяток объектов, которые используют pecl модули. В 95% случаях это работает. В ~5% - нет. Разумеется, все объекты уничтожаются внутри итерации :)

В общем, утечки есть, но проблем не создают. Они связаны с длительными консольными скриптами, которые тут же переписываются, если вылетают. На backend или кронах проблем утечек нет.

Есть посерьезнее проблема, когда PHP в корку падает.

Деталей не помню, но мы на днях обсуждали проблему, что если в деструкторе объекта создать объект другого класса (этого требует логика), то корка неизбежна. Вывод прост: не делать так и изменить логику. Кто виноват - PHP или те же кривые PECL модули, не разбирались.

Когда на крупном проекте один сервер вылетает - этого не заметно. А вот если на десятках back-end'ах начинаются падения в корку (равномерно, везде, потихоньку), это сказывается на производительности и появляется куча неотданных клиенту страниц.
(no subject) - pliskovs - Nov. 21st, 2010 03:25 am (UTC) - Expand
(no subject) - spb_borodin - Nov. 21st, 2010 11:52 am (UTC) - Expand
(no subject) - l_o_n_g - Nov. 22nd, 2010 12:03 am (UTC) - Expand
(no subject) - spb_borodin - Nov. 22nd, 2010 08:51 am (UTC) - Expand
(no subject) - l_o_n_g - Nov. 22nd, 2010 10:07 am (UTC) - Expand
(no subject) - spb_borodin - Nov. 22nd, 2010 10:18 am (UTC) - Expand
(no subject) - l_o_n_g - Nov. 22nd, 2010 10:46 am (UTC) - Expand
(no subject) - spb_borodin - Nov. 22nd, 2010 11:05 am (UTC) - Expand
(no subject) - l_o_n_g - Nov. 22nd, 2010 01:04 pm (UTC) - Expand
(no subject) - spb_borodin - Nov. 22nd, 2010 01:13 pm (UTC) - Expand
memotravelru
Nov. 21st, 2010 03:28 pm (UTC)
Будет ли видео версия?
Здравствуйте, Дмитрий.

Скажите планируется запись вашего семинара и последующая его продажа в виде dvd или каком-либо другом формате?

Нет возможности приехать, а тема очень интересна.
spb_borodin
Nov. 21st, 2010 05:46 pm (UTC)
Re: Будет ли видео версия?
Я провожу только первый мастер-класс, поэтому видео не будет. Через полгодика можно подумать о видео. Может оно никому не понравится и никто больше придет? :)
Re: Будет ли видео версия? - alexius2 - Nov. 22nd, 2010 10:36 am (UTC) - Expand
(Anonymous)
Nov. 22nd, 2010 07:10 pm (UTC)
Интересно
Сразу отпишусь, что мне понравилась статья и, будь Вы в Екатеринбурге, я бы обязательно посетил семинар и взял бы с собой пару-тройку своих сотрудников.
Однако вопрос: а Вам зачем?
alexclear
Nov. 25th, 2010 07:46 pm (UTC)
Забыли вчера обсудить, как устроена лента новостей.
А устроена она, я думаю, так: сначала запросом из базы выбираются айдишники тех, за кем следит данный юзер (его друзья и группы), а потом из кэша фетчем забираются события для этих айдишников.
Когда что-то происходит, то это событие просто забрасывается в кэш для того айди, для которого оно произошло (если там уже было событие, новое добавляется в конец списка). Поскольку новости устаревают по определению, их в базе держать вообще смысла нет.
Вот, как-то так.
alexclear
Nov. 25th, 2010 07:47 pm (UTC)
Ну да, то, что заберется из кэша нужно будет в PHP-скрипте еще отсортировать по времени, само собой.
(no subject) - spb_borodin - Nov. 25th, 2010 09:51 pm (UTC) - Expand
Ivan Samsonov
Dec. 6th, 2010 08:43 pm (UTC)
Замечательно переписали. У меня то 502 то 504. Мож вернете как было? Оно хотя бы работало.
(Anonymous)
Dec. 7th, 2010 06:26 pm (UTC)
Den
Вопрос (задача) возможно не корректный, но все же Сколько посетителей (в день) выдержит сервер 4ГБ оперативка, Нгинкс+Апач+PHP+MySQL+memcahed+хороший широкий интернет канал ? при том что по максимуму будет все оптимизировано. Портал - типа соц сети. Я так понял слабое место тут все равно остается БД и по ней стоит равняться. До уровня 100 тыс уникумов/день (500 тыс открытых страниц) можно расчитывать? Просьба ответить исходя из минимум-максимум (при хорошей оптимизации всего и вся).
spb_borodin
Dec. 7th, 2010 07:54 pm (UTC)
Re: Den
Для начала нужно выкинуть апач за полной ненадобностью. Хороший инет канал не понадобится, сервера скорее покажут слабость, чем канал.

Разумеется гадать о нагрузка неизвестного проекта бессмысленно. На глазок - один средний сервер в сети держит 10000-20000 уников в сутки.

На 100.000 хостов будет 500.000 запросов? Нет, что-то с цифрами не то. При таких расчетах узким местом будет ВСЕ, а не только БД :)
Re: Den - (Anonymous) - Dec. 7th, 2010 09:03 pm (UTC) - Expand
Re: Уники - (Anonymous) - Dec. 9th, 2010 04:10 pm (UTC) - Expand
Re: Уники - spb_borodin - Dec. 9th, 2010 04:21 pm (UTC) - Expand
Re: Уники - (Anonymous) - Dec. 9th, 2010 11:11 pm (UTC) - Expand
Re: Уники - spb_borodin - Dec. 10th, 2010 09:48 am (UTC) - Expand
Re: Den - loginincorrect - Dec. 29th, 2010 07:25 am (UTC) - Expand
Re: Den - spb_borodin - Dec. 29th, 2010 11:07 am (UTC) - Expand
Re: Den - loginincorrect - Dec. 29th, 2010 11:31 am (UTC) - Expand
Re: Den - spb_borodin - Dec. 29th, 2010 11:52 am (UTC) - Expand
k_sashka
Dec. 12th, 2010 03:43 pm (UTC)
Судя по описанию очень интересный и актуальный мастер-класс. Жалко что поздно узнала и не успею :(
(Anonymous)
Dec. 13th, 2010 06:42 am (UTC)
Добрый день!
Дмитрий, спасибо за статьи. Это первый материал, с который познакомил меня с хайлоад. Объясните пожалуйста, хотя бы в нескольких словах, что есть масштабирование. Включает ли этот термин правильную нормализацию БД или это что-то кардинально другое. Я задумал реализовать проект на одном из php фреймворков. Будет ли он популярен или нет - не знаю, но хотелось бы с самого начала правильно "заложить первый камень".
Спасибо.
spb_borodin
Dec. 14th, 2010 09:18 pm (UTC)
Сделать так, чтобы любая таблица могла быть раздроблена на N частей без изменения кода самого проекта (допустимо только скрипт разбиения написать, когда понадобится).

Выбор фреймворка и создание масштабируемой модели - вопросы из разных плоскостей, почти не связанных между собой.
Роман - (Anonymous) - Feb. 24th, 2011 09:49 pm (UTC) - Expand
Re: Роман - spb_borodin - Feb. 25th, 2011 12:03 pm (UTC) - Expand
skazo4neg [ya.ru]
Dec. 25th, 2010 12:02 am (UTC)
Дмитрий, Вы молодец что решились написать 1ю часть такой подробной (хоть и для личного "Пеара"), уверен это подтолкнёт многих к размышлениям.
Только пожалуйста - старайтесь не быть таким высокомерным. Поверьте - свою аудиторию вы соберёте и так. Когда Вы пишите, что JOIN не нужен, или что язык не имеет значения - люди воспринимают всё буквально и стараются ухватить Вас "за язык" именно как результат высокомерия.

В защиту Дмитрия хочу пояснить пункт про "не имеет значения". Как это не странно - выбор базы данных, языка, фреймворка, чего-то ещё - действительно не так важны (естественно, при условии что вы хорошо знаете, то на чём строите).
Что лучше: reddis, cassandra, mongo, или сделать на RDBMS своё key-value хранилище - правильный ответ скорей всего есть, но его никто не знает. Я серьёзно - посмотрите хотя бы на google - там работают прекрасные инженеры. Гугл может нанять лучших. но всё-равно регулярно в новостях мы наблюдаем сообщения о каких-то неполадках. Тоже и твиттер (поищите их истории о смене хранилища), и вконтакте, и многие другие. Это говорит только об одном: все могут допустить ошибку. Что же делать? Стараться строить архитектуру так, чтобы в случае чего можно было заменить одну часть на другую. Касательно выбора хранилища: семантика методов работы у всех KeyValue хранилищ очень похожа. Соберите их в общий интерфейс и обращайтесь к его методам. Это позволит быстрее заменить одно хранилище на другое.

ну и 2я составляющая: да действительно - java быстрее php в "дроблении чисел". а C быстрее java. Но это только "в теории". Производительность реальных программ написанных обычным "средним" программистом - нивелирует эту разницу и зачастую сводит на нет (плохо написана программа + программа большую часть времени ждёт ввода/вывода, а не вычисляет факториал).



Кстати - тем, кто только начинает интересоваться вопросами высоких нагрузок - рекомендую пробежаться по High Performance MySQL Optimization, Backups, Replication, Load Balancing & More By
Jeremy D. Zawodny, Derek J. Balling - тем есть ряд глав посвященных высокими нагрузкам, и в частности подробно рассматриваются методы Read/Write Split и шардинг. Там очень подробно описаны многие вопросы. После этого перенести эти принципы на другое в том числе и KeyValue хранилище проблемы не вызывает.
spb_borodin
Dec. 25th, 2010 12:28 am (UTC)
Спасибо за отзыв, но меня не надо защищать. Разве что от толп воинствующих троллей, которые не имеют ничего, кроме мнения. Все, чему я учу, в точности повторяется во всех больших проектах, таких как фейсбук. Против этого аргумента сложно что-то возразить =)
(Anonymous)
Dec. 25th, 2010 12:23 am (UTC)
Вам не нужен МАСТЕР-КЛАСС если у вас нет 5000р )
spb_borodin
Dec. 25th, 2010 12:28 am (UTC)
Если вы закажете консалтинг для своей компании/проекта - это будет стоить дороже в 1000 раз.. так что цена весьма низкая =)
peerj
Dec. 26th, 2010 03:57 am (UTC)
Было бы интересно сходить на МК, но уже поздно
будет ещё?
_bublik_
Dec. 27th, 2010 02:45 pm (UTC)
Т.е. RabbitMQ не используете только потому, что неумеете его готовить? :)) Это прямо FAIL.
Тоже самое касается и Flash.

Интересно, почему после переписывания приложения на PHP оно большинство времени не работало, а отдавало 502?
spb_borodin
Dec. 27th, 2010 03:18 pm (UTC)
1. Вы читать умеете? Как со стенкой общаюсь. Описал в статье проблему, что и почему, а в комментах все равно пишут почему :) Проблема пхп и ребита в том, что они выдают неприемлемо низкую скорость обработки, которая указана выше. Претензии к авторам экстеншена. Мы его не писали (писали экстеншн для Редиса). На его фоне другие сервера очередей выдают хорошую скорость. Я же ровно этими словами в статье написал? Большинство тех, кто использует Ребита, просто не задумываются о скорости в силу мизерности своих проектов. И нет проектов на пхп, использующих его. Поэтому обрисовать и поднять проблемы в принципе некому.

И что же там флеша касается?

2. Понимаю, когда по теме написать совершенно нечего, но хочется потроллить, другого вопроса нет.
а) Большинство времени приложение работает. Даже смешно такую глупость опровергать...
б) Проблемы 502 не имеют ни малейшего отношения к обозначенным темам по честному горизонтальному масштабированию.
в) Причины бывают такие:
- нагрузка в разы больше возможностей нашего железа (мало памяти, HDD не рейд, а простой домашний sata), только тем и заняты, как из слабого железа выбрать больше, чем оно способно дать
- спам и флуд
- регулярное осыпание винчей
- программеры наговнокодили (в силу дикого темпа разработки, чего нет ни у кого)
- балансировка нагрузки на базы хоть и есть, но работает медленно
(Anonymous)
Mar. 15th, 2011 03:35 pm (UTC)
Вопрос про хранение SESSIONS в memcache
Дмитрий, здравствуйте!
Хочу задать вам вопрос по существу:

1. Вы объясняли, что сессии хранятся в мемкеше. Если у нас 100 серверов, то на каком сервере хранится сессия определенного пользователя? на одном супер сервере мемкеша(что маловероятно) или узнаем по user_id и карте мемкешей, где он должен хранится, и храним ее на сервере предназначенном для данного user_id?

2. А если страница генерируется из одного мемкеш инстанса, а сессия хранится на другом мемкеш инстансе, то надо сразу к обоим соединяться?
spb_borodin
Mar. 15th, 2011 09:47 pm (UTC)
Re: Вопрос про хранение SESSIONS в memcache
Будем считать, что у вас не слишком крупный проект, общее число серверов менее 100. Тогда под сессии (всякие временные объекты, типа кешей) нужно отвести штук 5, на каждом по 2-3 инстанса. Проблем с числом коннектов нет (забудьте о проблемах в вашем вопросе номер 2). Если будет на порядки больше - да, надо будет сделать по другому.

Получается, никакой разницы, где будет лежать ключ - нет. Для этого существует модуль Ketama, который вам и нужно использовать, как самое простое начальное решение. Он сам будет определять, по хешу от ключа, на какой из N инстансов мемкешей положить/достать очередной ключ. Причем, если вы меняете число инстансов, ничего делать не придется, кетама сама распределит всю нагрузку равномерно.

Да, если у вас более крупный проект, значительно больше 1000 серверов, придется подумать об экономии коннектов, тут решение посложнее и кетама не подойдет. Нужно будет делать, как вы предположили - нечто от user_id вычислять.

И разумеется, этот паттерн только для сессий и временных кешей! К другим видам данных применять кетаму категорически нельзя. Если в вашем языке и модуле мемкеша нет кетамы - придумайте ее примитивный аналог (алгоритм).

Итого, сессии и кеш можно хранить очень по разному, как угодно, не особо думая о производительности, для проектов менее 100 серверов. Когда будет больше - сами поймете без моих советов, что делать.
Re: Вопрос про хранение SESSIONS в memcache - (Anonymous) - Mar. 17th, 2011 05:24 pm (UTC) - Expand
(Anonymous)
Mar. 17th, 2011 09:32 am (UTC)
Дмитрий, вы обясняли на семинаре про то, как нужно хранить данные, разбивать их на шарды и т.д.

1. Но вот допустим надо зарегистрироваться новому человеку и его емайл или другой параметр надо сравнить с имеющимися на предмет повторной регистрации и т.д. и получается нам необходимо иметь один сервер, на котором в одной таблице будут записаны все емайлы всех пользователей всех шардов, для того, чтобы сравнить. - правильно я понял?

2. и второй момент с сессиями, которые можно хранить в памяти одного мемкаш инстанса. изходя из семинара сессия хранится не более двух часов, а как же тогда момент разлогинивания? или необходимо сессии в одном месте хранить на два часа и дополнительно делать какую-то кукесу и хранить ее "вечно", чтобы пользователь не разлогинивался?
(Anonymous)
Mar. 17th, 2011 09:37 am (UTC)
3. Сюда же можно и прописать рассылку по всем зарегистрированным или выборочно по региону - все равно супер таблица одна получается со всеми пользователями(с определенными полями).

Причем для поиска среди пользователей (как на семинаре) - одна,а вот если еще для регистрации новых - другая?их может быть несколько с разными полями - правильно?

или одна большая с нужными полями?( и для поиска и для регистрации и для прочего сервиса)
spb_borodin
Mar. 17th, 2011 09:56 am (UTC)
Для начала о простых вещах, которые не касаются масштабирования вообще: как, не храня сессию вечно, не терять авторизацию. Решите этот вопрос на мелком проекте в 1 страничку.

Делается элементарно, в общих чертах:

1. Сессии можно хранить действительно не долго, не более получаса. Реально можно и дольше (сутки), но нельзя строить логику проекта, основываясь на это предположение. Считайте, что сессия умрет через 15 минут, обратное предположение - мина в проекте.

2. В куках юзера, которые хранятся вечно, храним специальный хеш, позволяющий на лету выполнить незаметную авторизацию и создать пустую сессию. Посмотрите на куки, как это сделано везде в соц.сетях и разных проектах. В общем, этот вопрос в форумы по программированию, а не сюда.

Про регистрацию.

Да, юзер пытается ввести мыло и мы должны узнать, уникально ли оно. Заведите специальный центральный инстанс sql для редко запрашиваемой информации. Там создайте простую таблицу: email, user_id. Обычным select проверяйте уникальность нового мыла. Если в проекте более 1.000.000 адресов, создайте сразу 10 таблиц (разбивка по первым буквам или хешу от строки). Суть в том, что подобные операции крайне незначительны, поэтому их выдержит один сервер и очень легко. Это один паттерн.

Если ваш проект направлен на то, что каждый 10й запрос к серверу будет долбится в эту таблицу, то применяем другой паттерн. Заводим отдельный физический сервер с master sql. Там та же таблица (возможно, разбивка на 10 таблиц). Еще заводим пару серверов со slave sql.

Этот паттерн подходит для всякой справочной информации, типа объявления, анкетный поиск юзеров, выборка товара, баннеров и т.д. Прекрасно и быстро будет работать до 20-50 млн пользователей (сущностей). Можно придумать nosql решения, но не нужно тратить время, когда и sql справится. Эти компоненты проекта замечательно масштабируются вертикально. Просто оставьте в таблице ровно то, что нужно наиболее высоконагруженному SELECT запросу + репликация. Все остальное в соседние справочные таблицы (и вообще, их то можно горизонтально масштабировать).

Когда идет рассылка, т.е. служебное обращение к данным (не от веб-контроллера), то не важно, как быстро оно будет работать. Поэтому пусть оно не спеша читает те же самые таблицы. Не выдумывайте себе проблем, когда их нет. Позаботьтесь, чтобы наиболее высоконагруженная операция у юзеров работала мгновенно. Это, как правило, страница с показом профайла пользователя (сущности вашего проекта) и чтение сообщений.

Кстати, для вопросов - специально создан следующий топик .-)
( 59 comments — Leave a comment )