We have a situation where a single user data set has multiple "aliases" associated with it (e.g name, E164, SIP address etc).
What would be a good design to take care of this ?
In other k/v implementations we basically have two maps. One map that maps from different aliases to a "storage id",
and the other map mapping this storage id to the actual data. When we read we basically look at the 'type' of key that is used
to read. If its of the 'storage' type we read directly from the data map, otherwise (e.g E164) we'll have to resolve it using the id map.
I saw something about major key paths etc, but I didn't get the feeling this would fit us well (or would it).
Does NoSQL have anything built in for these scenarios, or do I need to model this somehow ?
Ideas, comments and questions are more than welcome !
The major-minor key concept does not seem to help your scenario.
The major key will determine which shard gets the key-value pair.
A minor key will just make sure things associated with the same major key are kept in that same shard and can therefore be used not only for single value lookups, but also efficient grouped transactional operations and range type of queries.
So, you need to model it.
It is quite common to denormalize data within a key-value store. I guess the question is whether or not you are going to change the user data set or it is fairly static.
If it is static, seems that each of your alias's are going to be unique, so you can just use them as multiple keys pointing to a denormalized value set i.e. each unique key gets the same value, it takes a little extra disk space, but will provide best latency look up.
If you expect the data set to change a lot, it becomes a pain to update the denormalized value under all keys, so you may want to have that 1 level of indirection, your alias to key map.