Prós e contras do NoSQL

Há, é claro, prós e contras da modelagem de dados sem esquemas. Uma vantagem do aplicativo Back to the Races é que ele é bastante flexível. Caso eu decida adicionar uma nova propriedade ao Runner (como um SSN), não há muito o que ser feito —na verdade, se eu incluí-la nos parâmetros do construtor, ela estará lá. O que acontece com as instâncias mais antigas que ainda não foram criadas com um SSN? Nada. Elas possuem um campo que é null.

Por outro lado, está claro que troquei consistência e integridade por eficiência. A arquitetura de dados atual do aplicativo não me deixa com nenhuma restrição — seria possível, teoricamente, criar um número infinito de instâncias do mesmo objeto. Sob a manipulação de chaves do Google App Engine, todas elas teriam chaves únicas, mas todo o restante seria idêntico. O pior é que exclusões em cascata não existem, então, se eu usasse a mesma técnica para modelar relacionamentos one-to-many e o pai fosse removido, eu terminaria com um filho ultrapassado. É claro que seria possível implementar minha própria verificação de integridade — mas isso é importante: Eu mesmo teria que fazer isso (assim como fiz todo o restante).

Usar armazenamentos de dados sem esquemas requer disciplina. Caso crie vários tipos de Races — algumas com nomes, outras sem nome, algumas com uma propriedade date e outras com uma propriedade race_date — estaria dando um tiro em meu próprio pé (e no pé de todas as outras pessoas que alavancarem meu código).

É claro que ainda é possível usar JDO e JPA com o Google App Engine. Tendo usando tanto os modelos relacionais quanto o sem esquemas em projetos múltiplos, posso dizer que a API de baixo nível do Gaelyk é a mais flexível e divertida para se trabalhar. Uma outra vantagem de usar o Gaelyk é obter um entendimento melhor de armazenamentos de dados Bigtable e sem esquemas, no geral.

Leitores rápidos

A velocidade é um fator importante no argumento NoSQL versus relacional. Para um Web site moderno passando dados para, potencialmente, milhões de usuários (pense no crescente número de 400 milhões de usuários do Facebook), o modelo relacional é simplesmente muito lento, sem mencionar caro. Os armazenamentos de dados NoSQL, em comparação, são extremamente rápidos no que diz respeito a leituras.

Concluindo

Tendências vem e vão e, algumas vezes, é seguro ignorá-las (conselho sábio vindo de um rapaz com um guarda-roupa cheio de ternos antiquados). Mas o NoSQL se parece menos com uma tendência e mais como uma base emergente para o desenvolvimento de aplicativos da Web altamente escaláveis. No entanto, os bancos de dados NoSQL não substituirão o RDBMS; eles irão suplementá-lo. Uma grande quantidade de ferramentas e estruturas bem sucedidas residem sobre bancos de dados relacionais e os próprios RDBMSs parecem não correr risco de perder popularidade.
O que os bancos de dados NoSQL fazem é, finalmente, apresentar uma alternativa adequada ao modelo de dados objeto-relacional. Eles mostram que algo diferente é possível e — para casos de uso específico e altamente atrativo — melhor Bancos de dados sem esquemas são mais adequados para aplicativos da Web multinós que necessitam de recuperação de dados rápida e escalabilidade. Como um efeito colateral, eles estão ensinando desenvolvedores a abordarem a modelagem de dados a partir de uma perspectiva orientada ao domínio, ao invés de uma perspectiva relacional.