Как структурировать Redis для схем данных со слишком большим количеством ассоциаций - mongodb

Question

У меня есть приложение с более чем 10 отдельными моделями данных. Каждая из этой модели так глубоко связана друг с другом. Например, существует модель, называемая пользователем, которая связана с другими моделями данных, такими как сообщения, комментарии, ответы, соединения и т. Д. Я пытаюсь использовать систему Redis Cache, которая будет кэшировать данные каждый раз при выполнении запроса. Итак, рассмотрим этот сценарий, в котором за публикацию проголосовали, когда произойдет этот запрос, мне придется обновить все модели, которые так или иначе связаны с этим запросом.

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

Answer 1

Это очень широкий вопрос.Я не знаю, как выглядит ваша схема БД и эти отношения сущностей.Но у меня есть несколько предложений, которые, я надеюсь, помогут вам структурировать ваши данные.

Разбейте ваши сущности Храните user, post, comment, reply отдельно.Когда вам нужно получить, например, post, получите сообщение и все его сущности отдельно от redis, затем объедините их, чтобы создать ответ.

Что-то вроде POST:345, USER:23, COMMENT:567.

Не хранить все в redis Поддерживать кеш намного сложнее.Храните только те данные, к которым вы обращаетесь чаще, и это действительно окажет влияние, если вы отправите их из кеша.Например, сохранение профиля пользователя улучшит all post responses, comment responses, connection lists и т. Д., Потому что все они будут иметь пользовательские объекты, и вы их кэшируете.

Увеличивайте статистику непосредственно в redis Значения лайков и количества комментариев могут напрямую increment и decrement при повторном отображении.

Обнулить кэш при обновлении Когда объект обновляется, не обновляйте его кэш.Просто удалите его из кеша, и следующий вызов get кеширует обновленные данные.Это просто для упрощения вещей в коде.