Organizzazione di gruppi di entità su Google App Engine per la scrittura

Question

Sono un po 'confuso riguardo a "Gruppi di entità" nell'archivio dati di replica elevata (HRD) di Google App Engine. La documentazione di Google menziona che l'HRD consente solo 1 scrittura al secondo per gruppo di entità.

Che cosa significa esattamente? È questa 1 scrittura per richiesta utente o 1 scrittura per entità (che presumo sia un concetto simile a una "tabella").

Ad esempio, se si dispone di un'entità "Utente" e una tabella "Post". Se "Post" è un antenato di "utente":

1. Questo significa che uno "utente" può creare una "Post" al secondo
2. ... o significa tutte le scritture nell'entità "Post" sono limitate a 1 write-per-second indipendentemente dall'Utente? (ovvero il sistema può salvare solo 1 post alla volta indipendentemente dal numero di utenti che inviano post)
3. ... o significa che una singola entità "Utente" non può creare più di 1 "Post" allo stesso tempo (anche se migliaia di altri utenti sono creati entità "Post")?

Quali sono le opzioni per attenuare questo problema? È ragionevole creare entità root "Utente" e "Post"? Questo mi consentirà di creare più istanze "Post" al di fuori della limitazione di 1 write-per-second? Voglio evitare qualsiasi potenziale problema se diciamo che 1000 utenti dovevano creare voci "Post" contemporaneamente.

Answer 1

"gruppo di entità" è non come "tabella". Non c'è nulla che significhi "tavolo" nel datastore appengine. Dovresti pensare solo in termini di entità e indici.

Utilizzare i gruppi di entità solo quando si desidera essere in grado di eseguire operazioni a livello di transazione. Nel caso di un blog con "Post", probabilmente non importa se aggiungi o rimuovi i messaggi a livello di transazione, quindi NON devono essere presenti in un gruppo di entità.

Nella mia applicazione ho circa 15 diversi tipi di entità e circa 1,5 milioni di esse. Ogni singolo è un'entità root, anche correlata, e penso che questo sia l'ideale per AppEngine. Per quanto posso dire, l'UNICO scopo per i gruppi di entità è supportare le operazioni atomiche su più entità - non sono uno strumento organizzativo.

PS: come per le tue domande sulle restrizioni del gruppo Entity (che credo saranno per lo più discutibili ora): il limite di scrittura è per entità, non per richiesta. 1. Le entità non creano altre entità. 2. Se tutti i messaggi erano nello stesso gruppo di entità, allora sì, è possibile salvare solo 1 al secondo. 3. Se ciascun utente era nel proprio gruppo di entità, è possibile scrivere 1 post in ogni stesso gruppo allo stesso tempo, tante volte al secondo come desiderato. È solo che nessun singolo gruppo può essere scritto più di una volta al secondo. Sì, penso che "Utente" e "Post" dovrebbero essere entrambi entità root.

Answer 2

Anche l'utilizzo di gruppi di entità consente di rendere altamente coerenti i dati all'interno del gruppo.

Ad esempio, senza gruppi di entità, se si crea un post e quindi si passa rapidamente all'elenco dei post recenti, è possibile che il nuovo messaggio non venga visualizzato immediatamente. Per un blog, questo potrebbe non essere un problema.

Ma se si sta eseguendo un sistema di gestione delle attività ... si passa alla schermata dei dettagli dell'attività, si chiude l'attività e questo torna indietro all'elenco delle attività, l'attività potrebbe ancora apparire come aperta. Questo non è accettabile.Qui, ti occorrono gruppi di entità o altri mezzi per rendere l'elenco delle attività coerente per l'utente corrente.

In alcuni modelli di dati, è facile creare gruppi di entità. Ad esempio, la creazione di attività parte di un gruppo di progetti risolverebbe il problema presumendo che sia possibile visualizzare solo le attività per un singolo gruppo. Se l'interfaccia utente consente di elencare le attività da più gruppi, è più difficile trovare un modello che funzioni.