Основной поток данных от отслеживания пользователя до прямой трансляции

Question

Может ли кто-нибудь объяснить, как проходит поток от точки отслеживания пользователя до прямой трансляции с точки зрения модели данных?У моей команды разработчиков есть проблемы с этим:

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

Проблемы:
1) Действие 1: M.Как я могу отметить 10 человек на 1 фотографии.Поэтому, очевидно, я не буду записывать 10 отпечатков в таблице активности для этого.Следовательно, нужна ли мне еще одна таблица для хранения сведений об операции?

2) Поскольку в эту таблицу заносится вся деятельность по всем объектам, из которой она подается в таблицу каналов действий для вывода в канал операций,feed должен знать все объекты, участвующие в задании, поэтому он может сказать: «X помечены Марком, Джоном, Сарой на фотографии Тима».где Mark, John, Sarah - это в основном пользовательские объекты, ссылающиеся на их профили.Фотография - это фотообъект, связанный с таблицей фотографий ...

Выше приведен пример, но есть много объектов, таких как фильмы, музыка, бренды, города и т. Д. Итак, каким образом система должна знать об этомЗаписать таблицу в ленту действий, какой объект, что и где находится, чтобы он мог включить соответствующие данные в ленту новостей.Для этого у меня есть 2 столбца: object_id и object_type_id, где object_type похож на «User, Photo, Brands и т. Д.), А object_id - это идентификатор объекта. Но как связать это с фактическими таблицами?

3)И наконец, является ли этот дизайн лучшим способом перехода от отслеживаемых данных к каналу, то есть к журналу, к таблице журналов. Таблица журналов может иметь таблицу подробностей, а таблица журналов соединяется с таблицей сеансов. Каждые 2 минутыЗадание кукурузы запланировано для извлечения этих данных в таблицу каналов активности, которая денормализована и извлекает данные из этих + таблиц объектов для прямого чтения в прямом эфире.

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

Answer 1

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

2. Я бы также записал Activitybatchid в таблицу очередей для обработки, которую будет читать задание cron, чтобы добавить элементы в таблицу каналов. После обработки ActivityBatchid он будет удален.

3. Я рекомендую использовать рекурсивное задание cron в такой ситуации, когда за один раз считывается одна строка или пакет строк, а затем обрабатывается при сохранении блокировки, чтобы никакой другой процесс не мог прочитать эту таблицу. Вы можете указать количество строк, обрабатываемых за раз, для повышения производительности. Также в случае смерти этого процесса блокировка будет снята после определенного времени простоя.

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

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