Использование Redis EXPIRE для отслеживания онлайн-аудитории в Rails

[zvirusz]

А не лучше ли использовать сэты, вместо ключей с пустыми значениями?
Т.е. при каждом посещении пользователя добавляем его айдишник в сет с именем «blabla_<текущая минута>», ставить этим сетам expire в сколько-там-нужно-минут и доставать список активных пользователей через «SUNION blabla_1 blabla_2… blabla_59»

[deep_orange]

Весьма интересное предложение. В принципе если использовать отдельную базу — то и с пустыми ключами проблем не будет. Как нибудь на недельке найду время протестировать Ваш подход — и сравнить размер базы и производительность, сейчас увы занят. Не до конца понял Вашей идеи — идея интересна если только Вы предлагаете не для каждого пользователя использовать свой сет, а всего иметь 10 сетов — на каждую минуту (в принципе можно и на каждые 10 секунд свой сет) — и в текущий (текущей минуты) сет добавлять вошедших. Надеюсь я хотя б чуть понятен. Вообще говоря у меня под подозрением скорость поиска по сету при его большой длине.

[zvirusz]

Да-да, всё верно — я предлагаю 10 сетов. Для ускорения — можно в кроне несколько сетов запихать в один сет (SUNIONSTORE), а дальше SISMEMBER, которая O(1) (как и GET).

[b_r]

Вредные советы.
У keys время выполнения прямо зависит от количества ключей в редисе (http://redis.io/commands/keys)

[deep_orange]

Я просто представляю веб-страницу у которой есть отметка — сколько пользователей сейчас онлайн. Т.е. каждый запрос каждого пользователя — это и запрос количества онлайн пользователей. В этом случае что-то вроде User.where("last_online_time > ?", 10.minutes.ago) вряд ли окажется быстрее аналогичной операции в Redis.

[deep_orange]

Для оперативной памяти не столь важно O(n) или O(logn), скорость всё-равно на несколько порядков больше чем для диска. А вот связанный список позволяет сократить «оверхэд» до минимума. Стоит только подумать, сколько «лишней» информации придётся хранить в памяти, для того же красно-чёрного дерева. Для тех кто не в курсе, связанный список хранит значение и указатель на следующий элемент, в то время как красно-чёрное дерево: значение, указатель на левое поддерево, указатель на правое поддерево, цвет (если дерево не опирается на левую сторону (LLRB), то ещё и указатель на предка, кстати для такого дерева вставка медленней, чем для «обычного»). На 64-битных машинах (та же Ubuntu 14.04 x86_64) размер указателя — 64 бит. Цвет для скорости работы, скорее всего, тоже будет выровнен по этой границе (ну это уже на усмотрение разработчика).

Проще говоря — то, что справедливо для io операций, не всегда справедливо для оперативной памяти. То же B+дерево в памяти, это в обще маразм.

[printercu]

Вместо pipelined у вас можно использовать .set key, val, ex: timeout

[deep_orange]

+. Срочно переделываю статью. И ещё плюс от бенча (65k записей):

       user     system      total        real
   7.540000   2.870000  10.410000 ( 11.532065)  # .set key, val, ex: timout
  13.110000   4.450000  17.560000 ( 19.195621) # .pipelined{ .set + .expire }

[nedoshel]

еще бы сюда нотификацию об удалении ключа как-то подключить, был бы del callback. redis.io/topics/notifications