あなたがリストした 2 つのアプローチ (SQL を使用するか、クライアントでデシリアライズとフィルタリングを使用する) の代わりに、本質的に Redis インデックスである少し異なるアプローチを提案したいと思います。
オブジェクトのキー名が obj1、obj2...objn であり、attribute1 の値が val1、val2...valm であると仮定すると、attribute1 の各値 x に対して、 のようなキー名を持つ Redis セットが作成されますattribute1:valx:index
。セットのメンバーは、attribute1=valx を持つオブジェクトのキー名になります。これを実現するには、次のことを確認してください。
- attribute1 の値が valx の objy を作成するとき
objy
に、キーに追加しattribute1:valx:index
ます。
- objy の attribute1 を valx から valz に更新する場合は、 から削除
objy
しattribute1:valx:index
て に追加しattribute1:valz:index
ます。
- attribute1=valx で objy を削除する場合、 から削除
objy
しattribute1:valx:index
ます。
- 必要に応じて、アプリにとって重要な場合は、上記がアトミックに (つまり、Lua または WATCH/MULTI/EXEC ブロックで) 発生する必要があります。
これらのポイントは、インデックスを維持するために必要なものです。attribute1:valx:index
インデックスを使用するには、attribute1=valx でフィルター処理されたオブジェクトを検索するときにセットのメンバー (SMEMBERS など) をフェッチし、キー名 ( などobjy
) を介して実際のオブジェクトをフェッチします。別の方法として、SORT .. GET (例: SORT attribute1:valx:index GET obj*
) を使用することも、1 つのコマンドだけを使用して実行する別の方法です。
attribute2 についても同じことを繰り返します。いくつかの追加ポイント:
- Redis のハッシュを使用してオブジェクト (HSET objy attribute1 valx など) を保存し、シリアル化のオーバーヘッドを節約し、Redis での値の操作を容易にすることを検討してください。
- 上記の単純なインデックスは、さらに拡張することができます。より複雑なフィルタリング オプションについては、SUNION、SDIFF、SINTER などのセット操作を使用することを検討してください。