Progettazione per migrare facilmente su Google App Engine

Question

Inizierò a progettare un'app Web a breve, e mentre ho molta esperienza nel mondo SQL, non ho idea di cosa devo prendere in considerazione per farlo con l'obiettivo di migrare verso Gae in modo molto vicino futuro.

In alternativa, potrei progettare l'app per GAE sin dall'inizio, e quindi in quel caso, quali sono le differenze che devo prendere in considerazione? In altre parole, quali sono i DOS e le Donts di scrivere la tua app per GAE, provenienti da un passato di database relazionali.

Answer 1

Appena fuori dalla mia testa:

• È davvero solo un negozio di valore, non lasciarti ingannare da cose come GQL (che è solo un sottoinsieme di SQL Select)
• NO JOIN - Spesso devi denormalizzare o dimenticare
• Timeout più o meno frequenti
• (Molto) l'accesso lento rispetto alla base SQL locale.
• Conta molto costoso
• Offset (in Select) Implementato sul lato client, quindi in realtà prendi tutti i record fino all'offset - Come indicato da Nick Johnson in uno dei commenti, non è lato client, quindi ora, poiché il limite di 1000 è sparito, è simile ai database SQL.
• (Recentemente rimosso) limite di 1000 file recuperate
• Selezionare le prestazioni diminuiscono drasticamente con il numero crescente di righe restituite
• Le migrazioni sono difficili da fare perché devi farlo utilizzando le normali richieste HTTP e ogni richiesta viene uccisa dopo 30 secondi. Devi ricorrere alle code di attività che elaborano le file in lotti
• Ci sono chiavi straniere pseudo - chiamate referenceproperties nell'API Python - ma non vengono applicato in alcun modo - se qualcuno/qualcosa elimina l'oggetto target, allora hai quello che è noto come puntatore penzolante in C ++
• I campi che usi per le query devono essere indicizzati, ma ancora usando chiave (tipo di chiave primaria per ogni riga/istanza) Fa funzionare le domande più velocemente
• Costruire indici sull'istanza dal vivo può richiedere molto tempo (e non puoi diminuirlo) e senza di loro la tua app spesso non può funzionare. Birra e pazienza altamente raccomandate ..
• Molti limiti artificiali (come il limite massimo già rimosso di 1000). EG GQL "In" L'operatore è solo zucchero sintattico per più OR-S e c'è un limite superiore di 30 valori utilizzati.

Tutto ciò significa che probabilmente non puoi evitare di esporre uno stato incoerente all'utente e quasi di sicuro non puoi evitare di avere uno stato incoerente dei tuoi dati (ad esempio mezze righe migrate e metà non, durante le modifiche ai dati di unione manuale ecc.