29

Sto leggendo su Google App Engine raggruppa molti utenti (Fig1, Fig2, Fig3) che non riescono a capire da dove proviene l'elevato numero di dati Datastore nei loro rapporti di fatturazione.
Come forse sapete, lo Datastore reads ha un limite di 50.000 ore/giorno, oltre questo budget è necessario pagare.Quante letture di Datastore consumano ogni operazione di recupero, conteggio e query?

Le operazioni 50 K sembrano molte risorse, ma sfortunatamente sembra che ogni operazione (Query, Entity fetch, Count ..), nasconda diverse letture di Datastore.

È possibile conoscere tramite API o qualche altro approccio, quante letture di Datastore sono nascoste dietro le comuni chiamate RPC.get, RPC.runquery?

Appstats sembra inutile in questo caso perché fornisce solo i dettagli RPC e non il costo nascosto delle letture.

Avere un semplice modello come questo:

class Example(db.Model): 
    foo = db.StringProperty()  
    bars= db.ListProperty(str) 

e entità del datastore, mi interessa il costo di questo tipo di operazioni:

items_count = Example.all(keys_only = True).filter('bars=','spam').count() 

items_count = Example.all().count(10000) 

items = Example.all().fetch(10000) 

items = Example.all().filter('bars=','spam').filter('bars=','fu').fetch(10000) 

items = Example.all().fetch(10000, offset=500) 

items = Example.all().filter('foo>=', filtr).filter('foo<', filtr+ u'\ufffd') 
+0

Penso che ogni entità restituita sia una lettura, se si dispone di un oggetto di riferimento, la prima volta che si accede è anche una lettura. Si noti che fetch (X) non significa che le entità X vengono restituite se il conteggio è troppo alto, quindi funzionerebbe in massa e ogni volume conterebbe come letture dei dati (dimensione complessiva). Non ho idea di come count (X) funzioni nel rispetto delle letture dei dati, dovrebbe essere considerato come una singola lettura ma è un pio desiderio. –

risposta

10

Vedi http://code.google.com/appengine/docs/billing.html#Billable_Resource_Unit_Cost. Una query costa 1 lettura più 1 lettura per ogni entità restituita. "Restituito" include le entità ignorate da offset o conteggio. Quindi è 1001 letture per ciascuno di essi:

Example.all(keys_only = True).filter('bars=','spam').count() 
Example.all().count(1000) 
Example.all().fetch(1000) 
Example.all().fetch(1000, offset=500) 

Per questi, il numero di letture a carico è 1 più il numero di soggetti che corrispondono ai filtri:

Example.all().filter('bars=','spam').filter('bars=','fu').fetch() 
Example.all().filter('foo>=', filtr).filter('foo<', filtr+ u'\ufffd').fetch() 

Invece di usare conteggio voi considerare la possibilità di memorizzare il conteggio nel datastore, se necessario è necessario aggiornare il conteggio più di una volta al secondo. http://code.google.com/appengine/articles/sharding_counters.html

Se possibile, è necessario utilizzare i cursori anziché uno scostamento.

+0

Non riesco a vedere alcun riferimento nel link che hai postato che costa 1 lettura per entità restituita, infatti non vedo alcuna menzione delle letture del datastore. –

+0

Oops, ho incollato il link sbagliato. L'ho risolto ora – ribrdb

3

Giusto per essere sicuro:

Sono quasi sicuro:

Example.all().count(10000) 

Questo si usa operazioni datastore piccoli (non c'è bisogno di prendere le entità, solo chiavi), quindi questo conterebbe come 1 leggi + 10.000 (max) piccole operazioni.

+0

Hai ragione - le "piccole operazioni" sono interessate dall'espressione sopra, non dalle "operazioni di lettura". Ho appena controllato che su un progetto GAE. –

Problemi correlati