2

フォロワーシステムを実装するためにどのソリューションを選択するのか疑問に思っていますか?

MySQLではテーブルがあります

userID INT PRIMARY,
followID INT PRIMARY

Redis では、SET を使用して、UserID にすべての followID を追加します。

たとえば、2000 人のフォロワーがいて、すべてのフォロワーを一覧表示したい場合は、どうすれば速くなりますか? (約 100 万のエントリがあるテーブルで) 2 人のユーザーが相互にフォローしているかどうかを調べるには、何が速くなりますか?

どうもありがとうございました！

4

3 に答える 3

5

現代の基準では、1M のアイテムは何でもありません。どのようなデータベースや NoSQL システムでも、このようなボリュームで問題なく動作するため、最も使い慣れたものを選択する必要があります。

絶対的なパフォーマンスに関しては、Redis はこのユースケースで MySQL よりも高速です。理由は次のとおりです。

  • データセット全体がメモリ内にある
  • ハッシュ テーブルは btree よりも高速です
  • 解析または実行する SQL クエリがない

ただし、リレーショナル データベースは、Redis のようなキー/バリュー ストアよりもはるかに柔軟であることに注意してください。データへのすべてのアクセス パスを予測できる場合、Redis は優れたソリューションです。それ以外の場合は、従来のデータベースの方が適しています。

于 2013-01-22T14:36:14.557 に答える
2

私の意見では、MySQL を使用します。

決定を下す際に考慮すべき最大のポイントは次の 2 つです。

1)ユースケースについて考えたことはありますか?

フォロワーシステムを実装したいとおっしゃっていました。各ユーザーが持っているフォロワーのリストのみを表示する場合は、RedisSETで十分です。

しかし、「現在フォローしているユーザーのリスト」のリストを取得したい場合はどうでしょうか。Redis から簡単に掘り出すことはできませんよSETね? または、User-X が User-A をフォローしているかどうかを知りたい場合はどうでしょうか。User-A のフォロワーが 10,000 人だった場合、これも簡単ではないでしょうか。

さまざまなシーンでさまざまなタイプの結果をクエリする場合、MySQL ははるかに柔軟です。

2)性能差は本当に必要ですか?

ご存じのように、このような場合、Redis は MySQL よりも高速です。単純な Key-Value システムなので、MySQL のパフォーマンスを上回ります。次のようなパフォーマンス結果を確認します。

http://colinhowe.wordpress.com/2009/04/27/redis-vs-mysql/

http://ruturaj.net/redis-memcached-tokyo-tyrant-and-mysql-comparison/

しかし、Redis と MySQL のパフォーマンスの違いは、約 5,000 リクエスト/秒の後で初めて実際に現れ始めます。そうしないと、50 ミリ秒以上の差は見られないでしょう。

非常に大きなトラフィックが発生するまで、パフォーマンスの違いは問題になりません。

したがって、この 2 点を考慮すると、MySQL の方が適切な答えになります。

Redis は、次の場合にのみ有効です。

1) セット/リストの目的は具体的であり、将来的に柔軟性を必要としない

2) パフォーマンスの違いが実際にアーキテクチャに影響を与えると感じている。

于 2013-01-22T15:07:08.370 に答える
0

それは、データで何をしたいかによって異なります。あなたはいくつかの例を挙げましたが、製品が何をする必要があるかを本当に完全に定義しているようには聞こえません. 本当にやりたいことは、ユーザーがお互いをフォローしているかどうかを表示することだけですか? 次に、2 つの単純なクエリについて話しているだけなので、どちらでもかまいません。ただし、2 人のユーザーに共有するユーザーの共通点を表示したり、ユーザーのプロファイル データに基づいてデータから提案をしたりしたい場合はどうでしょう。次に、Redis には非常に迅速にセットの共通部分を簡単に提供する機能があるため、より興味深いものになります (

sadd friends:alex george paul bart
sadd friends:alice mary sarah bart
sinterstore friends:alex_alice friends:alex friends:alice

上記はmysqlでも実行できますが、パフォーマンスが低下することに注意してください。バッチジョブとして実行し、将来の使用のために結果を保存する可能性が高くなります。一方、世界最大の「友達」ネットワークである Facebook は、関係を保存するために mysql から始まったことを覚えておいてください。これらの関係のグラフは、適切なパフォーマンスを得るために、数千の memcached サーバーのストレージ用にバッチ処理され、大幅に非正規化されました。

次に、mysq1 や redis 以外のオプションを探している場合は、友人関係などのグラフ データに RDBMS システムを使用することについて、Michael Stonebaker (彼は Postgres と Ingres の作成を支援した) の発言を読むことをお勧めします。 http://gigaom.com/2011/07/07/facebook-trapped-in-mysql-fate-worse-than-death/ . もちろん、彼は新しい VoltDB を売り込もうとしていますが、これは興味深い考察の材料です。

したがって、予想される負荷 (2000 を捨てたのか、それとも本当にあなたが何をしているのか) の両方の観点から、アプリの要件を計画する必要があると思います (友人が誰であるかを表示するだけではないと思います)。処理することを期待) と機能と予算。次に、市場に出回っているさまざまなオプションの多くを実際に調べます。

于 2013-01-22T15:52:29.617 に答える