Laravel 5.5 — Уведомления / Субно уведомления для 1 миллиона подписчиков?

Я использую notifications стол и subnotifications таблица, и я также использую очереди, поэтому он работает в фоновом режиме, когда пользователь что-то публикует. Когда у пользователя есть 10 подписчиков, и они создают сообщение, notifications таблица получает одну запись, которая включает в себя данные публикации для уведомления, и subnotifications таблица получает 10 записей (по одной субно-уведомления на каждого подписчика, каждая ссылается на идентификатор уведомления, поэтому нам не нужно повторять данные уведомления 10 раз, с read_at узнать, читал ли он этот подписчик или нет).

Это быстро и прекрасно работает без каких-либо проблем. Однако при тестировании с 1 миллионом подписчиков требуется около ~ 6 часов Вставить субно-уведомления для одного поста! Это, конечно, неприемлемо, так как для вставки 1 миллиона вложенных уведомлений требуется слишком много времени, по одному на каждого подписчика. Представьте, что тот же пользователь постит 10 постов, это будет как ~ 60 часов вставки и 10 миллионов строк субнотификации.

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

ОБНОВЛЕНИЕ: Застрял с текущим подходом, см. Ниже …

Если последователь $user имеет 100 лидеров, которых они следуют (которые они следовали в разных created_at временные метки, конечно, в таблице фолловеров), что будет правильным запросом о новых постах лидера со времени, когда фолловер следил за каждым лидером? Я застрял в created_at с этим псевдокодом:

// Assume `leader_id` is a column in the notifications table
DB::table('notifications')
->whereIn('leader_id', $leaderIds)
->where(`created_at`, '>', $whatTimestampsGoHere)
->paginate(20);

Существует 100 различных временных меток, и я застрял на том, как решить эту проблему правильно и эффективно. Есть идеи?

0

Решение

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

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

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]