1) формат данных роли не играет. Хоть XML, хоть JSON, хоть php в text/plain
2) если отсутствует шардинг и одна БД то да. Иначе — см мой комментарий про то, как устроен шардинг.
а еще недавно по телеку рассказывали про подземный Командный пункт товарища Сталина на окраине Москвы (возле каких-то прудов). Сейчас этот объект принадлежит частному лицу и организуются закрытые экскурсии, по слухам стоимость билета от 3х тугриков.
мне морские офицеры Северного флота рассказывали, что в конце 80х Горбачев по программе Сокращения вооружения распилил много действующих подлодок, но это полбеды.
Было взорвано уникальное подводное убежище, в котором под скалой на глубине пару километров прятались подлодки (ни какая атомная бобма им не страшна). Их цель была — нанесения второго удара, т.е. когда после первого удара разрушится полмира и все утихомирится, они выйдут из своей засады и надерут задницу забиякам!!!
вообще, та программа сокращения была неравноправная. Нас заставили сократить все стратегическое вооружение, а они сократили свое старье. Политика — грязное дело.
организуется таблица queue в которую пишится все события. Потом очередь читаются и события либо стираются, либо помечаются использованными. на HiLoad проектах обычно ничего не удаляется, просто ставится дополнительный сервер и все…
Вся проблема в обмене данных между шардами, более подробно об этом я уже отвечал в комментариях. Для реализации очереди — ее надо организовывать не в шардовых БД, а в центральной.
знаю, что в некоторых соц сетях используют memcacheq
можно использовать ZMQ, он более быстрый, но не масштабируется. вообще в гуугле много информации про сервера очередей (опенсоурсных и не...).
не вижу в этом проблему. Если мы формируем ленту классическим способом РСУБД, то нам тоже надо будет пройти по всем пользователям. А их десяток, два, три и даже есть сети более пяти… У каждого Пользователя, своя индивидуальная лента и формируется она раз в сутки по крону.
возможно пример не оч удачный,
это мы планировали, на тот случай — если будет действительно много сообщений.
алгоритм Ленты примерно такой:
-о каждом событии пишется в очередь
— лента разгребается по крону (раз/четыре в день) и формируются индивидуальные данные для каждого пользователя в БД.
— Пользователь видит свои данные, взятые из БД
как вариант: Можно формировать HTML и его вставлять ssi #include
пишу не только я, на Хабре есть люди, которые разбираются лучше моего
на хайлоаде выступал не я, но я имел приглашение выступить с мини-докладом, который более полно освещен в последних моих двух статьях. К сожалению не смог приехать по семейным обстоятельствам. Дай бог, выступлю на сл. год. Может информация накопится, может будет какой-то и отрицательный результат, эта технология еще мало изучена.
ответ 1) нет смысла делать ленту Друзей мнгновенной, хотя это реально. Для мгновенности можно реализовать «Эфир». Эфир — реализуется по принципу ленты и ответ будет мгновенным.
2) нагрузка на что? Не забываем, что у нас HiLoad проект, серверов много: сервер БД, сервер очередей, Web сервер, сторадж данных (о нем сознательно умолчено в статье). На сервер БД — нагрузка будет не более обычной, сервер очередей на фронт-энд ни как не повлияет. Если и будет нагрузка, то Пользователь этого не почуствует.
что касается шардинга:
не знаю на сколько мне этично рассказывать чужие идеи,
хранилище данных и хранилище файлов — это немного разные понятия и соответственно используются технологии. В данном примере речь шла о хранилище данных. Представляете, что у Вас несколько десятков миллионов пользователей. Все их данные в таблицу на одном сервере не поместятся, по этому данные разнесены по разным БД и серверам.
На одном физическом сервере БД, может находится несколько баз данных. Одна такая единица данных — называется шардом. Например, все пользователи с Id 1..200 000 — это shard1, 200 000 ..400 000 -shard2
Так вот проблема, если у человека 100 друзей и они расположены на 50 разных шардах, и пусть это будет разнесено на 15 разных физических серверах, то для реализации ленты необходимо открыть минимум 15 коннекций к разным БД. Проблему я обрисовал?
можно, даже интересно послушать альтернативы, может идеи сгодятся.
автор топика не против, но если с подробностями и примерами, то лучше отдельным блогом.
на счет по очереди на логин — это правильно подмечено,
но на создание очереди уходит всего 3к, (миллион пользователей — 3Gb) сервера RabbitMQ могут объединяться в кластер, по этому проблем с этим пока нет. честно признаюсь и миллиона пользователей пока нет.
>Ну и при таком количестве подписчиков весьма плохая идея — >рекомендовать заводить свою очередь на каждого пользователя. >Вот об этом действительно стоит подумать.
>Раз уж взялись писать социальную сеть, то пишите все своими руками.
>Иначе как-то непрофессионально получается.
и мускуль тоже написать своими руками?
>Такая очередь крайне просто реализуется обычными средствами mysql.
как показано в статье — так раза в три проще чем и раз в пять быстрее, через мускуль
Мне понравился ответ Дерика: «Раз вы что-то не понимаете, то значить Вам это не надо»
2) если отсутствует шардинг и одна БД то да. Иначе — см мой комментарий про то, как устроен шардинг.
а еще недавно по телеку рассказывали про подземный Командный пункт товарища Сталина на окраине Москвы (возле каких-то прудов). Сейчас этот объект принадлежит частному лицу и организуются закрытые экскурсии, по слухам стоимость билета от 3х тугриков.
а сколько еще таких объектов.
мне морские офицеры Северного флота рассказывали, что в конце 80х Горбачев по программе Сокращения вооружения распилил много действующих подлодок, но это полбеды.
Было взорвано уникальное подводное убежище, в котором под скалой на глубине пару километров прятались подлодки (ни какая атомная бобма им не страшна). Их цель была — нанесения второго удара, т.е. когда после первого удара разрушится полмира и все утихомирится, они выйдут из своей засады и надерут задницу забиякам!!!
вообще, та программа сокращения была неравноправная. Нас заставили сократить все стратегическое вооружение, а они сократили свое старье. Политика — грязное дело.
но возможны разные варианты повышения производительности.
а как сделать цитироание?
Вся проблема в обмене данных между шардами, более подробно об этом я уже отвечал в комментариях. Для реализации очереди — ее надо организовывать не в шардовых БД, а в центральной.
можно использовать ZMQ, он более быстрый, но не масштабируется. вообще в гуугле много информации про сервера очередей (опенсоурсных и не...).
>Выемка данных для френдленты сама по себе тяжелая операция, на которую способ уведомлений не сильно влияет.
в том-то и фокус, что не нужно ни какой выемки данных для френд-ленты. Все за тебя делает брокер.
это мы планировали, на тот случай — если будет действительно много сообщений.
алгоритм Ленты примерно такой:
-о каждом событии пишется в очередь
— лента разгребается по крону (раз/четыре в день) и формируются индивидуальные данные для каждого пользователя в БД.
— Пользователь видит свои данные, взятые из БД
как вариант: Можно формировать HTML и его вставлять ssi #include
на хайлоаде выступал не я, но я имел приглашение выступить с мини-докладом, который более полно освещен в последних моих двух статьях. К сожалению не смог приехать по семейным обстоятельствам. Дай бог, выступлю на сл. год. Может информация накопится, может будет какой-то и отрицательный результат, эта технология еще мало изучена.
2) нагрузка на что? Не забываем, что у нас HiLoad проект, серверов много: сервер БД, сервер очередей, Web сервер, сторадж данных (о нем сознательно умолчено в статье). На сервер БД — нагрузка будет не более обычной, сервер очередей на фронт-энд ни как не повлияет. Если и будет нагрузка, то Пользователь этого не почуствует.
не знаю на сколько мне этично рассказывать чужие идеи,
хранилище данных и хранилище файлов — это немного разные понятия и соответственно используются технологии. В данном примере речь шла о хранилище данных. Представляете, что у Вас несколько десятков миллионов пользователей. Все их данные в таблицу на одном сервере не поместятся, по этому данные разнесены по разным БД и серверам.
На одном физическом сервере БД, может находится несколько баз данных. Одна такая единица данных — называется шардом. Например, все пользователи с Id 1..200 000 — это shard1, 200 000 ..400 000 -shard2
Так вот проблема, если у человека 100 друзей и они расположены на 50 разных шардах, и пусть это будет разнесено на 15 разных физических серверах, то для реализации ленты необходимо открыть минимум 15 коннекций к разным БД. Проблему я обрисовал?
автор топика не против, но если с подробностями и примерами, то лучше отдельным блогом.
но на создание очереди уходит всего 3к, (миллион пользователей — 3Gb) сервера RabbitMQ могут объединяться в кластер, по этому проблем с этим пока нет. честно признаюсь и миллиона пользователей пока нет.
>Ну и при таком количестве подписчиков весьма плохая идея — >рекомендовать заводить свою очередь на каждого пользователя. >Вот об этом действительно стоит подумать.
а что предлогаешь?
>Иначе как-то непрофессионально получается.
и мускуль тоже написать своими руками?
>Такая очередь крайне просто реализуется обычными средствами mysql.
как показано в статье — так раза в три проще чем и раз в пять быстрее, через мускуль
Мне понравился ответ Дерика: «Раз вы что-то не понимаете, то значить Вам это не надо»