Eventually consistent datastore gets make get by key operations faster.
Queries should perform the same, but better in failure scenarios in high
replication.
As far as things going out of date goes: that's just the technology world
for you. Every API or service provider in the world will do their best to
keep things up to date, but unless you're doing legacy COBOL maintenance,
there's always going to bits where people will say, "Oh, by the way, don't
use that way anymore. Use this new way instead." The high replication
datastore didn't exist when Dan wrote that book. Also, you should know how
the book writing cycle works: a writer works with a publisher, then writes
the book over the next year or two. During that time, the publisher markets
the book, and the writer furiously tries to keep it up to date, knowing that
chances are good there are bits that will be obsolete and his initial plan
has to change. I don't know off the top of my head if Dan is planning on
releasing a new version of his book or not. The first edition was printed in
November 2009. In general, Dan's advice is correct: use get-by-key as much
as possible, and any update to the book will likely include a section about
high replication.
--
Ikai Lan
Developer Programs Engineer, Google App Engine
plus.ikailan.com | twitter.com/ikai
On Thu, Aug 18, 2011 at 3:52 PM, thstart <thst...@gmail.com> wrote:
> >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 google-appengine@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
