Bancos de dados não relacionais e o movimento NoSQL | Alura Cursos Online
Bancos de dados não relacionais e o movimento NoSQL
6 min6 minutos de leitura
6 min6 minutos de leitura
Nas grandes aplicações web é cada vez mais comum a quantidade de informações ser enorme, e ainda temos uma certeza: amanhã teremos mais dados para armanezar. Como lidar com isso de maneira eficiente?
Muito se fala ultimamente sobre os novos bancos não relacionais. Houve um encontro inicial e a segunda conferência também já aconteceu. O movimento acabou ganhando o nome de NoSQL, até mesmo por que cada banco de dados tem uma maneira diferente de se escrever queries.
Muitos acham que esses bancos de dados escalam simplesmento por causa da ausência de um schema (schema free), logo não há verificação de integridade e de relacionamentos. Mas seria só isso? O MySQL, nos seus primórdios, quando não fazia tais verificações, ainda assim não era rápido como esses novos competidores. Quais são então os segredos para tanta escalabilidade?
O Amazon Dynamo se destacou por causa da forma como o sistema escala. Cada nó no cluster comunica com outros nós (p2p) e faz ativamente parte da partição/replicação. Não tem um single-point-of-failure, mas essa facilidade de escalar não vem sem custo.
Todos os novos bancos tem em comun que eles são key-value stores, ou seja salvam, como o nome sugere, um conjunto de enradas formadas por uma chave associada a um valor e o valor poderia ser de qualquer tipo, um binário ou string que está sendo salvo de forma denormalizada (schema-free). Diferentemente dos bancos SQL não existe uma esquema forte. Essa abordagem facilita a distribuição dos dados entre vários servidores onde cada servidor possui apenas uma fatia dos dados (shard).
O CouchDB é um dos mais famosos no time dos key-value stores. Ele usa _documento_s para definir uma estrutura no banco, armazenando uma chave associada ao um documento. Um documento é apresentado como JSON. Por exemplo:
Repare a estrutura dos dados é definido através da aplicação, o CouchDB não exige nada, apenas um documento JSON.
Talvez o CouchDB ficou famoso por causa da simples API REST e do uso do JSON, ou da interface grafica bonita ou por causa dos views interessantes usando Map-Reduce ou da replicaçãoMulti-Master ou por que foi escrito em Erlang (como esse e esse também). Seja que for, a promessa principal do NoSQL - sendo escalável - o CouchDB não compriu ainda. Ele não é distribuídosozinho, e precisa de ajuda externa para tal.
Outra forma de dar alguma estrutura aos dados ficou famosa por causa do Google Bigtable. A idéia é não salvar os dados em linhas como estamos acustomados pelos bancos relacionais. Os dados serão salvos através de colunas. Veja a diferença:
No column-oriented vem primeiro TODOS os dados da primeira coluna Nome, depois a segunda coluna Salario e por último a coluna Data.
E isso altera algma coisa? Para o desenvolvedor que vai utilizar o banco de dados, a idéia é que isso seja transparente, mas para quem desenvolveu o banco, há enormes melhorias.
Isso não é muito vantajoso quando for salvo apenas um registro, como cada coluna tem que ser accessada separadamente. Também complica mais na recuperação de um registro específico (random-access) pelo mesmo motivo. Aqui a abordagem row-oriented tem vantagens.
Por outro lado, usando colunas, podemos empacotar os dados melhor já que os dados semelhantes, de mesmo formato, estão próximos um do outro. Gravando dados empacotados em BDs traz grandes vantagens, porque podemos recuperar e armanezar mais informações em menos tempo.
Com colunas também podemos aplicar projeções sobre os dados mais fácil. A segunda vantagem é importante principalmente para sistemas OLAP (online analytic process) que usam esse tipo de pesquisas pesadamente.
Banco de dados orientados a coluna vão além de um simples key-value store. Eles representam normalmente um array/hash de 4 ou 5 dimensões, usando ou adaptando o modelo proposto pelo BigTable.
Primeiramente, também temos tabelas só que eles chamem column-families. Como o nome indica um column-family são váras colunas. Quais são essas colunas, a aplicação define.
Cada coluna salva um valor. O grupo de colunas dentro de uma familia é acessível atraves de uma chave (row-key). O esquema fica:
columnFamily - parecido com uma tabela (tabela de colunas)
rowKey - ID do grupo de colunas
column - nome da coluna
value - valor a salvar
.. =
Por exemplo, para apresentar dados sobre um DVD com a ID 234:
<usuarios_dvds>.<joao.silva>.<234> = 'data que ele comprou'
Normalmente é salvo uma data automaticamente, ou seja, a estrutura completa fica:
... =
Os bancos orientados a coluna não oferecem joins entre column-families nem chaves compostas. A Google AppEngine, por exemplo, não aceita chaves compostas porque usa o BigTable por baixo. Existem pequenas diferenças entre implementações orientadas a coluna.
Seria o "início do fim" dos bancos relacionais? Aderindo a um banco de dados não relacional muita da responsibilidade de cuidar dos dados fica a cargo da aplicação. É ela que define como funcionam e como se relacionam os documentos. O banco fica com certeza mais simples, escalavél e rápido, mas perdemos as conhecidas garantias dos bancos relacionais. Como toda decisão arquitetural, escolher por bancos de dados não relacionais apresenta um tradeoff: ACID ou BASE ou alguma coisa no meio. Vale a pena? Cada caso deve ser estudado com cuidado. Algumas aplicações usam bancos de dados não relacionais para uma leitura e escrita temporária, atualizando um banco relacional de tempos em tempos, tirando vantagem das duas estratégias.
Semana que vem, no Caelum Day in Rio conversaremos sobre muitos outros detalhes do movimento NoSQL. Nos encontramos lá!
