parent-> relazioni figlio in appengine python (bigtable)

Question

Sto ancora imparando le mie lezioni sulla modellazione dei dati in bigtable/nosql e apprezzerei qualche feedback. Sarebbe corretto dire che dovrei evitare le relazioni genitore-> figlio nella mia modellazione dei dati se ho spesso bisogno di trattare i bambini in modo aggregato tra i genitori?

Ad esempio, diciamo che sto costruendo un blog a cui un certo numero di autori darà il proprio contributo e che l'un l'altro ha post e ogni post ha tag. Quindi potrei potenzialmente impostare qualcosa del genere:

class Author(db.Model): 
    owner = db.UserProperty() 

class Post(db.Model): 
    owner = db.ReferenceProperty(Author, 
    collection_name='posts') 
    tags = db.StringListProperty() 

Come ho capito questo creerà un gruppo di entità basato sull'autore padre. Ciò causa inefficienza se per lo più ho bisogno di interrogare i Post per tag che mi aspetto di tagliare su più Autori?

Capisco che fare una query sulle proprietà dell'elenco può essere inefficiente. Diciamo che ogni post ha in media circa 3 tag, ma potrebbe arrivare fino a 7. E mi aspetto che la mia collezione di tag possibili sia tra le poche centinaia. C'è qualche vantaggio nel modificare quel modello in qualcosa del genere?

class Author(db.Model): 
    owner = db.UserProperty() 

class Post(db.Model): 
    owner = db.ReferenceProperty(Author, 
    collection_name='posts') 
    tags = db.ListProperty(db.Key) 

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

O sarei meglio fare qualcosa di simile?

class Author(db.Model): 
    owner = db.UserProperty() 

class Post(db.Model): 
    owner = db.ReferenceProperty(Author, 
    collection_name='posts') 

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

class PostTag(db.Model): 
    post = db.ReferenceProperty(Post, 
    collection_name='posts') 
    tag = db.ReferenceProperty(Tag, 
    collection_name='tags') 

E ultima domanda ... cosa succede se il mio caso d'uso più comune sarà query per i messaggi di più tag. Ad esempio, "trova tutti i post con tag in {'mele', 'arance', 'cetrioli', 'biciclette'}" Uno di questi approcci è più appropriato per una query che cerca post che abbiano una qualsiasi raccolta di tag ?

Grazie, so che era un boccone. :-)

Answer 1

Qualcosa come il primo o il secondo approccio sono adatti per App Engine.Si consideri la seguente configurazione:

class Author(db.Model): 
    owner = db.UserProperty() 

class Post(db.Model): 
    author = db.ReferenceProperty(Author, 
    collection_name='posts') 
    tags = db.StringListProperty() 

class Tag(db.Model): 
    post_count = db.IntegerProperty() 

Se si utilizza il tag della stringa (case-normalizzato) come il key_name entità Tag, è possibile interrogare in modo efficiente per i messaggi con un tag specifico, o elencare i tag di un post, o andare a prendere statistiche tag:

post = Post(author=some_author, tags=['app-engine', 'google', 'python']) 
post_key = post.put() 
# call some method to increment post counts... 
increment_tag_post_counts(post_key) 

# get posts with a given tag: 
matching_posts = Post.all().filter('tags =', 'google').fetch(100) 
# or, two tags: 
matching_posts = Post.all().filter('tags =', 'google').filter('tags =', 'python').fetch(100) 

# get tag list from a post: 
tag_stats = Tag.get_by_key_name(post.tags) 

Il terzo approccio richiede ulteriori domande o recupera per la maggior parte delle operazioni di base, ed è più difficile se si desidera eseguire una query per più tag.

Answer 2

Vorrei scegliere l'ultimo approccio, perché consente di recuperare un elenco di post direttamente dato un tag.

Il primo approccio rende praticamente impossibile mantenere un insieme di tag canonico. In altre parole, la domanda "quali tag sono attualmente presenti nel sistema" è molto costosa per rispondere.

Il secondo approccio risolve questo problema, ma come ho detto non ti aiuta a recuperare i post con un tag.

gruppi di entità sono un po 'di una bestia misteriosa, ma basti dire che il primo approccio non crea un gruppo di entità, e che sono solo necessari per le operazioni di database transazionale, e talvolta utile per ottimizzare i dati si legge, ma probabilmente non sono necessari in un'applicazione di dimensioni ridotte.

Va detto che qualsiasi approccio che si prende funzionerà bene solo in combinazione con una strategia di caching intelligente. Applicazioni GAE AMARO il caching. Prendi confidenza con la memcache api e impara le operazioni di lettura/scrittura di massa su memcache e sul datastore.