29

Estoy leyendo en Google App Engine grupos de muchos usuarios (Fig1, Fig2, Fig3) que no pueden determinar de dónde proviene el gran número de lecturas del Datastore en sus informes de facturación.
Como ya sabrá, Datastore reads tienen un límite de 50K operaciones/día, por encima de este presupuesto debe pagar.¿Cuántas lecturas de Datastore consumen cada una de las operaciones Fetch, Count y Query?

Operaciones de 50K suenan como una gran cantidad de recursos, pero desafortunadamente, parece que cada operación (consulta, obtención de entidad, recuento ...), oculta varias lecturas de Datastore.

¿Es posible saber a través de API o algún otro enfoque, cuántas lecturas de Datastore están ocultas detrás de las llamadas RPC.get, RPC.runquery comunes?

Appstats parece inútil en este caso, ya que proporciona solo los detalles de RPC y no el costo de las lecturas ocultas.

tener un modelo simple como esto:

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

y entidades en el almacén de datos, estoy interesado en el costo de este tipo de operaciones:

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

Creo que cada entidad devuelta es una lectura, si tiene una referencia, entonces la primera vez que accede es también una lectura. Tenga en cuenta que fetch (X) no significa que se devuelvan entidades X si el recuento es demasiado alto, entonces funcionaría en grandes cantidades y cada bulto contaría como lecturas de datos (tamaño total). No tengo idea de cómo funciona el recuento (X) con respecto a las lecturas de datos, debería contar como una sola lectura, pero es una ilusión. –

Respuesta

10

Ver http://code.google.com/appengine/docs/billing.html#Billable_Resource_Unit_Cost. Una consulta le cuesta 1 lectura más 1 lectura por cada entidad devuelta. "Devuelto" incluye entidades omitidas por desplazamiento o recuento. Así que es 1.001 lecturas para cada uno de estos:

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

Para éstos, el número de lecturas que se cobra es 1 más el número de entidades que coincidan con los filtros:

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

En lugar de utilizar el recuento se debería considerar almacenar el conteo en el almacén de datos, fragmentado si necesita actualizar el conteo más de una vez por segundo. http://code.google.com/appengine/articles/sharding_counters.html

Siempre que sea posible, debe utilizar cursores en lugar de un desplazamiento.

+0

No puedo ver ninguna referencia en el enlace publicado que costó 1 lectura por entidad devuelta, de hecho, no veo ninguna mención de las lecturas del almacén de datos. –

+0

Vaya, pegué el enlace equivocado. Lo arreglé ahora – ribrdb

3

Sólo para asegurarse de:

estoy casi seguro:

Example.all().count(10000) 

Éste utiliza las operaciones del almacén de datos pequeños (no hay necesidad de ir a buscar las entidades sólo pueden introducirse), así que esto contaría como 1 leer + 10,000 (max) operaciones pequeñas.

+0

Tiene razón: las "operaciones pequeñas" se ven afectadas con la expresión anterior, no con "operaciones de lectura". Acabo de comprobar eso en un proyecto de GAE. –

Cuestiones relacionadas