restricciones de transacciones del almacén de datos

Question

en mi aplicación de Google, cada vez que un usuario compra una cantidad de contratos, estos eventos se ejecutan (simplificado para mayor claridad):

• user.cash ha disminuido
• user.contracts aumenta en número
• contratos.current_price se actualiza.
• market.no_of_transactions se incrementa en 1.

en un rdms, estos se colocarían dentro de la misma transacción. Creo que el almacén de datos de Google no permite que entidades de más de un modelo estén en la misma transacción.

¿Cuál es el enfoque correcto para este problema? ¿Cómo puedo asegurarme de que si falla una escritura, todas las escrituras anteriores se revierten?

editar: obviamente he echado de menos grupos de entidades. Ahora agradecería más información sobre cómo se usan. Otro punto a aclarar es que Google dice " Solo use grupos de entidades cuando sean necesarios para las transacciones. Para otras relaciones entre entidades, use las propiedades ReferenceProperty y los valores clave, que se pueden usar en consultas " ;. ¿significa que tengo que definir tanto una propiedad de referencia (ya que necesito consultarlas) como una relación padre-hijo (para transacciones)?

edit 2: y finalmente, ¿cómo defino dos padres para una entidad si la entidad se está creando para establecer una relación n-n entre 2 padres?

Answer 1

Después de una investigación exhaustiva, descubrí que se ha desarrollado una capa de transacción distribuida que proporciona una solución a la restricción de grupo de entidad única en el país de los usuarios con la ayuda de algunas personas de Google. Pero hasta ahora, no se ha lanzado y solo está disponible en Java.

Answer 2

Permítanme agregar una cita de la Documentación del almacén de datos :

  

Una buena regla general para los grupos de entidades es que deberían ser   el tamaño del valor de un solo usuario   datos o más pequeños.

Podría crear una pseudo entidad raíz y poner todo debajo de esto. Luego, ejecuta todo en una transacción.

Answer 3

shanyu, mencionaste la capa de transacción distribuida que te permite operar de manera arbitraria en muchos grupos de entidades en una sola transacción. En realidad se ha lanzado , simplemente no se ha anunciado en voz alta. fue diseñado y escrito por daniel wilkerson y erick armbrust, con algunas consultas de mi parte. dan lo describe en esta charla .

nick johnson también ha descrito cómo hacer " transferir " escriba operaciones entre grupos de entidades , similar a lo que describe. no es tan general como la tapioca-orm, pero es más simple y liviano.

hay una función integrada relacionada, tareas transaccionales , que le permite agregar una tarea a una cola dentro de una transacción del almacén de datos, de modo que solo se agregará si la transacción se confirma correctamente. esa tarea puede realizar más operaciones de almacenamiento de datos, incluida una transacción en un grupo de entidades diferente. no es tan fuerte como la solución de dan y erick, pero le brinda una consistencia eventual garantizada en todos los grupos de entidades, lo cual es lo suficientemente bueno para muchos casos de uso, sin la sobrecarga adicional.

en respuesta a sus preguntas: 1) no está obligado a utilizar tanto las propiedades de referencia como las relaciones padre / hijo (es decir, grupos de entidades). esa directriz solo significa que los grupos de entidades limitan el rendimiento de escritura del almacén de datos, ya que las escrituras se serializan por grupo de entidades. debe tenerlo en cuenta si está considerando estructurar sus datos en grupos de entidades solo para consultas ancestrales.

2) una entidad no puede tener más de un padre. si desea modelar una relación de muchos a muchos, generalmente debe usar una propiedad ListProperty de propiedades de referencia (es decir, claves). consulte este artículo y esta charla para más detalles.