Модель данных базы Redis для личных сообщений

Делал удобную личку с mysql теперь хочу ( пока для развития) сделать такую же личку с nosql базой Redis
логика системы такая - имеем список контактов и переписку с каждым из них, как месседжер

в мускуле была такая структура таблиц

таблица диалогов

CREATE TABLE IF NOT EXISTS `dialogs` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `who_id` int(11) NOT NULL,

  `with_id` int(11) NOT NULL,

  `lastmsg_id` int(11) NOT NULL,

  `unreadmsg` int(11) NOT NULL,

  `all_countmsg` int(11) NOT NULL,

  `timestamp` varchar(30) NOT NULL,

  PRIMARY KEY (`dlg_id`)

  KEY `with_id` (`with_id`),

  KEY `who_id` (`who_id`)

) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

who_id - кто завел диалог
with_id - с кем завел диалог
chain_id - ид цепочки сообщений (инкрементится вручную)
lastmsg_id - ид последнего сообщения ( чтобы выводить его в списке диалогов, так нагляднее)
unreadmsg - количество не прочитанных сообщений
all_countmsg - количество всех сообщений в переписке
timestamp - время добавления

при отправке сообщения добавляются/перезаписываются две записи в таблице
1 who_id = отправитель with_id = получатель
2 who_id = получатель with_id = отправитель
для облегчения дальнейшей выборки, чтобы не выбирать (who_id = отправитель with_id = получатель) or (who_id = получатель with_id = отправитель)

CREATE TABLE IF NOT EXISTS `private_message` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `message` text,

  `from_id` int(11) NOT NULL,

  `to_id` int(11) NOT NULL,

  `read` enum('0','1') DEFAULT NULL,

  `from_del` enum('0','1') DEFAULT NULL,

  `to_del` enum('0','1') DEFAULT NULL,

  `read_time` varchar(30) DEFAULT NULL,

  `create_time` varchar(30) DEFAULT NULL,

  PRIMARY KEY (`id`),

  KEY `to_id` (`to_id`),

  KEY `from_id` (`froid`),

  KEY `to_del` (`to_del`),

  KEY `from_del` (`from_del`)

) ENGINE=MyISAM  DEFAULT CHARSET=utf8  AUTO_INCREMENT=1 ;

message - сообщение
from_id - от кого
to_id - кому
read - прочтено или нет
from_del - удаленно отправителем
to_del - удалено получателем
read_time - время получения
create_time - время отправки

выборка идет по получателю и отправителю логической командой OR, так же отсортировываются удаленные пользовател сообщения

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


ладно задача в другом, как построить похожую структуру для редиски чтобы можно было реализовать такую же систему личных сообщений??

вот мой взгляд

тип данных sorted sets или sets( не особо разобрался как сортировать в редисе )

msgs:id_user:mydialogs {user_id_1, user_id_2, user_id_3, ........ user_id_n}

id_user - ид пользователя(свой ид)
user_id_1, user_id_2 список моих контаков
то есть кто уже есть у меня в диалогах...берем список юзеров -] получаем диалоги, количество новых сообщений и т.д и выводим список юзеров с последними сообщениями


тип данных list или hash

msgs:u1:u2:dialogs { chain_id_u1, count_all_msgs, unread_count, last_msg_id}
msgs:u2:u1:dialogs { chain_id_u2, count_all_msgs, unread_count, last_msg_id}

ключи
u1 - кто
u2 - с кем
поля
chain_id_u1 - номер ключа со списком id сообщений для первого пользователя
chain_id_u2 - номер ключа со списком id сообщений для второго пользователя
(отдельно, чтобы сообщения при удалении одной стороны не удалялись у другой)
count_all_msgs - всего сообщений
unread_count - новых
last_msg_id - ид последнего сообщения


тип данных sorted sets или sets

msgs:id:chain {1, 2, 3, 4, 5 , ........ msgs_id_n}

тут всё просто вроде, списки идшников сообщений.. только как сортировать и удалять нужные пока не знаю, и вообще возможно ли?


тип данных list или hash

msgs:id:message { sender_id, body_msg, timestamp}

тут еще проще, сами сообщения и их отправители


msgs:chain_increment - инкрементим ключи для цепочки сообщений

msgs:messages_increment - инкрементим ключи для сообщений

К сожалению помочь не могу, нет практического опыта использования подобных недо субд, хотел спросить для чего такая экзотика, если даже на MySQL есть далеко не все что нужно чтобы считать ее полноценной СУБД) Вы полагаете будущее за такими примитивными хранилищами данных как редиска? Я не стебаюсь, просто питаюсь понять смысл использования таких хранилищ.

Цитата ("MMM_Corp"):

Вы полагаете будущее за такими примитивными хранилищами данных как редиска?

Вы, видимо, имеете ввиду "заменят ли подобные хранилища реляционные базы данных"? Нет, не заменят. У них своя ниша, это свой класс хранилищ со своими особенностями и преимуществами.

Цитата ("MMM_Corp"):

смысл использования таких хранилищ

Очень уж они быстрые.