Diseño para migrar fácilmente al motor de aplicaciones de Google

Question

Voy a comenzar a diseñar una aplicación web en breve, y aunque tengo mucha experiencia en hacerlo en el mundo de SQL, no tengo idea de lo que necesito tener en cuenta para hacerlo con el objetivo de migrar a GAE en los muy cercanos futuro.

Alternativamente, podría diseñar la aplicación para GAE desde el principio, y en ese caso, ¿cuáles son las diferencias que necesito tener en cuenta? En otras palabras, ¿cuáles son los DoS y los que no están escribiendo su aplicación para GAE, provenientes de un pasado de bases de datos relacionales?

Answer 1

Justo en la parte superior de mi cabeza:

• En realidad es solo una clave de valor de clave, no se deje engañar por cosas como GQL (que es solo un subconjunto de SQL Select)
• No se unen: a menudo tienes que desnormalizar u olvidar
• Tiempos de espera más o menos frecuentes
• (Muy) Acceso lento en comparación con la base local de SQL.
• Cuenta muy caro
• Offset (en selección) implementado en el lado del cliente, por lo que de hecho obtiene todos los registros hasta Offset - Como lo señaló Nick Johnson en uno de los comentarios, no es el lado del cliente, por lo que ahora, como el límite de 1000 se ha ido, es similar a las bases de datos SQL.
• (Recientemente eliminado) Límite de 1000 filas obtenidas
• El rendimiento seleccionado disminuye drásticamente con el aumento del número de filas devueltas
• Las migraciones son difíciles de hacer porque tienes que hacerlas usando solicitudes HTTP normales y cada solicitud se mata después de 30 segundos. Debe recurrir a colas de tareas que procesan filas en lotes
• Hay pseudo claves extranjeras, llamadas propiedades de referencia en la API de Python, pero no se aplican de ninguna manera, si alguien/algo elimina el objeto objetivo, entonces usted tiene lo que se conoce como un puntero colgante en C ++
• Los campos que usa para consultas deben indexarse, pero aún usar llave (tipo de clave principal para cada fila/instancia) hace que sus consultas funcionen más rápido
• Construir índices en instancia en vivo puede llevar mucho tiempo (y no puede disminuirlo) y sin ellos su aplicación a menudo no puede funcionar. Cerveza y paciencia muy recomendable.
• Muchos límites artificiales (como el límite máximo ya eliminado de 1000). Por ejemplo, el operador de GQL 'in' es solo azúcar sintáctica para múltiples OR, y hay un límite superior de 30 valores utilizados.

Todo eso significa que probablemente no pueda evitar exponer el estado inconsistente al usuario, y casi seguro no puede evitar tener un estado inconsistente de sus datos (por ejemplo, las medias filas migraron y la mitad no, durante los cambios en los datos de unión manual, etc.)