Redis Twitter-like Follow/Unfollow Design Pattern

Question

Предположим, мы дублируем функцию Twitter. Насколько я могу судить, все теперь согласны на следующий дизайн, используя Redis.

Все твиты с последующим джо хранятся в отсортированном наборе «сс: Джо» с ключом = tweet_id, оценка = tweet_timestamp

Итак, когда Джо следует LadyGaga, чириканье LadyGaga добавляются в «сс: Джо», так это так хорошо.

Вопрос: как удалить твиты ladygaga из «ss: joe», когда joe unfollows ladygaga?

Итерация через каждый твист «ss: joe» и удаление тех, которые принадлежат к дамегаге.

Лучшее, что я могу придумать, это сохранить еще один сортированный набор для каждого пользователя, который хранит свои собственные твиты, поэтому у ladygaga будет свой отсортированный набор «tweets: ladygaga» с ключом = tweet_id, score = tweet_timestamp, затем мы можем выбрать Ледигага Tweets от ZINTERSTORE "ss: joe" и "tweets: ladygaga".

Есть ли лучшее решение?

Answer 1

Существует еще большая проблема для этого дизайна. Хранение tweet_id s в ss:joe означает, что система не может составлять gaga, создавая новый чириканье (или удаляя его, если это поддерживается) без изменения ss:joe. Теперь представьте, что у вас несколько сотен знаменитостей с 50 000 последователей каждый, и каждый из них пишет дюжину твитов в день. Это много вложений в множество наборов, которые вы также не можете легко распределить. И, это много повторяющихся данных (помните, что redis - это база данных только для RAM, и, хотя операционная система дешевле, она все еще не близка к «неограниченному»). EDIT: И для обновления записей следящих, вам также нужно знать последователей (поскольку повторение каждого пользователя на каждом новом написанном твите вряд ли является вариантом). Поэтому вам нужно также поддерживать список обратных ссылок.

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

Это потребует дополнительного запроса за последующим лицо, чтобы получить идентификаторы ЧИРИКНУТЬ, но это уменьшит отмене подписки для удаления одного значения из набора, и он будет держать все обновляется автоматически по мере создания новых твитов.

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