Форум PHP

Возник острый вопрос по хранения сообщений пользователей в хранилище Redis. Сейчас сообщения хранятся как JSON объект в типе List. Сейчас все сообщения определены общим уникальным ключом, т-е по отдельности сообщения не имеют своего уникального ID, с чем возникают сложности при попытке связать таблицу сообщений с другой(SETS). Вопрос в том, как определить для каждого сообщения свой автоинкремируемый ID. И второе, как хранить статус прочитанного сообщения или нового?

>Сейчас сообщения хранятся как JSON объект в типе List.
Вам бы тогда лучше MongoDB использовать.

>Сейчас все сообщения определены общим уникальным ключом, т-е по отдельности сообщения не имеют
>своего уникального ID, с чем возникают сложности при попытке связать таблицу сообщений с
>другой(SETS).
Вы не гипнотизируйтесь контейнерами, в простых хранилищах можно очень очень гибко хранить объекты, манипулируя ключом

post:12512 {json}
post:12513 {json}
post:12514 {json}

post:12512, post:12513, post:12514 - это ключи, число - фактически это ID, которого вам не хватает, тем более именно в случае Redis вы можете выбирать все ключи при помощи

keys "post:*"

>Вопрос в том, как определить для каждого сообщения свой автоинкремируемый ID. И второе, как хранить
>статус прочитанного сообщения или нового?
Только исправлять значение... вам MongoDB нужна, а не редис. Как вариант, полагаться на друблирование в реляционной СУБД MySQL или PostgreSQL, используя redis в качестве быстрого кэша.

post:12512 {json}

- это в каком типе данных (контейнере) хранить? String или List?
Как генерировать автоматический новый ключ, равный значению предыдущего + 1?
Или придется каждый раз при добавлении извлекать последний ключ и делать ++?
И что вы можете подсказать по хранению сообщений пользователей, сейчас у меня все сообщения помещаются в List, с ключом равным

id_user1_id_user2

.
Допустим 2 пользователям общаются между собой. Id - первого 145, второго 151.
ключ List по которому будут ложиться сообщения будет: 145_151.
Проблема встает подсчета прочитанных сообщений и новых для каждого из пользователей а так же для каждого из сообщений нет уникального ключа, подобное такому:

keyList:keyMessage: {object message}

Редис - быстрое NoSQL решение, тут нет механизмов классической реляционной базы данных, ключи вам придется генерировать самому, как и следить за связями. Вам не заменить полностью при помощи Redis базу данных. Redis - это такой прокаченный memcached, в нем много чего есть, но это не СУБД.

Я бы не стал полагаться на один Redis в качестве хранилища данных, хотя, да очень заманчиво, один redis-сервер держит обращения от доброго десятка серверов-приложений, да еще и репликацию поддерживает, т.е. может быть в любой момент масштабирован. Однако, за такую устойчивость приходится расплачиваться - атомарностью, согласованностью, удобством и всем тем, за что мы ценим классические СУБД, которые, кстати, тоже прекрасно масштабируется на несколько серверов (и кстати, тоже могут быть настроены на работу с оперативной памятью - почти всю базу туда можно ухнуть - будет не так быстро, как redis, но на пару порядков быстрее, чем вообще без настройки).