Эффективно реализовать функцию «отслеживания» в GAE

Question

Я реализую приложение для iPhone с функцией «follow» в Java / GAE. Эта функция похожа на Instagram в том, что пользователь может следить за событиями других пользователей. События могут быть новыми опубликованными фотографиями, любить фотографии, подписаться на других пользователей и т. Д.

Допустим, у нас есть две сущности: Follow и Event, каждая из которых имеет ссылку на идентификатор пользователя.

Так что я думаю об использовании запросов ИЛИ, где мы можем перечислить события целевых пользователей. Но GAE не поддерживает запросы OR, и выдача отдельных запросов также будет неэффективной, поскольку число запросов может быть довольно большим (например, 100+ следует за нормой).

Что является обычной практикой для этого?

Answer 1

Я бы использовал ListProperty как для подписок, так и для подписчиков.Каждый раз, когда подписанный пользователь публикует сообщения, вы используете задачу для добавления записей, которые должен видеть каждый подписчик.Как отметил Рик Манги, реляционная модель не поможет вам с хранилищем данных.Если вы используете новый NDB API, вы можете вместо этого использовать свойство repeat .Поскольку вы создаете сущности для каждого наблюдателя, асинхронный API может быть полезен.

Answer 2

Мы внедряем модель, которую Etsy описал в своем общедоступном слайде.

Вот схема схемы.

Настоятельно рекомендуем прочитать их презентацию целиком.

Etsy Activity Feed Arch

Answer 3

Вы должны перестать думать в реляционной модели ;-) Мы делаем нечто подобное в нашем приложении.Храните список UID, которые «подписаны» на пользователя, за которым следуют в объекте следующего пользователя.Когда пользователь делает что-то, что требует уведомления, создайте объект события для каждого пользователя, который следует за пользователем (да, популярный пользователь может создать целую кучу записей, это может быть выгружено в очередь задач).

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

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