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

Category:

(#1) Как устроены крупные соц.сети изнутри. Часть 1. О мифах после конференции Highload++.

Это вступительное слово к проводимым мастер-классам, которые дадут вам практические сведения, как на самом деле можно построить крупный горизонтально масштабируемый проект web 2.0 с нуля (самостоятельно). Вы досконально понимаете, как устроен крупные и можете воспроизвести их аналог сами? А так же комментарии о многих важных недосказанных моментах к прошедшей конференции Highload++ в октябре 2010 года.

Сожалею, в этой короткой статье, не будет ответа, как построить крупный проект. Но зато будет написано, где и каким образом получить данные сведения, а так же, на что не надо тратить время. Вы наверняка внимательно читали сайты типа insight-it. И, конечно, понимаете - это всего лишь общие слова. Такие же, как описание НЛО сотнями очевидцев. Только вот проблема: как НЛО работает и как вам лично воспроизвести тоже самое - не написано. Я попробую исправить это.

Здесь и далее речь идет о неком абстрактом проекте (соц.сеть, приложние для соц.сети, веб-магазин, СМИ, блог, FLASH игра, каталог знаний и т.д.) с 10-100 млн пользователей. Не важно, какова роль сущностей в проекте, заменяйте по ходу чтения слово “пользователь” на “товар” или “ветка обсуждения”. Не важно, на каком языке и базе данных вы это делаете, каков тип и функционал вашего проекта.

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.
  • 66 comments
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →
Камрад следит за сайтом
очень тронут вниманием .-)

Anonymous

July 31 2013, 18:54:56 UTC 6 years ago

Мне интересный следующий вопрос
я имею таблицу пользователей Users:
id //ид мой уникальный автоинкрементный
login
password

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

другие таблицы планируется разбить по userID
В корне неправильная логика!

Оценим, какой % нагрузки будет приходится именно на формочку авторизации, по сравнению с общей дикой нагрузкой от 100 млн юзеров? Ну, ткнув пальцем в небо, ответ будет 0,000001%. А есть функционал, на который придется 50% нагрузки, это банальное чтение профайла. Решите, для начала, успешно более важную задачу и я даю гарантию, та, на 0,000001%, как-то сама рассосется .-)

Ну, если отвечать серьезно, достаточно разбить в пределах центрального сервера эту таблицу по 10 млн записей или использовать эластик.
Классная статья, соглашусь со многим, но выделю главную мысль - управлять черным ящиком занятие неблагодарное, лучшее решение это простое решение! Решение, которое создано своими руками (и мыслями о дальнейшей масштабировании)
Спасибо за статью
Что лучше использовать: редиску или Memcache?
Если выбирать что-то одно - редис. Но и мемкеш имеет свои плюсы в простоте и надежности.
Спасибо за полезную информацию из собственного опыта.

Расскажите, пожалуйста, более подробно об устройстве спотов на шардах БД. Как хранятся таблицы в базе? Все споты в одной базе на шарде? Если, например, в БД в одном споте 50 таблиц, а на сервере 500 спотов, то получается каша из 25 000 таблиц в одной БД только на одном сервере.

Как происходит генерация ID для пользователей / вычисление нужно шарда по id юзера и т.п. Как и где хранится информация о соответствии id пользователя / нужного шарда и как нескольким инстансам приложения на разных серверах получать к ним доступ?

Что думаете о готовых решениях для шардинга типа MySQL Fabric или Vitess?

Спасибо.

Re: Шардинг

Андрей Смирнов

October 15 2017, 17:57:09 UTC 2 years ago Edited:  October 16 2017, 06:57:23 UTC

Какую очередь для отложенной обработки используете, если от RabbitMQ отказались? Воркеры для обработки очереди запускаются по крону?

Что используете для реализации системы личных сообщений (вебсокеты/long-polling)? Как при этом происходит уведомления пользователей из разных шардов о новых сообщениях? Как хранятся сообщения/чаты в MySQL?

