valores - ¿La relación uno a varios más eficiente en el almacén de datos de Google App Engine?

tablas relacionadas en power pivot

Question

Lo siento si esta pregunta es demasiado simple; Solo estoy entrando al noveno grado.

Estoy tratando de aprender sobre el diseño de base de datos NoSQL. Quiero diseñar un modelo de Google Datastore que minimice el número de lecturas / escrituras.

Aquí hay un ejemplo de juguete para una publicación de blog y comentarios en una relación de uno a varios. ¿Qué es más eficiente: almacenar todos los comentarios en una propiedad estructurada o usar una propiedad clave en el modelo de comentarios?

De nuevo, el objetivo es minimizar el número de lecturas / escrituras en el almacén de datos. Usted puede hacer las siguientes suposiciones:

• Los comentarios no se recuperarán independientemente de su respectiva publicación de blog. (Sospecho que esto hace que el StructuredProperty sea más preferible).
• Los comentarios deberán ser ordenados por fecha, clasificación, autor, etc. (Las subpropiedades en el almacén de datos no se pueden indexar, por lo que ¿esto podría afectar el rendimiento?)
• Tanto las publicaciones del blog como los comentarios pueden editarse (o incluso eliminarse) después de su creación.

Utilizando StructuredProperty:

from google.appengine.ext import ndb

class Comment(ndb.Model):
    various properties...

class BlogPost(ndb.Model):
    comments = ndb.StructuredProperty(Comment, repeated=True)
    various other properties...

Utilizando KeyProperty:

from google.appengine.ext import ndb

class BlogPost(ndb.Model):
    various properties...

class Comment(ndb.Model):
    blogPost = ndb.KeyProperty(kind=BlogPost)
    various other properties...

Siéntase libre de presentar cualquier otra consideración que se relacione con la representación eficiente de una relación de uno a muchos con respecto a minimizar el número de lecturas / escrituras en el almacén de datos.

Gracias.

Answer 1

Podría estar equivocado, pero por lo que entiendo, una Propiedad Estructurada es solo una propiedad dentro de una entidad, pero con sub-propiedades.

Esto significa leer un BlogPost y todos sus comentarios solo costarán una lectura. Así que cuando renderizas tu página, solo necesitas una operación de lectura para toda tu página.

Escribir sería más barato cada uno también. Necesitará una operación de lectura para obtener BlogPost, y mientras no actualice las propiedades indexadas, solo será una operación de escritura.

Puede manejar la clasificación de comentarios por su cuenta después de leer la entidad del almacén de datos.

Tendrá que sincronizar las actualizaciones / ediciones de sus comentarios con las transacciones, para asegurarse de que un comentario no sobrescriba a otro, ya que ambos están modificando la misma entidad. Es posible que tenga problemas irreparables si todos los usuarios comentan y editan la misma publicación del blog al mismo tiempo.

Sin embargo, al optimizar el costo, golpeará una pared con el tamaño máximo de entidad de 1 MB. Esto limitará la cantidad de comentarios que puede almacenar por publicación de blog.

Ir con la KeyProperty sería un poco más caro.

Necesitará una lectura para obtener la publicación del blog, más 1 consulta más 1 pequeña operación de lectura para cada comentario.

Cada comentario es una nueva entidad, por lo que serán al menos 4 operaciones de escritura. Es posible que desee indexar por orden de clasificación, por lo que terminará costando aún más operaciones de escritura.

En el lado positivo, tendrá comentarios ilimitados por publicación de blog, no tiene que preocuparse por sincronizar nuevos comentarios. Es posible que deba preocuparse por la sincronización para editar comentarios, pero si limita la edición al creador, eso no debería ser un problema. Usted no tiene que hacer la clasificación a ti mismo tampoco.

Es una compensación entre costo y características.

Answer 2

Qué pasa:

from google.appengine.ext import ndb

class Comment(ndb.Model):
    various properties...

class BlogPost(ndb.Model):
    comments = ndb.KeyProperty(Comment, repeated=True)
    various other properties...

De esta manera, puede almacenar hasta 5000 comentarios por publicación de blog (el número máximo de propiedades repetidas) independientemente del tamaño de cada publicación de blog. No necesitarás una consulta para obtener los comentarios de un blog, solo puedes hacer ndb.get_multi(blog_post.comments) . Y para esta operación, puedes intentar confiar en el memcache de ndb. Por supuesto, depende de su caso de uso si esta es una buena suposición o no.

Answer 3

Tenga en cuenta esta advertencia al utilizar una propiedad estructurada repetida:

No use propiedades repetidas si tiene más de 100-1000 valores. (1000 probablemente ya lo está empujando). No fueron diseñados para tal uso.

Vea la respuesta de Guido en el diseño, rendimiento y uso de propiedades repetidas de GAE ndb .

Entonces, si bien no puede alcanzar el límite de entidad de 1 MB con StructuredProperty, puede alcanzar fácilmente el máximo de 100-1000 sugerido.