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

Categories:

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

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

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

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

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

Read more...Collapse )
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 →

Anonymous

March 17 2011, 09:32:05 UTC 8 years ago

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

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

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

Anonymous

March 17 2011, 09:37:41 UTC 8 years ago

3. Сюда же можно и прописать рассылку по всем зарегистрированным или выборочно по региону - все равно супер таблица одна получается со всеми пользователями(с определенными полями).

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

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

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

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

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

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

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

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

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

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

Кстати, для вопросов - специально создан следующий топик .-)
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →