Projetar para migrar facilmente para o Google App Engine
Pergunta
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.
Solução
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)