I'm reading the posts about indices, watched Mr. Fuller's video on
composite indexes, and have some questions.

Plan to be a billing app, so according to a recent group posting from
ikai @google I'd get up to 200 indices, otherwise 100 if free app. But
ikai strongly suggests is that writes get "much, much" more intensive
with larger index counts, but I can't find any info to quantify what
this might mean, but is certainly is threatening enough.

Feeling a bit lost in it all. Appreciate any insights.

Here's a proxy of my setup.

Topics:
topic_ID_Index (also key value)
clientIndex
topicIndex
usernameIndex
tagIndex [list of up to 3 words]
dateCreatedIndex

Content:
content_ID_Index (also key value)
clientIndex
topicIndex
usernameIndex
tagIndex [list of up to 3 words]
dateCreatedIndex

Comments:
comment_ID_Index (also key value)
clientIndex
topicIndex
contentIndex
usernameIndex
dateCreatedIndex

The structure is:
>client is root
>>clients have topics
>>>topics have contents
>>>>content have comments

Tags are my only use of a list value index. Queries using tags can
only use one tag, so it is alway "tag = 'word'" never "tag in
['word1', 'word2']".

The main issue is that my application let's users build any
combination of filter items.

Every query will have clientIndex = 'value'. From there is could be
any combination of index combinations.

It all adds up of course (notably with a few DESC sort needs), and
right now I have 85 indices. Not all these 85 are related to models
which allow the "user built" indices. But the user built volumes do
account for the total.

Worst case right now is comments has 30 indices. Topics and Content
have about 20 indices each. However, I've not written a script yet to
ensure my index.yaml file has all the possible permutations. Just
built the yaml with lots of testing. So I'd guess these totals are 80%
of my final tally.

There are no dynamics in the indexed fields. Once a record is written,
the index values wont be updated again. (Well, there is an indexed
status field or every table/rec that may change, but very
infrequently).

Not a high volume site with respect to writes. Topics is lowest
volume. Lets say no more than "dozens per day". Content is next with
"hundreds per day". Comments is highest with "thousands per day".

Have I been a complete fool with this setup??

Are there any obvious means to optimize??

Thanks,
Steve

PS: I hope this all made sense. I'm worried about optimization, but
there is very little that I can really understand well enough to apply
given documentation available. (Have explored the "spin up" issue --
clearly a big issues for many, but no related documentation from G.
that I can find. Now indexing). As Mr. Fuller implied in his Google IO
video about composite indices, if a person can understand the tradeoff
for using composite indices, then he/she will be very valuable. I took
that comment, and my sense of my own understanding given review of
materials available, to mean that this stuff isn't easy, and Google
has not enough staffing in the GAE team to take it to the point where
their documentation will enable non-specialists to provide
substanative value. Unfortunate for GAE that is.

-- 
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.

Reply via email to