django - standard - Query complesse che utilizzano il datastore GAE




java app engine datastore (3)

Direi che lo storage di tipo bigtable è meno adatto per applicazioni statistiche, proprio per le ragioni che hai menzionato. Ma questo è un classico compromesso che devi fare. Raramente mi sono trovato a utilizzare la flessibilità di query molto complesse, ma sono stato costretto molte volte a trovare soluzioni più specializzate per cose che non avrebbero dovuto essere nel db in primo luogo.

Se ci si attiene a un RDBMS, è possibile eseguire il partizionamento logico e la denormalizzazione in modo abbastanza semplice, ad esempio tramite le strategie di persistenza di Hibernates e gli Hibernate Shard . Se si può vivere con l'elaborazione un po 'più lenta, è possibile anche eseguire query SQL su storage di tipo bigtable (si veda ad esempio latin su porco maiale ).

Sono nelle prime fasi di sviluppo di un sito web di statistiche sportive (ultimo frisbee) e vorrei sapere le tue opinioni se Google App Engine è giusto per me.

Lo sto scrivendo in Python usando Django e da anni mi sento a mio agio con RDBMS standard, ma questo sito è un progetto a lungo termine e mi aspetto grandi quantità di dati, quindi mi piacerebbe il ridimensionamento "infinito" offerto dal datastore GAE. Una grande maggioranza delle query al database restituirà risultati molto standard che renderebbero il datastore una scelta logica. Tuttavia, mi piacerebbe essere in grado di fare query estremamente complesse in futuro per trovare nuove metriche statistiche o semplicemente ottenere risultati interessanti. Ho intenzione di fare un sacco di questo in futuro, ma non saprò quali sono queste query fino a quando i dati non sono già stati raccolti.

Ad esempio, si vedono spesso statistiche di baseball che gli analisti si inventano statistiche ridicole come "Questa è solo la prima volta negli ultimi 50 anni che due lanciatori mancini i cui cognomi iniziano con la" Z "hanno lanciato colpi di scena a colpo singolo in passato. giorni". Mi piacerebbe avere la flessibilità di fare qualsiasi domanda qualunque in futuro. :)

Tuttavia, ho l'impressione che un database non relazionale come bigtable richieda di creare modelli contenenti dati ridondanti in anticipo e tutto il lavoro si svolge sugli inserti piuttosto che sui recuperi. Ho già creato modelli di django che contengono praticamente tutti i dati su cui avrei mai dovuto interrogare, ma non ho idea di quali modelli denormalizzati desidererò avere tra un anno o due. Quindi, mi sento come rendere le query complesse in futuro sarebbe estremamente difficile sul datastore GAE e richiederebbe di estrarre una tonnellata di informazioni dal server prima di elaborarlo in python.

Il datastore del motore dell'app google è semplicemente sbagliato per quello che voglio fare? O mi manca qualcosa. Grazie mille in anticipo!

Aggiornamento: grazie per le risposte finora. Mi rendo conto che dovrei anche menzionare che molte di queste query complesse sono query che vorrei che gli utenti potessero fare, rendendo così un database offline non proprio un'opzione. Ad esempio, gli utenti dovrebbero essere in grado di vedere varie statistiche di come giocano due giocatori particolari quando sono sul campo nello stesso momento durante determinati giochi o stagioni. Anche se queste query non sono così frequenti come le statistiche aggregate standard, continueranno a verificarsi con regolarità.

Avere un database relazionale e il datastore GAE sarebbe grandioso, ma django non supporta più db di default e l'installazione di patch su una soluzione sembra difficile e disordinata. Eric Florenzano ha una bella soluzione per due database che usano entrambi i modelli django, ma se dovessi usare il datastore GAE, dovrei invece usare il modello db del motore dell'app. E trovare una buona soluzione come ha fatto per questo complesso problema è un po 'oltre il mio livello di abilità a questo punto.

Al momento le mie due opzioni preferite sono l'uso della coda di task GAE per eseguire le query più difficili o passare a un webhost standard come la webfreation e quindi denormalizzare le mie tabelle più tardi una volta che i miei dati crescono e ho bisogno di aumentare le prestazioni.


Il data-store GAE è completamente diverso da un RDBMS. È facile in un DB relazionale scrivere qualcosa come:

SELECT STDEV(player_score)
FROM Table
WHERE player_id = 1234
  AND game_date BETWEEN '2007-01-01' AND '2009-11-10'
  AND city <> 'London'

La query GAE ha molte restrizioni, vedi qui , quindi non è facile da tradurre. Per le funzioni di aggregazione (somma, stdev, ecc.) Devi trasferire tutti i dati nel livello applicazione e calcolare o gestire le entità aggregate che si aggiornano su ogni inserimento / aggiornamento di dati.

Aggiornare
Puoi prendere in considerazione l'utilizzo di GAE per l'interfaccia utente e la logica di business, ma avere un DB relazionale separato da qualche altra parte in cloud come: Microsoft SQL, DB2 su Amazon, MySQL altrove e utilizzare il data-store GAE per aggregazioni e statistiche precalcolate. Quindi le statistiche sono ancora calcolate in RDBMS, ma i dati vengono memorizzati (statistiche parziali pre-calcolate) nello spazio di archiviazione GAE; simile alla memoria dimensionale nei cubi analitici.


Voglio supportare il riferimento di MindWire all'utilizzo di Google CloudSQL.

Il mio attuale progetto funziona in realtà dall'archivio dati principalmente con altre attività basate su SQL eseguite in Cloud SQL.

Refernce Docs per SDK Python App Engine





non-relational-database