Evitar la contención en AppEngine - google-app-engine, contención

Estoy tratando de envolver mi cabeza alrededor de la contención y cómo se aplica a la pila de Application Engine.

Tengo un modelo que se construye como tal.

class Events(db.Model):
#Owner Identification Number
owner_id        = db.StringProperty(required=True)

#Authentication Token
auth_token      = db.StringProperty(required=True)

#generic, b, c, d, ...
driver          = db.StringProperty(required=True)

#Start Time and Date
tStart          = db.DateTimeProperty(auto_now=True)

#Define whether the event is active or inactive
active          = db.BooleanProperty(default=False)

#Payload store, this will store each payload block sent or pulled
payloads        = db.StringListProperty(indexed=False)

Este modelo tiene varios eventos, cada evento tieneun propietario y una carga útil, el propietario del evento escribirá las cargas útiles desde y hacia su evento y muchos otros leerán del evento, es una especie de pila de transcripción.

Mi pregunta es acerca de la contención: ¿Me afectará esto y, de ser así, cómo puedo reestructurarme para evitarlo?

Gracias.

Respuestas

1 para la respuesta № 1

No veo ningún problema con su modelo:

1. Events las entidades no pagarán ningún impuesto de contención como parecen, a juzgar por sus palabras y ejemplo, solo entidades raíz fuera de cualquier grupo de entidades.
2. Una actualización frecuente en una sola entidad puede causarpero no dudo que el propietario actualizará cualquier entidad más de una vez por segundo (1QPS es el umbral que debe tener en cuenta, por encima de que se encuentra en la zona de peligro).
3. Las operaciones de lectura del almacén de datos no causan problemas de contención.

---

2 para la respuesta № 2

Soy nuevo en Google App Engine también. así que, básicamente, evitar la contención es en realidad preguntar cómo aumentar el rendimiento de escritura. Las soluciones que podría pensar son:

1. Transacciones de sacrificio
2. Escrito por lotes en memcached
3. Contadores de fragmentos
4. Cola de tareas en segundo plano

https://developers.google.com/appengine/articles/sharding_counters

https://developers.google.com/appengine/articles/scaling/contention

¿Alguna otra idea? ¡Me gustaría saber también!

---

1 para la respuesta № 3

En su caso, la limitación que se aplica es la limitación de escritura / actualización de la entidad, que es 1 escritura / actualización por entidad (o grupo de entidades) por segundo.

No hay limitación para las lecturas.

Sigue siendo una buena idea utilizar memcache para las lecturas de caché para reducir el costo y mejorar el tiempo de respuesta. Si usa Python NDB, entonces el almacenamiento en caché está habilitado por defecto.

Solución: En mi humilde opinión, una buena solución para aumentar el rendimiento de escritura y al mismo tiempo tener lecturas son backends. Son (en su mayoría) siempre en instancias que puede utilizar como una memoria compartida. Por lo tanto, puede realizar escrituras por lotes (y vaciar a través de la cola de tareas) mientras tiene lecturas simultáneas.

Nota: Las instancias se reinician una vez al día, por lo queno puede tratarlos como almacenamiento confiable: puede usarlos como caché inteligente mientras se actualiza de forma asíncrona (a través de subprocesos de fondo o cola de tareas) en el almacén de datos.

---

1 para la respuesta № 4

En App Engine, cada instancia de un evento esleer / escrito como un objeto entero. Usted estaría preocupado por la disputa en cada instancia del evento. Si debe actualizar una sola instancia de Evento con frecuencia, es posible que deba preocuparse por la contención. Si actualiza diferentes instancias, entonces no hay nada de qué preocuparse.

No estoy seguro de a qué te refieres exactamente con contención. Puede estar refiriéndose a a) integridad transaccional o b) rendimiento de escritura limitado. No debería tener problemas con el rendimiento de lectura, aunque sí tiene el problema de la consistencia eventual con el cual lidiar.

a) Si debe leer los datos correctos después de actualizar una instancia de Evento, debe usar una solicitud get () del almacén de datos por clave. Una solicitud de consulta () puede devolver datos antiguos.

b) Si te preocupa el rendimiento de escritura,necesitas dividir de alguna manera tu entidad en múltiples entidades. Quizás pueda considerar tener varias entidades de carga útil para cada evento, algo como:

class Payload(db.Model):
event = db.ReferenceProperty(Events)
payload = db.StringProperty()

De esta manera usted puede escribir cada carga útil por separado,pero será un poco más caro ya que deben indexarse ​​y tendrá que consultarlos por evento para obtenerlos. Es posible que desee configurar el evento para que sea el antepasado, de modo que pueda utilizar las consultas de antepasados ​​para realizar consultas coherentes.

---