>If you enable eventually consistent queries, a batch get by key in high
replication should perform as fast as in master/slave.
*is this related only to queries like:*
q = db.GqlQuery("SELECT * FROM Person " +
"WHERE last_name = :1 AND height < :2 " +
"ORDER BY height DESC",
"Smith", 72)
http://code.google.com/appengine/docs/python/datastore/queries.html
The Master/Slave Datastore and the High Replication
Datastore<http://code.google.com/appengine/docs/python/datastore/hr/> have
different guarantees when it comes to query consistency. By default:
- The Master/Slave datastore is strongly consistent for all queries.
- The High Replication datastore is strongly consistent by default* for
queries* within an entity
group.<http://code.google.com/appengine/docs/python/datastore/entities.html#Entity_Groups_and_Ancestor_Paths>
With
the High Replication Datastore, non-ancestor queries are always eventually
consistent.
*If that is the case I managed to get rid of queries - I don't use any any
queries, just working with lists and keys -
*
*it is parallel, fast, don't need indexes, etc. Bret Slatkin had very useful
presentations and found them to be very simple*
*and to work in practice.*
*
*
*By the way our customers don't know what technique I am using only thing
they care is to be fast and they are telling me*
*up to now they haven't used a web app with so much functionality to be so
fast. *
*
*
*I would say they to be fast is that I designed the database as separate
entity for each user - e.g. it scales with numbers of users*
*automatically. Very important is that I don;t use any queries, indexes,
etc. just lists of keys and for ... in construct for search,*
*also the keys and entities are composed in as many ways possible in advance
so when the user is searching for data it gets*
*it instantly because search is embedded in the keys. In Master/S**lave all
this worked in parallel and was extremely fast.*
*
*
*
*
>The practice you're citing from Brett is a few years old and predates high
replication; would you be willing to revisit it if I roped him into updating
it for high >replication?*
*
Yes this is true, but you have to admit this is the only useful information
on designing efficient data-store. There is *only one* serious book
explaining
how *AppEngine Datastore* is working and in this book you can read the same
recommendation like Brett Slatkin recommends. And the book
is a year old:
Programming Google App Engine
by Dan Sanderson
Copyright © *2010* Dan Sanderson.
Dan Sanderson is working at Google and explains everything extremely well
and I believe after so much time and efforts invested to understand how it
works and to successfully implement a very useful app with waiting customers
- *do I have to think a book and technique explained in 2010 is already
out-dated?*
>would you be willing to revisit it if I roped him into updating it for high
replication?
*I always want to know new techniques, so the quick answer is yes,
definitely. *
*
*
*You should also keep in mind that it is not a good business idea to
constantly revisit *
*and rewrite a perfectly working and tested code.*
*
*
*Best,*
*--Constantine*
*
*
--
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/-/BzQWzYVCk3UJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
