Diseñando para migrar fácilmente a Google App Engine

Question

Voy a empezar a diseñar una aplicación web en breve, y aunque tengo mucha experiencia haciéndolo en el mundo de SQL, no tengo idea de lo que debo tener en cuenta para hacerlo con el objetivo de migrar a GAE en un futuro muy cercano.

Como alternativa, podría diseñar la aplicación para GAE desde el principio, y en ese caso, ¿cuáles son las diferencias que debo tener en cuenta? En otras palabras, ¿cuáles son los DO y DONT de escribir su aplicación para GAE, proveniente de un pasado de bases de datos relacionales?

Answer 1

Justo fuera de la parte superior de mi cabeza:

• Es realmente sólo un número-> tienda de valor, no se deje engañar por cosas como GQL (que es sólo un subconjunto de SQL SELECT)
• Sin uniones: a menudo hay que desnormalizar u olvidar
• Tiempos de espera más o menos frecuentes
• (Muy) acceso lento en comparación con la base de SQL local.
• RECUENTO muy caro
• OFFSET (SELECCIONAR) implementado en el lado del cliente - por lo que, de hecho, usted lo trae todos los registros hasta compensar - como se ha señalado por Nick Johnson en uno de los comentarios, no es el lado del cliente, por lo que ahora , como LIMIT de 1000 se ha ido, es similar a las bases de datos SQL.
• (recientemente retirado) límite de 1000 filas captadas
• rendimiento SELECT disminuye drásticamente al aumentar el número de filas devueltas
• Las migraciones son difíciles de hacer porque hay que hacerlo mediante peticiones http normales y cada solicitud se mató después de los 30 secs. Debe recurrir a colas de tareas que procesan filas en lotes
• Hay claves pseudoexternas llamadas Propiedades de referencia en la API de Python, pero no se aplican de ninguna manera; si alguien/algo borra el objeto de destino, entonces tiene lo que se conoce como colgando puntero en C++
• los campos que se utilizan para las consultas tienen que ser indexados, pero aún usando clave (especie de clave principal de cada fila/instancia) hace que sus consultas correr más rápido
• índices de construcción de ejemplo vivo puede tomar mucho tiempo (y no puede disminuirlo) y sin ellos su aplicación a menudo no puede funcionar. Cerveza y paciencia muy recomendadas.
• MUCHOS límites artificiales (como el LIMITE máximo ya eliminado de 1000). P.ej. El operador GQL 'IN' es solo azúcar sintáctico para múltiples OR-s, y hay un límite superior de 30 valores utilizados.

Todo lo que significa que es probable que no se puede evitar la exposición de estado inconsistente de usuario, y casi con seguridad no se puede evitar tener estado inconsistente de los datos (por ejemplo, filas y medio emigraron y la otra mitad no, durante el manual de JOIN cambios de datos, etc.)