best data structure for a specific use case (microstream performance question)

[guykatz]

Hi all
assuming my root object has a collection of around 300 items give or take. this ballpark number will stay the same for the lifetime of the application.
assuming most of my actions are:

• take an item from the list based on its id (app logic id not ms id)
• deep copy it
• remove original item from collection and add the deep copied modified item
  my question is:
  should I use a list of items or a map of id->item?
  in both cases I need to store the collection after a modification not matter if its a map of a list.
  does MS care from a performance perspective?
  thanks!

[hg-ms]

Hi,
If you don’t need to maximize performance id suggest using a map if the api better fits your needs.
If performance matters using a simple list writes less data on a store. Here is why:
If you store a list, a long value for each entry in the list (the entries internal ObjectID) and all entries that are not jet persisted are written. In case of a map the keys need to be stored too in the same manner as the values.
In case of 300 entries this would be 2400 bytes + newObjects for a list and 4800 bytes + new Objects in case of a map.

One optimization you may do is combining the removing and adding in one store.

[useryq8]

Hi @hg-ms @fh-ms , following the previous reply, the size of microstream storage data is more smaller, the performance will be more higher? If I have multi domain entities, is it be more suitable to use multi microstream storage?

[hg-ms]

The performance depends on several factors. The storage size is important during the startup. After that the most important factor is the number of bytes that are persisted by a store operation. In case of (java) collections the size of the collection is directly related to the IO size.
One option to work with larger collection is to split a single collection into several smaller ones. E.g., instead of one collection that contains all data you may split it up into data per month, day, hour etc.