3

古い MySQL ベースのユーザー管理システムを Redis に変換していますが、いくつかの問題が発生しました...

システムの基盤として HASH と SET の組み合わせを使用しています。

いくつかの疑似コード

let uid=incr user_id_counter

    hset joe@dom.com user user:uid
    hset user:uid email joe#dom.com
    hset user:uid gender m
    hset user:uid year_of_birth 1972
    hset user:uid fav_band acdc
    sadd maleUsers uid
    sadd born1972Users uid

この時点ですべてが順調で、たとえばsinterを使用して検索できます。

sinter maleUsers born1972
or
sinter femaleUsers born1980

これは、誕生の年ごとに別のセットを作成することを前提としています

sad bornXXXX uid

これは私が満足できるものですが、お気に入りのバンドをどのように処理しますか? 確かに、すべての可能なバンドのセットを作成しませんか?

最終的には、次のような詳細な検索ができるようにしたいと考えています。

sinter maleUsers born1980 genreRock genreMetal homeTownSydney

リレーショナル クエリを行うより洗練された方法はありますか?

4

2 に答える 2

3

私は Redis の大ファンです。しかし、あなたのアプローチはかなり間違っているのではないかと心配しています。ユーザー資格情報のプライマリ ストレージは引き続き従来の RDBMS にする必要があり、MySQL を使い続けることは優れた方法です。

NoSQL データベース、特に Redis は、他のことを行うことを意図しています。

Redis はメモリベースです。はい、すべてをハード ドライブに保持できますが、マシンが起動すると、ハード ドライブからメモリにすべてが読み込まれます。そして - ストレージ上限はマシンのメモリです。したがって、あまり多くのユーザーを期待しない限り、Redis をストレージの主要なソースとしてお勧めしません。ユーザーへのセカンダリ アクセス (たとえば、第 2 レベルのキャッシュ) には引き続き Redis を利用できますが、プライマリ ソースとしては利用できません。

ディスクベースの NoSQL データベース (MongoDB、CouchDB、Cassandra など) をユーザー データベースに使用できます。これは Redis よりも優れた選択肢ですが、それでも従来の RDBMS を強くお勧めします。最も重要なデータを、信頼できるトランザクション ベースのシステムに保持したいと考えています。

于 2013-02-16T11:07:54.910 に答える
0

しかし、お気に入りのバンドをどのように処理しますか? 確かに、すべての可能なバンドのセットを作成しませんか?

さて、これはまさにあなたがすべきことです。Redis では、このような関係は、バンドへの参照、ユーザー定義の一部、およびすべてのユーザーへの参照を含むバンドに関連付けられたセットによって表されます。

この関連付けは手動で維持する必要がありますが、MULTI/EXEC ブロックを活用して、並行環境でのデータの一貫性を保証できます。

リレーショナル クエリを行うより洗練された方法はありますか?

はい。Redis の代わりにリレーショナル データベースを使用します。リレーショナル クエリを探しているのであれば、RDBMS を使用してみませんか? MySQL の何が問題になっていますか?

于 2013-02-16T10:13:06.523 に答える