James, Yes, it seems like I misunderstood your original question. Our data store is distributed. Static assets are distributed via a CDN, however, dynamic requests that are handing by App Engine apps are routed to data centers serving App Engine requests. We don't currently route requests to the nearest data center, though if we did we'd probably do it by IP addresses and not email domain.
On Wed, Nov 11, 2009 at 6:57 AM, James H <james.hollier...@gmail.com> wrote: > > Ok, so if we have a single entity named Membership and a property > could be their email domain suffix like > Membership.domainSuffix=.com, .net, .uk, etc right? And querying on > this property would auto-create an Index on domainSuffix. How would > this alone help GAE to distribute the data such that .uk member data > is likely to be located on servers in the UK and so on? > > "distributing CRUD operations for you"...what is actually distributed > here Ikai? Do you mean the "processing" is distributed (ie the use of > app servers) or the data partitions are distributed near their > originating Users within google infrastructure. > > Virtually every google app has this same problem to solve and if there > is a Best Practice offered then as a whole the entire google > infrastructure will benefit from efficient implementations of this > most common requirement. Please advise. > > On Nov 10, 5:41 pm, "Ikai L (Google)" <ika...@google.com> wrote: > > James, > > > > The way I would probably do this would be to create an enum in the scope > of > > the Membership class representing a region and store it as an indexed > > property. The App Engine data store will take care of distributing the > CRUD > > operations of related data for you. You probably won't get much bang for > > your buck by creating different entities. By maintaining a single > Membership > > entity, you'll be able to more easily reuse related class. At its most > low > > level, the App Engine datastore is simply a distributed, type agnostic > > key-value store. App Engine recognizes entities by creating an index for > all > > of your application's Entities, and indexes are created for each property > by > > default. I would recommend creating a Data Access layer and doing the > > segmentation there. > > > > On Tue, Nov 10, 2009 at 1:48 PM, James H <james.hollier...@gmail.com> > wrote: > > > > > Is there a best practice entity design for storing Membership data > > > that targets a global market? Ideally, the Membership data is > > > partitioned geographically since a Membership in the U.S. is > > > independent of one in the U.K. and elsewhere, for example. The motive > > > is that operations (searches, inserts, updates, deletes) on U.S. data > > > need NOT involve data from the U.K. and elsewhere. Can GAE > > > transparently provide this based on the design of a single Membership > > > Entity or do you have to create separate Entities for each region in > > > your design such as MembershipUS, MembershipUK, etc? > > > > -- > > Ikai Lan > > Developer Programs Engineer, Google App Engine > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > To post to this group, send email to > google-appengine-java@googlegroups.com > To unsubscribe from this group, send email to > google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en > -~----------~----~----~----~------~----~------~--~--- > > -- Ikai Lan Developer Programs Engineer, Google App Engine -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=.
