Каков лучший способ реализации потока общественной деятельности? [закрытый]
Как будто вы пытаетесь получить доступ к объекту, который является null. Рассмотрим ниже пример:
TypeA objA;
. В это время вы только что объявили этот объект, но не инициализировали или не инициализировали. И всякий раз, когда вы пытаетесь получить доступ к каким-либо свойствам или методам в нем, он будет генерировать NullPointerException, что имеет смысл.
См. Также этот пример:
String a = null;
System.out.println(a.toString()); // NullPointerException will be thrown
8 ответов
Я создал такую систему, и я проявил этот подход:
Таблица базы данных со следующими столбцами: идентификатор, идентификатор пользователя, тип, данные, время.
- идентификатор пользователя является пользователем, который генерировал действие
- , тип является типом действия (т.е. Записал, что сообщение в блоге, добавленная фотография, прокомментировало фотографию пользователя)
- , данные являются сериализованным объектом с метаданными для действия, где можно вставить то, что Вы хотите
, Это ограничивает поиски/поиски, можно сделать в подаче, пользователям, время и типы действия, но в канале действия типа Facebook, это действительно не ограничивает. И с корректными индексами на таблице поиски быстры .
С этим дизайном необходимо было бы решить, каких метаданных каждый тип события должен потребовать. Например, действие канала для новой фотографии могло выглядеть примерно так:
{id:1, userId:1, type:PHOTO, time:2008-10-15 12:00:00, data:{photoId:2089, photoName:A trip to the beach}}
Вы видите, что, хотя название фотографии несомненно хранится в некоторой другой таблице, содержащей фотографии, и я мог получить имя оттуда, я копирую имя в поле метаданных, потому что Вы не хотите делать любые соединения на других таблицах базы данных, если Вы хотите скорость. И для отображения, скажите 200, различные события от 50 различных пользователей, Вам нужна скорость.
Тогда у меня есть классы, который расширяет основной класс FeedActivity для рендеринга различных типов записей действия. Группировка событий была бы создана в коде рендеринга также, для держания сложности отдельно от базы данных.
Самыми большими проблемами с потоками событий является видимость и производительность; необходимо ограничить события, отображенные, чтобы быть только интересными для того конкретного пользователя, и необходимо сохранить количество времени, которое это занимает, чтобы отсортировать и определить те управляемые события. Я создал небольшую социальную сеть; я нашел, что в мелких масштабах, сохраняя таблицу "событий" в базе данных работает, но что это добирается, чтобы быть проблемой производительности при умеренной загрузке.
С более крупным потоком сообщений и пользователей, вероятно, лучше пойти с системой обмена сообщениями, куда события отправляются как сообщения в отдельные профили. Это означает, что Вы не можете легко подписаться на потоки событий людей и видеть предыдущие события очень легко, но Вы просто представляете небольшую группу сообщений, когда необходимо представить поток для конкретного пользователя.
я полагаю, что это было дефектом первоначального проекта Twitter - я не забываю читать, что они поражали базу данных, чтобы втянуть и отфильтровать их события. Это имело все, чтобы сделать с архитектурой и ничем, чтобы сделать с направляющими, которые (к сожалению), родили "рубин, не масштабирует" мем. Я недавно видел представление, где разработчик использовал Amazon Простой Сервис Очереди как их бэкенд обмена сообщениями для подобного Твиттеру приложения, которое будет иметь намного более высокие возможности масштабирования - может стоить изучить SQS как часть Вашей системы, если Ваши загрузки достаточно высоки.
Я начал реализовывать систему как это вчера, вот то, где я имею к...
я создал класс StreamEvent со свойствами идентификатор , ActorId , Дата Идентификатора типа , , ObjectId и хеш-таблица дополнительных Детали пары ключ/значение. Это представлено в базе данных таблица StreamEvent ( идентификатор , ActorId , Дата Идентификатора типа , , ObjectId) и таблица StreamEventDetails ( StreamEventId, DetailKey, DetailValue).
ActorId, идентификатор типа и ObjectId позволяют, чтобы событие Subject-Verb-Object было получено (и позже запрошено). Каждое действие может привести к нескольким создаваемым экземплярам StreamEvent.
я тогда создал подкласс для StreamEvent каждый тип события, например, LoginEvent, PictureCommentEvent. Каждый из этих подклассов имеет более зависящие от контекста свойства такой как [1 117] PictureId, ThumbNail, CommenText, и т.д. (независимо от того, что требуется для события), которые на самом деле хранятся как пары ключ/значение в hashtable/StreamEventDetail таблице.
При задержке этих событий от базы данных я использую метод фабрики (на основе Идентификатор типа ) для создания корректного класса StreamEvent.
Каждый подкласс StreamEvent имеет Рендеринг ( контекст Как [1 137] StreamContext) метод, который выводит событие на экран на основе переданного класс StreamContext . Класс StreamContext позволяет опциям быть установленными на основе контекста представления. При рассмотрении Facebook, например, лента новостей на домашней странице перечисляет fullnames (и связывается с их профилем) всех вовлеченных в каждое действие, тогда как, смотря канал друга Вы только видите их имя (но полные имена других агентов).
я еще не реализовал совокупный канал (Facebook домой), но я предполагаю, что создам таблица AggregateFeed, которая имеет поля идентификатор пользователя , StreamEventId , который заполняется на основе некоторого 'Hmmm, Вы могли бы найти этот интересный' алгоритм.
Любые комментарии в широком масштабе ценились бы.
// one entry per actual event
events {
id, timestamp, type, data
}
// one entry per event, per feed containing that event
events_feeds {
event_id, feed_id
}
, Когда событие создается, решите, в какой подаче это появляется, и добавьте тех к events_feeds. Для получения канала выберите из events_feeds, участвуйте в событиях, порядке меткой времени. Фильтрация и агрегирование может тогда быть сделана на результатах того запроса. С этой моделью можно изменить свойства события после создания без дополнительной работы.
Если Вы действительно решите, что собираетесь реализовать в направляющих, возможно, Вы найдете следующий плагин полезным:
ActivityStreams: http://github.com/face/activity_streams/tree/master
, Если ничто иное, Вы доберетесь для рассмотрения реализации, и с точки зрения модели данных, а также API, предусмотренного, продвигая и вытягивая операции.
У меня был аналогичный подход к тому из heyman - денормализованная таблица, содержащая все данные, которые будут отображены в данной ленте активности. Это хорошо работает для небольшого сайта с ограниченным действием.
, Как упомянуто выше, это, вероятно, столкнется с проблемами масштабируемости, когда сайт растет. Лично, я не волнуюсь по поводу масштабирующихся проблем прямо сейчас. Я буду волноваться об этом в более позднее время.
Facebook, очевидно, сделал отличную работу по масштабированию, таким образом, я рекомендовал бы прочитать их технический блог, поскольку это имеет тонну большого содержания-> http://www.facebook.com/notes.php?id=9445547199
, я изучал лучшие решения, чем денормализованная таблица, которую я упомянул выше. Иначе я нашел выполнения, это должно уплотнить все содержание, которое было бы в данной ленте активности в единственную строку. Это могло быть сохранено в XML, JSON или некотором сериализованном формате, который мог быть считан Вашим приложением. Процесс обновления был бы прост также. После действия, помещают новое действие в очередь (возможно, использующий Amazon SQS или что-то еще) и затем постоянно опрашивать очередь относительно следующего объекта. Захватите тот объект, проанализируйте его и поместите его содержание в соответствующий объект канала, хранивший в базе данных.
хорошая вещь об этом методе состоит в том, что только необходимо считать таблицу единой базы данных каждый раз, когда тот конкретный канал требуют, вместо того, чтобы захватить серию таблиц. Кроме того, это позволяет Вам вести конечный список операций, поскольку можно появиться от самого старого объекта действия каждый раз, когда Вы обновляете список.
Hope это помогает!:)
Я думаю Plurk , подход интересен: они предоставляют Вашу всю временную шкалу в формате, который много походит на биржевые диаграммы Финансов Google.
на Это может стоить посмотреть Ning, чтобы видеть, как работает сеть социальной сети. разработчик страницы выглядят особенно полезными.
Я решил это несколько месяцев назад, но думаю, что моя реализация слишком проста.
Я создал следующие модели:
HISTORY_TYPE
ID - The id of the history type
NAME - The name (type of the history)
DESCRIPTION - A description
HISTORY_MESSAGES
ID
HISTORY_TYPE - A message of history belongs to a history type
MESSAGE - The message to print, I put variables to be replaced by the actual values
HISTORY_ACTIVITY
ID
MESSAGE_ID - The message ID to use
VALUES - The data to use
Пример
MESSAGE_ID_1 => "User %{user} created a new entry"
ACTIVITY_ID_1 => MESSAGE_ID = 1, VALUES = {user: "Rodrigo"}