Dragos Strugar
Dragos Strugar

Reputation: 1644

Inappropriate Redis Database Design

I have a node.js API that is responsible for 3 things:

Details here

Since I'm new to Redis, I started the implementation like this:

  1. JSON.stringify the buyer and store it with SET
  2. Store all buyer's offers as ordered set (this is for the third endpoint, which requires the offer with the highest value) - this set contains string that represents the name of a hash
  3. Then, that hash stores strings that represent the names of sets that have certain values and a location which the user will be redirected to after these conditions have been fulfilled (buyer1_devices, buyer1_hours, etc.)

Now, here is the problem:

I need to get GET /route working. As described on GitHub page that I have provided, I have 3 parameters: a timestamp, devices, and states. I have to browse through all the sets and get the appropriate location to redirect a user to. The location is stored in a hash, but I have to browse through all the sets. Since this is probably a bad implementation, where did it all go wrong and to go about implementing this?

Thank you in advance

Upvotes: 2

Views: 203

Answers (1)

Itamar Haber
Itamar Haber

Reputation: 49942

The first rule of Redis: store the data just like you want to read it.

To answer the /route query you need "filteration" on two attributes of from the buyers' offers - state and device. There is more than one way to skin that cat, so here's one: use many Sorted Sets for the offers.

Each such offers Sorted Set key name could look like this: <device>:<state> (so the example offered in the git will be added to the key desktop:CA).

To query, use the route's arguments to compose your key's name, then proceed regularly to find the highest-scored offer and resolve the buyer's details in the Hash.

Now go get that job!

Upvotes: 2

Related Questions