Redis Структура данных для хранения всех кликов для всех ссылок

Question

Я пытаюсь настроить систему, в которой ВСЕ ссылки, опубликованные пользователями и нажатые их подписчиками, хранятся в Redis таким образом, чтобы выполнялись следующие требования:

1. Возможность получить (например, 10%) большинство кликов по ссылкам за определенный период времени (может быть либо сегодня, на этой неделе, либо за все время, либо на заказ).

2. Возможность запрашивать всех пользователей, которые разместили одну и ту же ссылку.

3. Поскольку мы уже использовали много ключей, в идеале мы храним все это в одном ключе Redis.

4. Может кодировать значение в JSON, если необходимо.

Вот что я до сих пор придумал:

-Я использую один Redis Hash, каждый из которых равен одному часу, так что за один день этот хэш будет содержать 24 поля.

-В каждом поле я храню JSON, закодированный из массива в формате:

array("timestamp1" => array($url1, $url2, ...)
    , "timestamp2" => array($url3, $url4, ...)
    , ..., ...);

- Полная структура этого хэша:

[01/01/2010 00:00] => JSON(...),
[01/01/2010 01:00] => JSON(...),
....

Таким образом, я могу получить все клики по любому URL за любой период времени.

Однако я не могу использовать этот хэш для получения всех пользователей, разместивших URL.

Вопрос: есть ли лучший способ сделать это?

Обновлено 07/30/2011 : в настоящее время я храню минуты, часы, дни, недели, месяцы и годы в одном хеше.

Итак, один щелчок сохраняется во многих полях одновременно: - в поле для минуты (формат YmdHi) - в поле для часа (формат YmdH) - в поле для дня (формат Ymd) - в поле на неделю (формат YW) - в поле за месяц (формат Ym) - в поле для года (формат Y).

Таким образом, пытаясь получить конкретный таймфрейм, я мог получить доступ только к необходимым полям, не переключаясь по часам.

Например, если мне нужны клики с 26.07.2011 с 20:00 до 28.07.2011 в 02:00, мне нужно запросить только 7 полей: 1 поле для полного дня 27.07.2011, 4 поля для часов с 20:00 до 23:00 26.07, а затем еще 2 поля для часов с 00:00 до 01:00 07/28

Answer 1

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

Чтобы получить наибольшее количество нажатийссылки, создайте отсортированный набор для каждого часа или дня, при этом значение - это ссылка, а оценка - количество кликов, заданное с помощью ZINCRBY.Используйте ZCARD и ZREVRANGEBYSCORE, чтобы получить 10% лучших.Проще всего, если набор содержит все ссылки в системе, хотя есть стратегии, которые можно использовать для удаления менее популярных элементов из набора, если это необходимо.

Чтобы все пользователи разместили ссылку, сохраните набор пользователей.за каждую ссылку.Это можно сделать с помощью JSON и ключа или хеша, в которых хранятся подробности для ссылки, но набор упрощает обновление и запросы.

Answer 2

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