counting missed datastore read operations

88 views
Skip to first unread message

John Tantalo

unread,
Nov 21, 2011, 5:31:08 PM11/21/11
to google-a...@googlegroups.com
I have an index on one field of my model which I use for exact-match lookups (i.e., no range queries).

When a query matches, I expect to get the records which match the value. When it doesn't match (when it "missed"), I expect to get no records.

I believe the "missed" cases count towards my datastore read operations quota, even though no datastore read operations were performed.

My intuition is that the index and the datastore are two separate things, and read of the index should be free. In other words, read operations which do not return any records should be free and not count towards the datastore read quota.

Am I way off?

Brandon Wirtz

unread,
Nov 21, 2011, 5:35:35 PM11/21/11
to google-a...@googlegroups.com

Yes.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/FLFbvLe795cJ.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

Brandon Wirtz

unread,
Nov 21, 2011, 5:38:41 PM11/21/11
to google-a...@googlegroups.com

Oh, I should probably explain why.

 

What is the cost of doing a Google Search for the nonsensical pattern “Brandonsawesomesaucequery” ?

What is the cost of doing a Google search for “Brandon”

In either case you do a read to see if the thing exists.  And you still have to check against all the patterns to see if you have a match.

So the query is the same “cost”

Return Each row is a separate cost.

John Tantalo

unread,
Nov 21, 2011, 6:08:20 PM11/21/11
to google-a...@googlegroups.com
I don't doubt you need a read in each case. My point is about what the read is for, and how the quota are calculated.

App Engine has a quota for,
  • Datastore Write Operations
  • Datastore Read Operations
  • Datastore Index Write Ops
Now, I understand that the indexes may be part of the datastore, but if index write operations are separate from datastore write operations, why aren't the read operations also separated? Clearly they are separate things, but it seems they are combine under one quota.

My only question is why, and whether that makes sense.

For instance, it should be much cheaper to check if a query has results (a index read) than to return those results (a datastore read), so wouldn't it make more sense to have separate quotas?

Jeff Schnitzer

unread,
Nov 21, 2011, 8:38:04 PM11/21/11
to google-a...@googlegroups.com
My WAG is that a query which returns no results will cost you 1 "minor operation" (like a key-only query or a count step).

Jeff

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/jYkQSgzJzeEJ.

To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.



--
I am the 20%

Brian Quinlan

unread,
Nov 21, 2011, 8:54:37 PM11/21/11
to google-a...@googlegroups.com
Hi John,

A query will always cost you at least one datastore read.

This page shows how various high-level operations translate into the quota used:
http://code.google.com/appengine/docs/billing.html#Billable_Resource_Unit_Cost

Cheers,
Brian


> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/google-appengine/-/FLFbvLe795cJ.

John Tantalo

unread,
Nov 21, 2011, 11:07:57 PM11/21/11
to google-a...@googlegroups.com
Thanks Brian! This is exactly what I was looking for.
Reply all
Reply to author
Forward
0 new messages