2

Twitterのフォロー機能を複製しているとします。私の知る限り、Redisを使用した次の設計に誰もが同意するようになりました。

joeが後に続くすべてのツイートは、key = tweet_id、score = tweet_timestampのソートされたセット「ss：joe」に保存されます。

つまり、joeがladygagaをフォローすると、ladygagaのツイートが「ss：joe」に追加されます。

問題は、joeがladygagaのフォローを解除したときに、「ss：joe」からladygagaのツイートを削除するにはどうすればよいですか？

すべての「ss：joe」ツイートを繰り返して、ladygagaに属するものを削除します。

私が考えることができる最善の方法は、自分のツイートを保存するすべてのユーザーに対して別の並べ替えられたセットを維持することです。したがって、ladygagaはkey = tweet_id、score = tweet_timestampの並べ替えられたセット「tweets：ladygaga」を持ち、ZINTERSTOREでladygagaのツイートを選択できます。 「ss：joe」と「tweets：ladygaga」。

より良い解決策はありますか？

4

1 に答える 1

3

この設計にはさらに大きな問題があります。tweet_idsを格納するということは、システムが変更せずに新しいツイートを作成する（またはサポートされている場合は削除する）ことをss:joe考慮できないことを意味します。ここで、それぞれ50,000人のフォロワーを持つ数百人のセレブがいて、それぞれが1日に12件のツイートを書いていると想像してみてください。それはたくさんのセットへのたくさんの挿入物であり、あなたも簡単に配布することはできません。そして、それは多くの重複データです（redisはRAMのみのデータベースであり、RAMは安くなりますが、それでも「無制限」にはほど遠いことを思い出してください）。編集：そしてフォロワーレコードを更新するには、フォロワーも知る必要があります（新しく書かれたすべてのツイートですべてのユーザーを繰り返すことはほとんどオプションではないため）。したがって、バックリンクのリストも維持する必要があります。gagass:joe

別の設計では、フォローしている人のユーザーIDをセット（または、必要に応じてソートされたセット）に保存して、ユーザーが注文をシャッフルできるようにします。さらに、各人は、すべてのツイートID（日付でソート）を含むソートされたセットを持っています。

これには、ツイートIDを取得するためにフォローしている人ごとに追加のクエリが必要になりますが、フォロー解除がセットから1つの値を削除することを減らし、新しいツイートが作成されたときに全員が自動的に更新されます。

ルックアップは挿入/削除（リバランスまたは再ハッシュが必要になる場合があります）よりもコストがかからないため、数十人をフォローしている場合でも、これらの余分なクエリは、より頻繁な更新ほど問題にはなりません。
さらに、ルックアップは複製されたスレーブのネットワーク上で実際に発生する可能性があります（新しいツイートがすべての人に表示される前に、1〜2秒が経過する可能性がありますが、誰が気にしますか？それは無限に拡大します）。

于 2012-06-05T11:20:38.223 に答える