Google I/O 2008 - Building Scalable Web Apps with App Engine
Why Stack Overflow recommends it
Stack Overflow users link it when answering App Engine datastore design and performance questions, as the go-to talk on denormalizing data, caching and scaling.
Recommended by 3 people across 3 different months, 2010 to 2013.
What it is
A 2008 Google I/O session by Brett Slatkin of Google on building scalable web apps with App Engine's Python runtime. It covers caching, dynamic module loading, App Engine idioms and strategies for scaling to millions of users.
What people said
Recommends fceruti · 2011-10 · Stack Overflow · on “Datastore design - How to simulate efficient joins”
Theres third possibility which doesn't make a compromise. You make Score a child of Article , and keep the sumOfScore in Article . For sorting purposes, this field will come in handy. As this two classes are from the same entity group, you can create a Score and update the Article in a transaction. You could even double check by querying all the Score who's parent is a given Article . The problem with this approach, is that you can only update an entity 5 times per second. If you think you'll have much more activity than that (remember, it's just a limitation on a single entity not the entier table), you should check out sharded counter tutorial [LINK] or see the google io's video [this video] ex
Recommends stun · 2013-04 · Stack Overflow · on “How to define Key Name in Datastore GAE Python?”
Quick Advice Working on project, which need to have input form to extend its content(name,email,phone..) with defined Key Name in Datastore, preferably to increase in define way . Took me like a minute or two trying to understand what you are saying. Don't rush typing out what you want to ask without thinking. If you want a well thought out answer from other people, try to ask the question clearly. My Questions to You Why do you think you need to define the Key Name manually ? What benefit do you think you are getting? From what I can infer, you seem like you don't understand the basics of the GAE HRD Datastore. If you don't understand the HRD datastore, you can't code effectively on GAE. My
Recommends stun · 2013-04 · Stack Overflow · on “Improving database record retrieval throughput with appengine”
I will second what @illia-frenkel said above. Maybe consider designing your application to include using `memcache` and being cacheable? Since you're not providing any more info, I'd advise watching **App Engine Datastore Under the Covers** [LINK] and **Building Scalable Web Apps with App Engine** [this video] from Google IO 2008. Also read Jeff Dean's [LINK]
Recommends nanospeck · 2013-12 · Stack Overflow · on “designing a database in google app engine”
There aren't much books written about designing database for google app engine. The most helpful resource I found about was the Bret Saltkin's talks in the Google I/O [this video] . This talk explains some of the magical properties of app engine datastore. I've written a detailed blog about data modeling in google app engine here [LINK] .
Cites Jason Hall · 2010-06 · Stack Overflow · on “Database design - google app engine”
As you've noticed, this design doesn't scale. It requires 4 (!!!) DB queries to render the page. That's 3 too many :) The prevailing notion of working with the App Engine Datastore is that you want to do as much work as you possibly can when something is written, so that almost nothing needs to be done when something is retrieved and rendered. You presumably write the data very few times, compared to how many times it's rendered. Normalization is similarly something that you seem to be striving for. The Datastore doesn't place any value in normalization -- it may mean less data incongruity, but it also means reading data is muuuuuch slower (4 reads?!!). Since your data is read much more ofte