Explicación de las consideraciones de rendimiento de lectura/escritura en Google Datastore (GAE)?

Question

Estoy teniendo un momento muy difícil para entender la mecánica del Google App Engine Datastore.
Quiero entender la mecánica para poder construir mi base de datos de manera óptima para la base de datos.

Dado mi ejemplo a continuación, alguien me puede ayudar en:

1. estructura de la base de datos de manera óptima
2. entender el rendimiento de leer y escribir, dado que la estructura

Ejemplo:
Digamos que tengo baseball N cada uno tiene una ID única.
Me gustaría mantener un conteo diario de los jonrones golpeados por cada jugador (almacenando una propiedad de "jonrones diarios totales") y básicamente incrementarlo cuando se golpea un jonrón.
Por lo tanto, a medida que aumente el tiempo, me gustaría mostrar un gráfico de jonrones cada día para cada jugador de béisbol durante X años.

Player 1 
1/21/2011 - 2 homeruns 
1/22/2011 - 0 homeruns 
1/23/2011 - 1 homeruns 

Leer Requisito: Lea los últimos 5 años de datos diarios "homerun" para un determinado jugador?

Comentario Requisito: incrementar un recuento cuadrangular al día durante un determinado jugador de béisbol.

Me encantaría saber cómo estructurar los datos y también los mecanismos de lectura y escritura. ¿Escalará esta simple tarea de almacenamiento? Gracias a todos.

Answer 1

Me modelar sus necesidades con una relación uno-a-muchos así:

class Player(db.Model): 
    name = db.StringProperty() 

class DailyHomeruns(db.Model): 
    date = db.DateProperty() 
    counter = db.IntegerProperty() 
    player = db.ReferenceProperty(Player) 

para recuperar todos los DailyHomeruns de un determinado Player puede hacerlo de esta manera:

daily_homeruns = DailyHomeruns.all().filter('player =', player) 
            .filter('date >', date_start) 
            .filter('date <=', date_end) 
            .order('date') 

Leer Requisito:

Google App Engine consultas de rendimiento escalas con el tamaño del conjunto de resultados y no con el tamaño del conjunto de datos.

Esto significa que si su últimos 5 años HomeRuns consulta conjunto contiene en promedio de 800 entidades ^*, esta consulta realiza la misma si se busca en más de un millar de entidades o un millón de entidades.

Comentario Requisito:
escrituras son lentos en Google App Engine, pero su escenario parece bastante trivial y no veo cualquier posible problema de contención/tiempo de espera; después de todo, solo necesita actualizar en serie el DailyHomeruns incrementando el contador un pequeño número de veces por día.

Otros pensamientos:
Si es necesario calcular algunas estadísticas, por ejemplo, el número total de Homeruns de un determinado Player, ni siquiera pensar en utilizar GQL para este fin, ya que no proporciona ninguna función agregada à la SQL.
En su lugar, debe diseñar su base de datos por adelantado, definiendo un modelo para almacenar el recuento total de Homeruns por jugador.
Usando la API transactions, cada vez que incremente el DailyHomeruns necesitará incrementar la entidad TotalHomeruns para ese reproductor.

^{* He estimado 3 partidos por semana durante 52 semanas multiplicado por 5 años}

Answer 2

No hay una sola respuesta a esta pregunta. El almacén de datos es realmente de bajo nivel y depende de usted crear los índices correctos y preprocesar los datos para que puedan recuperarse más rápido. También, dependiendo de acceso concurrente a la misma entidad, que tendría que utilizar algo bastante creativo como http://code.google.com/appengine/articles/sharding_counters.html

te recomiendo ver a dos Google I O Sesiones/para empezar http://sites.google.com/site/io/under-the-covers-of-the-google-app-engine-datastore le da una visión de bajo nivel de cómo funciona todo y por qué estaban hechas de esta manera (abajo a cómo los sectores se escriben en el disco)

Entonces http://sites.google.com/site/io/building-scalable-web-applications-with-google-app-engine le mostrará cómo utilizar ese material bajo nivel en aplicaciones del mundo real.

Hay otra que presenta otras soluciones a problemas comunes http://www.google.com/events/io/2009/sessions/BuildingScalableComplexApps.html - es agradable abrir su mente a nuevos tipos de soluciones a las limitaciones del almacén de datos.