Your welcome and one other thing that I forgot to mention is that: 8. I don't store KEY values as property values but instead use my own references since KEYs have the overhead of having the appid/namespace etc. in them and I prefer just storing what I need.
On Tue, May 10, 2011 at 9:35 AM, Richard Druce <[email protected]>wrote: > Thanks Stephen - great answer. > -- > m: +44 753 489 2926 > > > > On 10 May 2011 17:34, Stephen Johnson <[email protected]> wrote: > >> BTW, when I say no ssl support I'm referring to for the custom domain. >> What I mean is if there were support for custom domain ssl then appid could >> be really short and the user wouldn't even know what it is. Sorry for any >> confusion. >> >> >> On Tue, May 10, 2011 at 9:33 AM, Stephen Johnson >> <[email protected]>wrote: >> >>> Here's my list I go by: >>> 1. Only index properties you really need indexed. >>> 2. Make sure your composite indexes are really need. With zig-zag merge >>> join some composite indexes suggested by development server may not be >>> needed. >>> 3. Keep property names short. I use 3-4 character names but most are 3 >>> characters. >>> 4. Keep your entity kind names short. I use 2 character entity kind >>> names. >>> 5. If using namespaces, keep them short too. >>> 6. Keep you appid short but this is hard to do since no ssl support so >>> you may want your appspot.com domain to be more descriptive. I've gone >>> with a longer name myself. >>> 7. Keep down on the number of indexes need use your keys wisely, just >>> don't use an auto increment number or something like that which doesn't >>> provide you with anything, for example, if I have a User entity kind then >>> their key is their user id not an auto increment number where I also need an >>> additional property for User Id that I need to index. Then, if User, for >>> example, can rent items and I am going to store that in a Rental entity, >>> then I make the key be their User Id + the Date/Time of the rental so now I >>> can use the key to query for all of a User's rentals and they are ordered by >>> the Date/Time of the rental. Also, since single-property indexes also >>> contain the key in the index, I can query using the Key and the single >>> property index value so it's like I'm querying on multiple properties. In >>> addition, you can easily query on the key range, so let's say I want to >>> query on the rentals of a user for last month and that single-value >>> property. Again, no need for a composite index for this type of query. >>> >>> Right now, in my development app, I have the following data breakdown >>> according to the Datastore Statistics page: >>> Total # of entities: 6,475 >>> Size of all entities: 272 MB >>> Metadata: 1 MB >>> And according to Quota Details total datastore usage is .27 >>> >>> I've so far only had to have one composite index created but there is a >>> caveat to that. Since I am in dev. mode I don't have lots and lots of >>> entities and it is possible that the zig-zag merge join may fail me down the >>> road and I may need to add some additional composite indexes either because >>> I start getting Index Needed exceptions or because I find that with a >>> composite index I can get a speed boost over the zig-zag join. >>> >>> Now, my entities are larger than probably the average user's entities and >>> so if you have lots and lots of small entities then you index usage may go >>> up. >>> >>> I hope this helps. I'm sure others have lots of suggestions too. >>> Stephen >>> >>> >>> >>> >>> On Tue, May 10, 2011 at 2:31 AM, Richard Druce <[email protected]>wrote: >>> >>>> Hope everyone is having a good day. We've just outgrown the free data >>>> storage which Appengine kindly provides which is good but it looks like >>>> most >>>> of our data is indexes as only 200M of the 1.1 G used is actual data / >>>> metadata. Is this a normal ratio and are there any best practices we can >>>> use >>>> to limit the growth of the index / data ratio? >>>> >>>> Cheers, >>>> >>>> Richard >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Google App Engine" group. >>>> 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. >>>> >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> 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. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > 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. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. 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.