Как создаются и наполняются данными новые споты? Отслеживается ли на сколько наполнился спот данными и как этом связано с логикой приложения на PHP?

Спасибо.
> Расскажите, пожалуйста, более подробно об устройстве спотов на шардах БД

Да уж рассказывал по комментариям не раз.

> Как хранятся таблицы в базе?

Самым обычным образом.

> Все споты в одной базе на шарде?

Да. Один инстанс MySQL хранит много логических баз данных. В каждой из них лежит целиком один или несколько спотов, т.е. набор всех таблиц группы пользователей с 7001 по 8000 будет физически находится в одном месте.

> Если, например, в БД в одном споте 50 таблиц, а на сервере 500 спотов, то получается каша из 25 000 таблиц в одной БД только на одном сервере.

Как правило, когда проект подрос, там несколько сотен таблиц.

500 спотов на сервер - это многовато, но всякое может быть.

Чтобы не было каши, необходимо создать десятки виртуальных баз в каждом инстансе MySQL. Либо даже можно по одной БД на спот (в одном инстансе). Поищите различие между словами "инстанс MySQL" и "база в инстансе MySQL". Если же делать одну БД - да, каша, файловая система не оценит.

> Как происходит генерация ID для пользователей

$n++ (в конфигурационной таблице центрального сервера)

> вычисление нужно шарда по id юзера

Слово шард использовать не нужно.

Если известен номер юзера, то сразу известен номер спорта (достаточно поделить на 1000 нацело и прибавить 1).

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

> Что думаете о готовых решениях для шардинга типа MySQL Fabric или Vitess?

Ничего не знаю, т.к. не интересовался никогда черными ящиками, которые могут отказать. В теории MongoDB должно решать все то, чему я учу. Но дичайшая ущербность реализации не позволяет всерьез воспринимать такие поделки. Лет через 10, наверно, их допилят, чтобы можно было применять на проектах масштаба 100-1000 серверов. Но, вряд ли, до бесконечно они позволят масштабироваться.
Спасибо за ответ и полезную информацию. Я смотрел Ваши презентации с Highload и читал комментарии здесь и в соседних темах, но у меня все-таки осталось несколько вопросов именно по устройстве шардов / спотов в БД.

Допустим у нас есть 100 млн. пользователей. Информацию о каждом пользователе мы храним в нескольких таблицах (например, users, photos, messages и т.п.). Всех пользователей мы разбиваем на споты по 1000 и соответственно получаем 100 000 спотов. В каждом споте будет хранится вся информация о 1000 пользователей (таблицы users, photos, messages и т.п.).

Дальше мы решаем разместить 100 000 спотов на 200 физических/виртуальных серверов (примерно 500 спотов на 1 сервер и 500 000 пользователей). Дальше на каждом сервере мы запускаем 10 инстансов MySQL на разных портах и в разных папках, чтобы избежать проблем с файловой системой (50 спотов на 1 инстанс). В каждом инстансе MySQL создаем 50 баз данных с именами spot1, spot2 ... spotN, в каждом из которых будет хранится информация о 1000 пользователей (таблицы users, photos, messages и т.п.). Информацию о соответствии спотов, физических серверов и инстансов MySQL храним в отдельных конфигах/таблицах.

Например, нам нужно получить информацию о пользователе с id 20567. Для этого мы вычисляем следующие параметры:

1) spot_id = (int) (20567 / 1000) + 1 = 21

2) server_id = (int) (spot_id / 500) + 1 = 1 (пользователь на 1 сервере, 500 спотов на сервер)

3) instance_id = (int) (spot_id / 50) + 1 = 1 (пользователь на 1 инстансе MySQL, 50 спотов на 1 инстанс БД)

Дальше из конфигов берем параметры подключения к серверу / БД и подключаемся. Я правильно понимаю?

Я просто хочу убедится, что я все правильно понял и я на верном пути.

Заранее спасибо!
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →