Em contraste com isso, as tecnologias emergentes nuvem empregam NO estrutura de banco de dados SQL mais frequentemente do que não. O banco de dados é mantida em infra-estrutura do provedor de nuvem. Administração de banco de dados, especialmente os procedimentos de backup, são vagamente definidas e não amadureceu até agora e estão evoluindo ao longo do tempo. Se uma empresa está se movendo de um DB relacional tradicional baseada em nuvem DB, a mudança pode ser muito grande quando se leva em conta todos estes fatores.
Conhecendo as ferramentas e conhecimento dos riscos torna a estratégia de banco de dados para nuvem valor dos benefícios de nuvens. Permite passar por aquilo que são as nossas opções com jogo de hoje. Nós não vamos passar detalhes nível de desenvolvimento neste artigo, mas estou a compreender o cenário em alto nível.
Estratégia de Implementação: SQL e SQL NO!
Se você está planejando para mover seus aplicativos existentes para jogo, e você tem JPA / JDO camadas em sua aplicação, a tarefa é bastante fácil. JPA / JDO Interfaces permitem armazenar dados de objeto no banco de dados sem ter código de banco de dados específico. Ele funciona com um tipo diferente de banco de dados, tornando assim mais fácil para a porta a sua aplicação a um tipo diferente de armazenamento. Esta estratégia é boa mesmo para o desenvolvimento de novas aplicações, especialmente se você quiser manter a opção de mover de volta a um modelo tradicional / banco de dados em um momento posterior. Existem, certamente, algumas limitações ou "recursos não suportados" com JOGO como "muitos para muitos relacionamentos" ou "junta-se em consultas", e você terá que dar conta de mudança de modelo, se é um caso de migração de aplicativo existente.
Para uma abordagem NO-SQL completo, você tem mais opções. Enquanto você pode usar o Google de armazenamento de dados diretamente com JOGO desde APIs, você terá certas coisas para lidar com o que pode significar um trabalho extra, por exemplo, lida com entidades Google datastore enquanto o aplicativo pode estar usando POJOs. Além disso, o gerenciamento de transações com o JOGO datastore API é um pouco complicado. Você também terá de lidar com chaves untyped etc Mas em nosso socorro, existem alguns frameworks que nos pode ajudar como Objectify, galho e slim
Embora o Google anunciou uma versão de banco de dados SQL para trabalhar com o Google App Engine, o seu ainda um "Labs" característica. No caso de você decidir ir SQL, você teria mais simples decisão com base em modelos empresariais existentes. Você se encaixaria em um framework ORM usando JDO / JPA ou estruturas semelhantes entre banco de dados e aplicação.
Migração e Backup
Frameworks de migração para Google App Engine não chegaram a um nível desejado de maturidade até agora. Uma possibilidade é, naturalmente, ter programas personalizados que podem funcionar como "fila de tarefas" e exportar dados em uma base periódica para o arquivo que você pode importar na sua DB. Existem frameworks como AppRocket que oferecem backup de DB em Python e aplicações baseadas AppScale que implementam, entre outros, APIs JOGO e executado como uma máquina virtual para oferecer várias tarefas.
Mas todas as abordagens acima de som confiável uma vez que o tamanho do banco de dados cresce muito grande! E isso é uma zona da abertura que precisa de algum trabalho.
Consistência disponibilidade,
App Engine oferece-o de armazenamento em duas variantes com base em garantia de disponibilidade e consistência. A loja de replicação alta proporciona maior disponibilidade de ler e escrever ao custo de maior latência escreve e custo mais elevado. Os dados são replicados em vários datacenters, mas, eventualmente, consultas mais consistentes.
O mestre opção datastore escravo usa um mestre e um armazenamento de dados escravo. Os dados são replicados de forma assíncrona e, portanto, a consistência é garantida. Mas uma vez que apenas um armazenamento de dados é usado, a disponibilidade pode ser "read only" durante a problemas no armazenamento de dados ou paradas planejadas. Neste caso, você também precisa criar o aplicativo para ser capaz de suportar "read-only-no-write" para armazenamento de dados.
A última palavra: Desempenho
Nenhum tópico no banco de dados está completa sem falar de performance! Embora um tratamento detalhado sobre o desempenho precisaria de uma discussão em separado. Datastore jogo não é um DB relacional tradicional e as necessidades de aplicações de forma diferente projetado, técnicas de indexação diferentes eo mais importante um bom entendimento de que tipo de loja que você está optando por.
Por exemplo, todas as entidades a ser actualizado em uma única transação em mestre-escravo loja deve ser do grupo de mesma entidade, o que não é necessário para armazenamento de dados de replicação alta. O design do aplicativo precisa ser bem pensada a partir de uma perspectiva de armazenamento de dados diferentes para alavancar a escala e infra-estrutura!
Nenhum comentário :
Postar um comentário