-1

In an application that I am currently working on, we need to ensure uniqueness with respect to the tuple of three properties in a specific kind. As such when creating a new entity, we need to ensure that no entity of that kind with the given tuple exists.

My naïve approach to this problem, was to create a simple query that filters on equality based on the three fields. If an entity with the given fields was found, the operation would abort, otherwise a new entity with those fields and other related data would be inserted. However, when trying to insert many entities in parallel, transaction contention would arise.

However, as soon as I added a composite index of those three properties, no contention occurs. I changed nothing in the code, I merely added a composite index for those fields.

I have been digging through all the documentation and searched around for anyone who has had a similar issue, but nobody has ever mentioned this "workaround".

Have I missed something? Perhaps discovered something? Or this is expected behavior; are the built-in indices not enough?

muffe
  • 47
  • 7

1 Answers1

0

The main document you'd want to look at is https://cloud.google.com/datastore/docs/concepts/optimize-indexes .

In your case it looks like your merge join ends up locking a number of rows while looking for no-match. However, with the composite index you are only looking up the index entry needed for your query. Thus there is less contention with the composite index vs using a merge join for the query.

Jim Morrison
  • 2,784
  • 1
  • 7
  • 11
  • Thank you for the quick response. I wish it was more clearly stated, perhaps as a benefit of composite indices in the comparison at the bottom of the page. Unless I have a missed something on the docs page. – muffe Sep 16 '21 at 06:19
  • Additional follow-up. What would be the expected result if I were to use ancestors (by having each property as a part of the key) instead of composite indices w.r.t. locking and contentions. Would the performance be equivalent or better than composite indices? – muffe Sep 19 '21 at 08:51
  • The contention would be the same, but your performance should be better as you are (a) indexing fewer fields, and (b) you can do a lookup based on the primary key. – Jim Morrison Sep 20 '21 at 14:29