ФорумРазработкаУстановка и администрирование ПОСерверы баз данных → Поток событий (с устареванием) в key-value

Поток событий (с устареванием) в key-value

  • artoodetoo

    Сообщения: 5138 Репутация: N Группа: в ухо

    Spritz 22 сентября 2010 г. 22:41

    Мне нужен какой-то толчек в понимании. Спинным мозгом чувствую, что на верном пути.
    Хочу хранить очередь пользовательских событий в redis.

    Ключом видимо будет комбинация user_id и времени (или инк. счетчика), а значением будет описание события. Я могу сразу задавать время устаревания записи, чтобы не копить бесконечно. Суть события сейчас абсолютно неважна. Интересует только доступ к этой очереди.

    В redis, насколько я понимаю, нет reset + next. Как мне итерировать очередь с головы к хвосту? Допустим я буду сохранять отдельно значение ключа самого свежего события, а дальше что?

    Профи-и-и-и!!! Вася-а-а-а-ц!!!
    ιιlllιlllι унц-унц
  • phpdude

    Сообщения: 26617 Репутация: N Группа: в ухо

    Spritz 22 сентября 2010 г. 22:48, спустя 7 минут

    там есть списки … заводи на юзера список, в список то и добавляй события, доки читай, чо профи отвлекать от онанизма?!

    /me пошел мыть руки
    Сапожник без сапог
  • artoodetoo

    Сообщения: 5138 Репутация: N Группа: в ухо

    Spritz 22 сентября 2010 г. 22:55, спустя 6 минут 55 секунд

    Спасибо маса Дуд за наставление!
    Вот нашел чего люди делали — очередь сообщений на redis. http://art-code.com.ua/articles_N154.htm
    Да, используют структуру list. Сука-сука, элементы очереди ведь не устаревают как сами записи. Это уже чуть менее красиво, чем я планировал. {+++108+++} Т.е. они не устаревают «автоматически».
    ιιlllιlllι унц-унц
  • phpdude

    Сообщения: 26617 Репутация: N Группа: в ухо

    Spritz 22 сентября 2010 г. 22:58, спустя 2 минуты 8 секунд

    Да, используют структуру list. Сука-сука, элементы очереди ведь не устаревают как сами записи. Это уже чуть менее красиво, чем я планировал.

    да, может устареть весь СПИСОК, а не отдельная структура, это неудобно :(

    сталкивался :(
    Сапожник без сапог
  • artoodetoo

    Сообщения: 5138 Репутация: N Группа: в ухо

    Spritz 22 сентября 2010 г. 23:02, спустя 4 минуты 50 секунд

    В общем здесь есть место для изобретательства. Актуально.
    ιιlllιlllι унц-унц
  • phpdude

    Сообщения: 26617 Репутация: N Группа: в ухо

    Spritz 22 сентября 2010 г. 23:06, спустя 3 минуты 19 секунд

    тебе надо "список с устареванием"? так тогда - в список добавляй айдишники записей + записывай сами записи в виде айдишников этих эвентам, ставь им время устаревания, и извлечение в 2 захода - получаем список вентов и чреез мультигет получаем список неустаревших записей, фильтруем и все - профит. хули выдумывать? :) {+++28+++}
    Карма: 86

    ы

    у меня в webmoney такой bussiness level :D
    Сапожник без сапог
  • artoodetoo

    Сообщения: 5138 Репутация: N Группа: в ухо

    Spritz 22 сентября 2010 г. 23:22, спустя 16 минут 50 секунд

    Чем больше уровней в редисе, тем ниже профит. Если запрос становится "многоходовым", может оказаться, что преимущества перед SQL улетучились.

    ιιlllιlllι унц-унц
  • phpdude

    Сообщения: 26617 Репутация: N Группа: в ухо

    Spritz 22 сентября 2010 г. 23:31, спустя 8 минут 7 секунд

    Если запрос становится "многоходовым", может оказаться, что преимущества перед SQL улетучились.

    ение памяти преде чтением с жесткого диска .. пусть даже и медленее запросы выполнится чем в скл, но профит на лицо - файловая подсистема свободна. так что не пизди, а реализуй так :D

    + мускуль на любой запрос памяти жрет дохуища все равно)
    Сапожник без сапог
  • vasa_c

    Сообщения: 3127 Репутация: N Группа: в ухо

    Spritz 23 сентября 2010 г. 1:23, спустя 1 час 52 минуты 15 секунд

    Что за события?
    Ещё там есть подписки. {+++229+++} Ещё есть упорядоченные множества.
    Можно время использовать, как оценку (значение, по которому будет сортироваться множество), периодически удаляя устаревшие.
    Зависит от того, что там всё-таки за события такие.
  • artoodetoo

    Сообщения: 5138 Репутация: N Группа: в ухо

    Spritz 23 сентября 2010 г. 1:33, спустя 10 минут 34 секунды

    любопытно, но разве эта модель не для постоянного соединения? если я вызову publish, мое сообщение получат только те, кто в этот момент подписан на канал. {+++71+++} совершенно неважно что за события. просто кусок говна, которое пользователь сервиса должен получить, пока оно не просрочено. {+++95+++} ссылка на чат Нурдхуйза дохлая
    ιιlllιlllι унц-унц
  • vasa_c

    Сообщения: 3127 Репутация: N Группа: в ухо

    Spritz 23 сентября 2010 г. 2:01, спустя 27 минут 25 секунд

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

    Сообщения: 5138 Репутация: N Группа: в ухо

    Spritz 23 сентября 2010 г. 2:06, спустя 5 минут 18 секунд

    это какбы новости. они от многих многим. вася будет участвовать в автопробеге. у пети день рождения. сарочка забеременела. {+++28+++} они не сгорают при прочтении
    ιιlllιlllι унц-унц
  • vasa_c

    Сообщения: 3127 Репутация: N Группа: в ухо

    Spritz 23 сентября 2010 г. 2:07, спустя 1 минуту 1 секунду

    Если второе, можно так.

    message:ids - общая переменная, максимальный ID сообщения
    message:$id - конкретное сообщение с ID=$id
    message:user:$uid - список сообщений для юзера $uid

    посылаем 17-му юзеры сообщение "хуё-моё":

    INCR message:ids // новый ID (25 пусть)
    SET message:25 "хуё-моё"
    EXPIRE message:25 3600 // время устаревания сообщения
    RPUSH message:user:17 25 // кинули ID сообщения в очередь сообщений пользователя


    Пользователь достаёт сообщения с другого конца.

    LPOP message:user:17 // 25
    GET message:25


    Если GET вернул нихуя, значит сообщение устарело - повторить LPOP.
  • artoodetoo

    Сообщения: 5138 Репутация: N Группа: в ухо

    Spritz 23 сентября 2010 г. 2:15, спустя 7 минут 47 секунд

    понятно. только видимо (l)push и (l)pop — читаем с самого свежего. а при надобности еще ltrim
    ιιlllιlllι унц-унц
  • ЗлобныйТролль

    Сообщения: ? Репутация: N Группа: Кто попало

    Spritz 27 сентября 2010 г. 3:21, спустя 4 дня 1 час 6 минут

    еще чуть-чуть и вы заново изобретете http://www.zeromq.org/

Пожалуйста, авторизуйтесь, чтобы написать комментарий!