Arquitetura
Modernas base de dados relacionais parecem ter uma limitação a transações com grandes volumes de dados e cargas de trabalhos típicas de operações modernas de grande carga, incluindo o dimensionamento de conjuntos de dados. Sistemas NoSQL frequentemente fornecem garantias de consistência fraca, como consistência eventual e operações restritas a ítens individuais de dados, apesar que uma faixa pode impor garantias ACID, adicionando uma camada de middleware complememntares. Alguns defensores do NoSQL promovem interfaces muito simples, como [[arrays associativos] ou pares chave-valor (Key-Value pairs). Outros sistemas como bancos de dados XML nativos provem o apoio ao padrão XQuery.
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 umencontro 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.
O CouchDB é um dos mais famosos no time dos key-value stores. Ele usadocumentos para definir uma estrutura no banco, armazenando uma chave associada ao um documento. Um documento é apresentado como JSON. Por exemplo:
{
"Subject": "Bancos não relacionais"
"Author": "Nico Stepat"
"PostedDate": "10/15/2009"
"Tags": ["database", "nosql", "rest"]
}
Repare a estrutura dos dados é definido através da aplicação, o CouchDB não exige nada, apenas um documento JSON.
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:
Row-Oriented (3 rows presentes – Nome, Salário, Data):
João,1432.00,15/10/2009
Maria,1511.00,13/10/2009
Pedro,1721.00,01/10/2009
Column-Oriented (mesmo exemplo):
João,Maria,Pedro
1432.00,1511.00,1721.00
15/10/2009,13/10/2009,01/10/2009
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 alguma coisa? Para o desenvolvedor que vai utilizar o banco de dados, a idéia é que isso seja transparente, mas para que desenvolveu o banco, há enormes melhorias.
Isso não é muito vantajoso quando for salvo apenas um registro, como cada coluna tem que ser acessada 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.
Nenhum comentário:
Postar um comentário