Existing entity put in Google App Engine

Question

For some reason, I've been under the impression that writing an existing entity is just as expensive, if not more, than writing a new entity, so a lot of my code has focused on ways of breaking entities into smaller entities so that when I modify a property, it incurs less write costs. However, looking now at the documentation, it states that an existing entity put has the following costs:

1 write + 4 writes per modified indexed property value + 2 writes per modified composite index value

Before I go around changing the entire structure of my code, I want to be sure I understand the details. What exactly qualifies an index as "modified"? Say I have 4 indexed string properties and no composite indexes. To put this as a new entity would cost 10 writes (2 + 2(indexed properties)). Say I now modify one of these string properties and put it back. Would that cost 5 writes only (1 + 4 per modified index)? Am I missing anything? Are there any things I should take into consideration?

And what if I had 4 indexed properties and 1 non-indexed property, and I modify only the non-indexed property - this will only cost me 1 write to re-put?

Answer 1

All your suppositions are correct. It helps if you know what the writes are for: The 1 write is for the entity itself; the 2 writes per indexed property on create are for the ascending and descending single property indexes for each property, and the 4 writes per indexed property on update are to delete the old value and insert the new value into those ascending and descending indexes.

Answer 2

I just ran an experiment where I updated a model that has 3 indexed properties (one of those being a list), and 4 unindexed properties.

I used a mapreduce run to update one of the unindexed properties and Put() the entity.

If I did my math right, I've verified that it only took 1 write op per entity, even though there were 3 indexed properties (that weren't updated).

(my math might have been a bit iffy since I used mapreduce, and mapreduce itself issues a bunch of datastore writes. I did a separate experiment to estimate the # of mapreduce writes, so I've accounted for it).