I have an entity Account which Contain mainly two groups of information.
Account {
a1 // Group 1 rarely change
a2
a3
a4
...
b1 // Group 2 change frequently
b2
b3
b4
...
}
First group is general info which will not update too frequent but group two will be changing frequently.
I wonder if I should extract Group 2 into another entity and store the key in Account so when I update group 2, I only need to put() the data of group 2.
My concern is, almost all operation to server would mostly require data from both group 1+2. If I split Account into 2, I need to do two get() to retrieve both data.
I know that read form data store is much inexpensive than write. But splitting the entity don't reduce the call to put(). In this case, I don't know if I should focus performance on put() or get().
Thanks
If the data in group 1 doesn't change, indexes don't get updated, so there's no monetary cost involved with updating them, while there is a cost to doing the second fetch.
You always need all the data so it doesn't make sense for you to split them.
The benefit you would get from splitting would be in performance. Fetching/putting a small entity takes less time than a big entity. So, for example, if Group 1 was really big (as in total size in bytes) and you didn't need the data, you could improve your performance by only fetching/putting an entity with Group 2. This doesn't sound like your scenario.
If say group 1 was 500KB, I'd consider splitting it. Although if you have to fetch group 1 all the time anyways, that nullifies the benefit.