Opções de Armazenamento no Google App Engine

Artigo traduzido do original escrito por Nick Johnson 
No Google App Engine há algumas opções para seu aplicativo armazenar dados. Alguns, como o datastore, são bem conhecidos, mas alguns outros nem tanto, e todos eles tem características distintas. Este artigo tem como propósito enumerar essas opções, e descrever os prós e contras de cada uma, para que você possa ter mais informações para armazenar seus dados.
 
Datastore 
A opção de armazenamento mais bem conhecida, mais largamente usada e mais versátil é, claro, o datastore, que é o banco de dados não-relacional do App Engine, e provê armazenamento robusto e durável, bem como provê a maior flexibilidade em relação à forma que seus dados são armazenados, acessados e manipulados.
Prós
  • Durável - os dados armazenados no datastore são permanentes.
  • Leitura/escrita - os aplicativos podem ler e escrever dados no datastore, e o datastore provê mecanismo de transações que asseguram a integridade.
  • Consistência global - todas as instâncias de um aplicativo enxergam a mesma datastore.
  • Flexível - consultas e indexações dão várias formas para consultar e pegar dados.

Contras
  • Latência - pelo datastore armazenar os dados no disco e fornecer garantias de constância (reliability guarantees), as escritas precisam esperar até que o armazentamento dos dados seja confirmado antes de retornar, e leituras normalmente precisam pegar dados do disco.

 
 

Memcache
Das opções ‘secundárias’ de armazenamento, o Memcache é o mais conhecido.  A API do Memcache fornece os meios para os aplicativos colocarem dados no cache para evitar refazer operações custosas. O Memcache é normalmente utilizado como uma camada de cache para outras APIs, como o datastore, ou para cachear  resultados gerados de qualquer fonte.

Prós
  • Rápido - acessos ao memcache tipicamente demoram apenas alguns milisegundos para serem completados.
  • Consistente globalmente - todas as instâncias de uma app tem a mesma visão do memcache, que fornece operações atômicas, para que os aplicativos assegurem a integridade dos dados armazenados nele.

Contras
  • Inconstante - os dados podem sair do memcache a qualquer momento


Blobstore
O Blobstore oferece um meio de armazenar e servir uma grande quantidade de dados upados pelo usuário facilmente e com eficiência.

Prós
  • Suporta arquivos grandes - até 2GB por blob.
  • Elimina a necessidade de você mesmo manejar os blobs.
  • Oferece um mecanismo para servimento de alta-performance dos blobs, particularmente imagens.
  • Os aplicativos conseguem ler os conteúdos do blob do mesmo jeito que leriam arquivos locais.


Contras
  • Somente leitura - os aplicativos não podem modificar os blobs upados, ou criar blobs novos.
  • A cobrança precisa ser ativada para  habilitar os blobs



Memória da instância
As instâncias do aplicativo também podem cachear dados na memória local, através do uso de globais ou de membros de classe.
Isso resulta em uma velocidade incrível, mas também em muitos prejuízos.

Prós
  • Rápido - literalmente o mais rápido possível, já que os dados são armazenados no mesmo processo que os acessam.
  • Conveniente - nenhuma API requerida, armazene os dados em globais ou em membros de classe.
  • Flexível - os dados podem ser armazenados em qualquer formato que seu programa manipular. Nenhuma serialização ou deserialização é necessária.


Contras
  • Inconstante - as instâncias podem ser iniciadas ou paradas a qualquer hora, então os aplicativos devem usar a memória da instância só para cachear dados.
  • Sem consistência global - cada instância de sua app tem seu próprio ambiente de runtime, logo, suas próprias variáveis locais. Mudanças em uma instância não são refletidas em outras instâncias.
  • Capacidade limitada - instâncias são limitadas em relação à quantidade de memória que podem consumir até que sejam terminadas. Isso põe um limite duro na quantidade de dados que você consegue cachear na memória.



Arquivos Locais
Os aplicativos podem ler de qualquer arquivo que foi upado com o aplicativo, não marcados como conteúdo estático, usando as operações padrão do sistema de arquivos. Isso inclui série de dados apenas-leitura de que o aplicativo eventualmente necessitar.

Prós
  • Rápido - ler arquivos locais requer somente acesso padrão ao disco na máquina em que a instância do aplicativo estiver rodando, então a latência é quase tão boa quanto no memcache.
  • Confiável - os arquivos locais estão disponíveis sempre que sua app estiver servindo
  • Flexível - você pode usar qualquer formato ou mecanismo para acessar os arquivos locais que você quiser.


Contras
  • Apenas leitura - os aplicativos não podem modificar o conteúdo dos arquivos  locais; eles são fixados na hora do deploy.
  • Capacidade limitada - há o limite de 10MB por arquivo,  e de 150MB para o aplicativo.



Carga da fila de tarefas (Task queye payloads)
Ainda que não seja um armazenamento no senso-comum, as tarefas da fila de tarefas podem ter uma carga associada a elas, que podem previnir a necessidade de usar outros sistemas de armazenamento.

Prós
  • Rápido - as cargas são enviadas para a tarefa quando ela for rodada, então não é preciso nenhuma chamada à API para pegar os dados.
  • Usado corretamente, lhe permite evitar a necessidade de armazenar dados de tarefa em algum outro lugar.


Contras
  • Propósito-único - as cargas só são úteis para armazenar os dados fornecidos a uma fila de tarefas.
  • Capacidade limitada - as tarefas são limitadas a um tamanho de 10KB, incluindo os dados da carga.



Conclusão
O App Engine fornece mais mecanismos de armazenagem de dados do que aparenta em um primeiro momento. Todos eles tem prós e contras diferentes, então é provável que  um - ou mais - deles servirá bem ao seu aplicativo. Frequentemente, a solução ideal envolve uma combinação, como o datastore e o memcache, ou arquivos locais e memória da instância.

 

Tagged App Engine Python
​