Хранение большого объекта (с точки зрения размера) не является хорошей практикой. Вы можете прочитать это из здесь . Одной из проблем является сеть. Вам необходимо отправить 50 МБ полезной нагрузки на сервер Redis за один вызов. Кроме того, если вы сохраняете их как один большой объект, то при извлечении и обновлении его (одно поле, элемент и т. Д. c) вам необходимо получить 50 МБ обратно с сервера и проанализировать его, чтобы получить одно поле, обновить его до конца отправить обратно на сервер. Это серьезная проблема с точки зрения сети.
Вместо redis strings вы можете предпочесть sorted sets или lists в зависимости от вашего варианта использования. Если вы собираетесь хранить их с временными метками и получать диапазон событий между этими временными метками, то sorted sets может быть идеальным решением для вас. Это хорошо для нумерации страниц и др. c. Одним из решающих недостатков является сложность добавления нового элемента O(log(N)).
lists также может обеспечить хорошую игровую площадку для вашего случая. Вы можете использовать LPUSH / RPU SH для добавления новых событий в ваш список, и, поскольку Redis lists реализованы с помощью linked lists, то при добавлении сообщения в начало или конец списка то же самое, O(1), что отлично.
Всякий раз, когда происходит событие, вы либо звоните zadd, либо RPUSH / LPUSH, чтобы отправить события в redis. Если вам нужно запросить их, вы можете использовать доступные функции, такие как ZRANGEBYSCORE или LRANGE в зависимости от вашего выбора.
При разработке ваших ключей вы можете использовать такой идентификатор, как идентификатор пользователя, как вы упомянули в комментариях. У вас не будет проблем со списками / отсортированными наборами, как у вас будет в strings. Но выбор наиболее подходящего варианта зависит от вашего варианта использования для чтения / записи или бизнес-правил.
Вот несколько полезных ссылок для чтения;
Redis intro data intro
типы данных Redis
Redis лабораторная документация о типах данных