2010-10-08 9 views
5

Il datastore del motore di app non può essere interrogato per un risultato aggregato.Strategia alternativa per interrogare l'aggregazione ("raggruppa per") nel datastore del motore dell'app google

Esempio: Ho un'entità chiamata "Post" con i seguenti campi:

Key ID, String soprannome, String postText, int punteggio

Ho molti soprannomi diversi e molti messaggi di ogni soprannome nel mio archivio dati.

Se voglio una classifica dei primi dieci soprannomi di punteggio totale, vorrei in genere hanno sql come segue:

select nickname, sum(score) as sumscore 
from Post 
group by nickname 
order by sumscore 
limit 10 

Questo tipo di query non è possibile in Google App Engine datastore java api (JDO o jpa).

Quali sono le strategie alternative che potrei utilizzare per ottenere un risultato simile?

Crudamente e intensamente, ho potuto caricare ogni entità Post e calcolare l'aggregazione completamente nel mio codice applicazione. Questo ovviamente non è efficiente su dataset di grandi dimensioni.

Quali altre strategie posso utilizzare?

+1

Se Google aggiornasse solo il proprio plug-in, DataNucleus avrebbe fatto questo approccio "forza bruta e brutale" per te in modo trasparente. Il codice per farlo sarebbe solo una manciata di linee per il loro plugin, contribuito un anno fa ... – DataNucleus

+1

@DataNucleus Avere supporto integrato non lo renderebbe più veloce o più efficiente. –

+1

@Nick, certo che non lo sarebbe, ma l'intera esperienza utente sarebbe dannatamente più piacevole, e la quantità di codice che la gente dovrà scrivere sarebbe inferiore - questo è il business in cui ci troviamo – DataNucleus

risposta

10

Creare un modello Nickname e ogni volta che si aggiunge un nuovo post, recuperare il soprannome corrispondente e aumentare la somma del punteggio memorizzato lì. In sostanza, esegui il calcolo all'inserzione/aggiornamento-tempo, non al tempo di interrogazione.

+0

Ciao Ambra.Grazie per il tuo contributo. Lo sto già facendo fino ad un certo punto. (Il mio modello è più complesso di come l'ho descritto). Sto già aggregando molti dati su inserti e aggiornamenti per aggirare questo problema. Ma non è possibile salvare tutte le statistiche aggregate possibili in questo modo (ho un sacco di statistiche aggregate diverse che vorrei calcolare ogni tanto). Ma questa è ancora una risposta valida. – Patrick

+1

L'approccio di Amber è giusto e sarà scalabile. Io uso un approccio molto simile a "fan-in con viste materializzate" (http://code.google.com/events/io/2010/sessions/high-throughput-data-pipelines-appengine.html) per calcolare dozzine di aggregati. Funziona abbastanza bene. –

+1

Sto usando questa tecnica, accoppiata a sharding per ridurre al minimo la contesa (http://code.google.com/appengine/articles/sharding_counters.html); oltre a poter posticipare atomicamente gli aggiornamenti di tali contatori e statistiche. Segnalo questa risposta come la migliore. – Patrick

Problemi correlati