KVM - Storing Objects as multi-values

[surbhi_nijhara]

Performance-wise ,is it recommended to store objects as multiple values for a single key in a KVM, ? where Value: [ { color: "red", code: "#f00" }, { color: "green", code: "#0f0" }, { color: "blue", code: "#00f" }]

Also, is there a limit on the number of multi-values?

[Former Community Member]

Hi @Surbhi just trying to understand as why you would want to store it like this, doesn't that put the onus on some logic (that has to be written) to sift through the entries to figure out the code value for lets say "blue" color (if the values list is long, the code would have to iterate through all of them to get the code for the last color in the list - worst case. Unless you store them in a specific order [& you know the order at all times] you could use indexes to retrieve a specific entry out of multiple entries). The size of the collection could have some performance impact potentially if it grows to a huge size.

So that means one lookup on the KVM + some processing on the entries to extract the code value. It seems like flattening it out to one entry per color may make your proxy/code more elegant, you will most likely have a single lookup operation. Don't believe there is any theoretical limit to number of entries in a single key.

[akoo · Accepted solution]

Hi @Surbhi, consider using a composite key made of multiple parameters. E.g.,

...
<Key>
  <Parameter ref="key1"><Parameter>
  <Parameter ref="color"><Parameter>
</Key>
...

As Prithpal mentioned, this not only eliminates need to sort through your object at retrieval time, but this also reduces the size of your KVM entry since you don't need to store a structure, itself. More details can be found here.

As for limit, there is no known limit on number of values for a given key.

Edit: I clarified the sample. I'm not sure what your key is in your question, so I substituted with 'key1' in the example I provided.

[surbhi_nijhara]

Thanks @Prithpal and @Alex- I am of same understanding but did want to hear out. I have a case similar to a situation where I have pre-defined colorProfiles where the colors indicate different codes for different profiles. So in profile1, while color red has code #f00, in profile2 color red has a code #ff0 for example. Same applies to more colors in a profile.

So I defined key='profile name' and the value = {color name,code} array. The size of profile and value sets of each is small for now. However I was concerned if it grows, and hence the question.

I did liked the composite key idea, where I can see defining my key as composition of profile1 and color, with value as code. However while I understand that the extra processing of finding the right element in worst case would be diminished, the size of KVM would increase.

I would now have more number of key=(profile+color name) and Value=(color code) pairs against key=(profile name) and Value = ([color name1,code}, {color name2, code2} ,{...}]).

This post

https://community.apigee.com/articles/1396/apigee-developer-heres-the-stuff-you-should-know.html

suggests to avoid using larger KVMS as entire map is looked up even on accessing a single entry.

Your comments?

[akoo]

Good question @surbhi. In either situation (larger value or more keys), you still have a large map that is retrieved. But the intent is that in the future, only the keys or subset of keys that are needed are retrieved. This is where a composite key design will work more efficiently, and so as a point of preparing for upcoming KVM changes, composite keys will be a superior design.

[surbhi_nijhara]

Sure Thanks again.

[#7]

Hi @Surbhi,

Fully in agreement on composite key approach. Some additional points:

1. Though there is no limit on the number of values, there is a limit of maximum size (15MB) of a single KVM.

2. Given scenario comes under configuration scenario so, I don't think, size will grow. In case if it happens, different KeyValueMap may be created e.g. one KVM for each profile.

3. Consider expiry time (ExpiryTimeInSecs) configuration if this KVM won't be used frequently.

Cheers, Rajesh Doda