Projetar para migrar facilmente para o Google App Engine

Question

Vou começar a projetar um aplicativo da web em breve e, embora tenha muita experiência em fazê -lo no mundo do SQL, não tenho idéia do que preciso levar em consideração para fazê -lo com o objetivo de migrar para o GAE em muito perto futuro.

Como alternativa, eu poderia projetar o aplicativo para o GAE desde o início e, portanto, nesse caso, quais são as diferenças que preciso levar em consideração? Em outras palavras, quais são os do DOS e o donts de escrever seu aplicativo para o GAE, provenientes de um passado de bancos de dados relacionais.

Answer 1

Apenas fora do topo da minha cabeça:

• É realmente apenas uma loja de valores, não se deixe enganar por coisas como GQL (que é apenas um subconjunto de SQL Select)
• Nenhuma junção - muitas vezes você tem que desnormalizar ou esquecer
• Tempo limite mais ou menos frequente
• Acesso (muito) lento em comparação com a base local do SQL.
• Conte muito caro
• Offset (em selecionado) implementado no lado do cliente - então, na verdade, você busca todos os registros para compensar - Como apontado por Nick Johnson em um dos comentários, não é do lado do cliente, então agora, pois o limite de 1000 desaparece, é semelhante aos bancos de dados SQL.
• (Removido recentemente) Limite de 1000 linhas buscadas
• Selecionar desempenho diminui drasticamente com o aumento do número de linhas retornadas
• É difícil fazer as migrações, porque você precisa fazê -las usando solicitações HTTP normais e cada solicitação é morta após 30 segundos. Você precisa recorrer a filas de tarefas que processam linhas em lotes
• Existem pseudo -chaves estrangeiras - chamadas referênciaProperties na API Python - mas elas não são aplicadas de forma alguma - se alguém/algo excluir objeto de destino, então você tem o que é conhecido como ponteiro pendurado em c ++
• Campos que você usa para consultas precisam ser indexados, mas ainda usando chave (tipo de chave primária para cada linha/instância) faz suas consultas funcionarem mais rápido
• A criação de índices na instância ao vivo pode levar muito tempo (e você não pode diminuí -lo) e sem eles seu aplicativo geralmente não pode funcionar. Cerveja e paciência altamente recomendados ..
• Muitos limites artificiais (como o limite máximo de 1000 já removidos). Por exemplo, o operador GQL 'no' é apenas açúcar sintático para múltiplos OR-S, e há limite superior de 30 valores utilizados.

Tudo isso significa que você provavelmente não pode evitar expor o estado inconsistente ao usuário, e quase com certeza não pode evitar ter um estado inconsistente de seus dados (por exemplo, meia fila migrou e não, durante a união manual, juntando -se a alterações de dados etc)