Как это делает Facebook?

Question

Вы когда-нибудь замечали, как в фейсбуке написано «3 друзьям и 33 другим это понравилось»? Мне было интересно, как лучше всего это сделать. Я не думаю, что просматривать список друзей и список пользователей, которым «понравилось», и сравнивать их - это вообще эффективно! Они отслеживают это в базе данных? Это сделает размер базы данных очень большим. Что вы, ребята, думаете?

Спасибо!

Answer 1

Я полагаю, что они внешне присоединяются к своей таблице friends со своей таблицей likes, чтобы подсчитывать как обычные лайки, так и лайки друзей одновременно.

С правильными индексами это не будет медленным запросом. Огромные базы данных не обязательно медленные, поэтому на самом деле нет причин не хранить всю эту информацию в базе данных. Хитрость заключается в том, чтобы убедиться, что индексы и разделы (если есть) настроены правильно.

Answer 2

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

http://www.25hoursaday.com/weblog/2009/09/10/BuildingScalableDatabasesDenormalizationTheNoSQLMovementAndDigg.aspx

Там много интересного, если вы перейдете по ссылкам на него в блоге Digg и т. Д.

Answer 3

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

Что касается масштабируемости, я уверен, что они используют много кэширования.

Вот пример:

Если вам нужно пройти 1 миллион строк, индекс может выполнить O (logn) = 20 операций (в худшем случае) только для того, чтобы найти то, что вам нужно.

Для 2 миллионов вам потребуется всего 21 операция (в худшем случае), чтобы найти то, что вам нужно.

Каждый раз, когда вы удваиваете количество пользователей, проходящих через вас, вам просто требуется всего лишь 1 операция (в худшем случае) с индексом O (logn).

Они также имеют распределенную архитектуру или кластерную базу данных.

Answer 4

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

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

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

Answer 5

При разработке программного обеспечения для социальных сетей (mothsorchid.com) я нашел единственный способ решить эту проблему - предварительно кэшировать потоки уведомлений. Никто не запрашивает базу данных во время загрузки страницы, чтобы подсчитать, сколько друзей и других «понравилось», когда кому-то «нравится» что-то, что записано на объекте, и при получении объекта его можно сравнить с текущим пользователем список друзей. Если кто-то обновляет свой профиль / комментирует / и т. Д., Он отправляет объекты уведомлений друзьям, которые предварительно кэшированы в их каналах. Значительно сокращает работу базы данных за счет дискового пространства, но дисковое пространство дешевое.

Что касается того, как Facebook делает это, они используют СУБД Cassandra, что, вероятно, немного отличается от того, что вы имеете в виду.

Answer 6

Имейте в виду, что Facebook активно использует memcached , поэтому они сохраняют много данных в памяти и обновляют их только в случае крайней необходимости. См. Этот пост в блоге для обсуждения масштабируемости:

http://www.facebook.com/note.php?note_id=39391378919

Answer 7

Многое из этого объясняет технический директор Facebook в презентации QCon:

http://www.infoq.com/presentations/Facebook-Software-Stack

Отличная презентация для просмотра .....

Answer 8

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