which is the best way to use a java object as key in Redis?
I was thinking of serializing the object (through FST or KRYO).
Is this the best way?
Should i use an hash?
Thanks
I don't think it's a good idea using object byte array as the key, because Redis has key size limited, and calculate byte array hash code as the real key, so you should using the unique key stand for the object, smaller key size can improve performance.
Related
What's the practical difference between keeping data in multiple hashes (HSET foo oof 1, HSET bar rab 2) and using plain keys in a hierarchy (SET foo:oof 1, SET bar:rab 2)?
According to the manual, you'd use hashes to represent a single object.
Also, it's not that efficient to iterate over Redis keys, so if you need to get all the data from a single object, HGETALL is your friend, not a KEYS thing:10:*/multiget fiasco.
However, you can't e.g. set expiry for only one key of a hash, so if you need that functionality, you'll want to use regular keys.
I'm not sure if this can be done in Redis, but is there a way to look up the key by value in redis?
Suppose that I have a redis DB where the key is the symptom_id and the value is the symptom_name.
For exammple:
{
"symptom_id:1": "headache",
"symptom_id:2": "stomach pain",
"symptom_id:3": "cough"
}
Let's say I want to find the symptom ID of "cough". Is it possible to do so? If so, how do I go about doing it?
If you have to do it regularly, use secondary index, as #for_stack suggested. This is a fast and proper way.
If you need an ad-hoc solution, you can iterate keys by pattern with SCAN symptom_id:* ... (see scan), and look at their values.
We are storing path's to data in redis as following:
KEY: `/pathOfUniqueAsset/v11/`
VALUE: `/disk1/pathOfUniqueAsset/path/v/11/`.
As you can see, the v which stands for version, will grow over time. I was wondering if there is a way to store flavors/versions of a key/value pair?
You can use a Hash instead of a String, as the key's value type. In the Hash, you can have a field per version/flavor and have the value as the associated path.
E.g.:
HSET /pathOfUniqueAsset v11 /disk1/pathOfUniqueAsset/path/v/11/
What are you trying to achieve? Do you need to keep older versions? If not, overwrite the key. If yes, what would 'version' of the key give you? You already know your version from the key. If you arrange your keys as pathOfUniqueAsset.v11, you can later issue KEYS pathOfUniqueAsset.* (or better SCAN) to get all versions. This way you can set EXPIRE individually. If you'll use HSET like #ItamarHaber suggests you can only delete values manually, but iterating a set is much faster than KEYS lookup (EDIT: actually, it depends on some factors, mostly the amount of other keys).
If you instead want a list of assets for each version kept together, you can use dedicated set of all keys associated to this version. Like
SET /pathOfUniqueAsset/v1 ...
HSET assets.v1 pathOfUniqueAsset /pathOfUniqueAsset/v1
I am still new to Redis and wondering if it would be possible to have a HASH of LIST.
Then I could do for example LPOP HASH myKey where the hash set holds each list's key and the lists contains data that I want to manipulate.
Redis does not provide nested data structures, therefore a List of Hashes isn't possible. A Redis List can only contain strings, but what you could do is store the Hashes' key names in a List and do HGET after popping.
I have to define an integer primary key for a table that I am trying to build for a web app. I can define it as a normal integer or make it autoIncrement. Both are OK for my table and I know that autoIncrement saves me the trouble of explicitly setting the value.
But, are there any advantages other than this? Or are there any disadvantages of using normal integer? For some reason I am inclined to use normal integer as the values can be random and hard to predict (being for a webapp). But I am worried if this causes performance issues while querying the table.
PS: This question is not about integer vs GUIDs. Just AutoIncrement vs Normal Int.
If you use a normal integer key, you assume the burden of generating unique keys. If there is more than one thread/process adding records to the table, this is non-trivial.
Another consideration is performance: the database engine can generate auto-incremented keys much faster than user-level code can come up with unique keys.
The upside is that you could make the keys hard(er) to predict. Whether this actually buys you anything is open to debate.