Thinking in AppEngine

Question

Sto cercando risorse che consentano di migrare le mie competenze di progettazione dal tradizionale archivio dati RDBMS a AppEngine DataStore (ad esempio lo stile "Schema morbido"). Ho visto diverse presentazioni e ogni tocco sui temi generali e su alcune tecniche specifiche.

Mi chiedo se ci sia un luogo in cui potremmo mettere in comune le conoscenze derivanti dall'esperienza ("dalle trincee") sugli approcci del mondo reale per ripensare il modo in cui i dati sono strutturati, in particolare il porting delle applicazioni esistenti. Siamo fortemente basati su Hibernate e probabilmente abbiamo già percorso un po 'il percorso sbagliato con il nostro modello di dati, generando alcune query gnarly con cui il nostro DB sta lottando.

Si prega di rispondere se:

1. Hai porting di un'applicazione non banale verso AppEngine
2. Hai creato un tipo comune di applicazione da zero in AppEngine
3. Hai fatto né 1 o 2, ma lo stanno prendendo in considerazione e vogliono condividere le tue scoperte fino ad ora.

Answer 1

Mi chiedo se c'è un posto abbiamo potuto riunire tutte le conoscenze da esperienze

Vari Google Gruppi sono buone per questo, anche se non so se ce ne sono direttamente applicabili a Java-GAE ancora - la mia esperienza GAE finora è tutta Python (sono orgoglioso di dire che Guido van Rossum, l'inventore di Python e ora al lavoro su Google su App Engine, mi ha detto che gli avevo insegnato alcune cose su come il suo genio ha funzionato - la sua raccomandazione ha menzionato che è ora quello che sono più orgoglioso, tra tutti quelli sul mio profilo linkedin ;-). [Lavoro in Google, ma il mio impatto su App Engine è stato molto periferico: ho lavorato su "building the cloud", sul cluster e sul SW per la gestione della rete e App Engine sta rendendo questa infrastruttura utile per gli sviluppatori di terze parti].

Ci sono in effetti molti saggi & presentazioni sul modo migliore per denormalizzare e frammentare i dati per il ridimensionamento GAE ottimale e le prestazioni - sono di qualità variabile, però. I libri che sono fuori finora sono così così; molti altri arriveranno nei prossimi mesi, speriamo che migliori (ho avuto un progetto per scriverne uno, con due amici molto abili, ma siamo tutti così indaffarati che abbiamo finito per lasciarlo cadere). In generale, consiglierei i video di Google I/O e i saggi che Google ha benedetto nel suo sito e blog dei motori delle app, INOLTRE ogni bit di contenuto da appenginefan's blog - ciò che Guido mi ha elogiato per avergli insegnato GAE, io a sua volta imparato da appenginefan (in parte attraverso il meraviglioso app engine meetup a Palo Alto, ma anche il suo blog è fantastico ;-).

Answer 2

Ho suonato in giro con Google App Engine per Java e ha scoperto che aveva molte lacune:

Questo non è di uso generale applicazione Java hosting. In particolare, non si ha accesso a un JRE completo (ad esempio non è possibile creare thread, ecc.) Dato questo fatto, è necessario creare la propria applicazione da zero con in mente JRE di Google App Engine. Portare qualsiasi applicazione non trival sarebbe impossibile.

più pertinente alle vostre domande ... datastore

Il datastore prestazioni è abissale. Stavo cercando di scrivere 5000 osservazioni meteorologiche all'ora - niente di troppo grande - ma non potevo farlo perché continuavo a scansare l'eccezione time-out sia con il datastore che con la richiesta HTTP. L'utilizzo dell'API del datastore "di basso livello" ha aiutato un po ', ma non abbastanza.

Volevo cancellare quelle osservazioni meteo dopo 24 ore per non riempire la mia quota. Ancora una volta, non poteva farlo perché l'operazione di cancellazione ha richiesto troppo tempo. Questo problema a sua volta ha portato al riempimento della mia quota di archivio dati. Insanamente, non è possibile eliminare facilmente grandi quantità di dati nel datastore GAE.

Ci sono alcune funzionalità che mi sono piaciute. L'integrazione di Eclipse è snellita. L'interfaccia utente del server dell'applicazione appspot è un milione di volte migliore rispetto a Tomcat (ad esempio, una bella vista dei registri). Ma gli svantaggi hanno superato di gran lunga quei benefici per me.

In sintesi, mi sono costantemente trovato a dover shave the yak, al fine di fare qualcosa che sarebbe stato piuttosto banale in qualsiasi ambiente di hosting Java/applicazione normale.

Answer 3

I timeout sono serrati e le prestazioni sono andate bene ma non grandi, quindi mi sono ritrovato a usare lo spazio extra per risparmiare tempo; per esempio ho avuto una relazione molti-a-molti tra trading cards e giocatori, quindi ho duplicato le informazioni di chi possiede cosa: gli oggetti Card hanno una lista di giocatori e gli oggetti Player hanno una lista di carte.

Normalmente memorizzare tutte le informazioni due volte sarebbe stato sciocco (e incline a non essere sincronizzato) ma ha funzionato molto bene.

In Python è stata rilasciata di recente un'API remota in modo da poter ottenere una shell interattiva sull'archivio dati in modo da poter giocare con il datastore senza timeout o limiti (ad esempio, è possibile eliminare grandi quantità di dati o refactoring dei modelli); ciò è straordinariamente utile poiché altrimenti, come ha detto Julien, è stato molto difficile eseguire operazioni di massa.

Answer 4

La progettazione di database non relazionali coinvolge essenzialmente la denormalizzazione laddove possibile.

Esempio: poiché il BigTable non fornisce sufficienti funzioni di aggregazione, l'opzione somma (in contanti) che sarebbe nel mondo RDBMS non è disponibile. Dovrebbe invece essere memorizzato sul modello e il metodo di salvataggio del modello deve essere sovrascritto per calcolare la somma del campo denormalizzata.

La progettazione di base essenziale che viene in mente è che ogni modello ha il proprio modello in cui tutti i campi obbligatori da compilare sono presenti denormalizzati nel modello corrispondente; e tu hai un'intera complessità di segnali-aggiornamento-robot che sta succedendo nei modelli.