Evento NoSQL BR em São Paulo
Torna-se cada vez maior o movimento contra o uso de banco de dados relacionais. Ferramentas open sources como Voldemort, MongoDB, Tokyo Tyrant e CouchDB são conhecidas na comunidade.
Acontecerá em São Paulo no próximo dia 15 de maio o primeiro encontro brasileiro conhecido como NoSQL Brasil, que visa apresentar, promover e discutir as tecnologias “noSQL”. Para isso, serão realizadas palestras sobre as diversas abordagens noSQL com exemplos práticos e demonstrações, bem como um painel onde será discutido como e quando utilizar noSQL. (via infoq.com)
• Publicado por Augusto Campos em
2010-05-10
@brlinuxblog
Feed RSS
“Torna-se cada vez maior o movimento contra o uso de banco de dados relacionais.”
Interessante. Depois tem gente que diz que o “No” do nome na verdade seria “NO”, de “Not Only SQL”.
Mas para mim sempre quis dizer algo contra, porque é a intenção das pessoas ao falar do assunto.
Josh Berkus mandou muito bem a respeito do assunto aqui[1]:
“There are a lot of reasons to choose one database or another, but ignorance should not be one of them, and if someone can graduate with a CS degree and zero knowledge of comparative databases, we’re going to have a lot of really bad software over the next ten years.”
“Most of what is in the relational model and today’s SQL RDMBSes is designed to address these issues, and abandoning the relational model usually puts you at risk of repeating them. At the very least, you need to come up with a new mechanism for making sure you don’t. ”
As “issues” que ele se refere são:
# corrupt data
# inconsistent data
# duplicated data
# untrustworthy enforcement of data rules
# inability to make application changes without recreating the database
Entre outros trechos excelentes, como fazendo justiça ao MySQL :) .
[1] http://it.toolbox.com/blogs/database-soup/what-are-relational-databases-good-for-part-1-38129
Cara trabalho com bd a muitos anos, e desconheço este tal “movimento”, já vi muita gente comentado que o fuuro dos relacionais seriam os bd objeto-relacionais, mas o custo de migração dos legados tornariam inviaveis, por isso dizem que não “pegou”, não conheço os numeros, logo não posso dizer se é uma verdade ou não, o que vejo é muito “desenvolvedor” ruim no mercado que não sabe utilzar um banco relacional de forma decente, ai as reclamações sobre desempenho, um banco bem modelado, tunado e aplicações de front-end bem elaboradas, apenas isso e vc não precisa mais se preocupar com o modelo ralcional.
@Weber Jr. Sobre as “issues” elas também podem ocorrer com bancos de dados relacionais, só que nós já somos orientados desde os primeiros cursos a respeitar por exemplo a integridade relacional, ou seja, estamos acostumados.
Quando mudarmos para bancos noSQL, se este for o caso, uma grande responsabilidade da consistência dos dados vai para aplicação.
Nada mais justo!
Fico em dúvida o quanto esse movimento é tecnicamente válido, já que os sites que o usam são sites que contam com orçamento muito restrito e apostam em alternativas livres e gratuitas, como o MySQL (Facebook e Twitter).
Sei que muitos vão achar que é flame, mas eu realmente gostaria de ver o quanto um Oracle ou mesmo Postgres aguentariam o tranco nesse caso.
E concordo com o amigo acima, que em nome de robustez, o NoSQL é uma volta no tempo em termos de tudo que se estudou nos últimos 30 anos sobre o assunto.
Parabéns pelo iniciativa evento NOSql. Mas como um evento desse não tem na grade o Prevayler e o Prevalence? http://www.prevayler.org
Ta faltando o nome do Klaus e do Bambo nessa grade.
Não da para levar a sério um evento desse sem os dois pais da prevalência de objetos!!!
@rogerio, envie o seu curriculo pro twitter. Acredito fortemente que eles irão querer um profissional como vc, que faz “tunning” e “ajustes” e constroi “aplicativos de frontend bem elaborados”.
A hora é essa, cara. Prove que eles fizeram a escolha errada, quem sabe vc vira diretor do twitter.
@Igor
“Quando mudarmos para bancos noSQL, se este for o caso, uma grande responsabilidade da consistência dos dados vai para aplicação.”
E é bom ter as regras de negócio na aplicação ? Você deve estar pensando somente nas aplicações web, que as regras ficam no servidor de aplicações. Ou seja… centralizados lá.
E acho que pouca gente está “acostumada”. Tanto é assim que muita gente não sabe usar direito ou mesmo que existe chave estrangeira, stored procedure e triggers.
Ele falou disso, no mínimo, tudo isso vai precisar ser reimplementado. No pior caso, não vai ser feito e vamos voltar no tempo com problemas que não deveriam existir mais.
Por causa disso já vi alguns seres muito maldosos dizendo que esses bancos deveriam ser classificados como NoACID. Que isso sim descreveria muito melhor. Maldade, claro ;)
@henry
Twitter é aquele site que colocou no dicionário o termo “baleiar” de tanto que cai ?
Que vive tendo bugs como hoje(10/maio) que apavorou os usuários por fazer sumir seus followers?
Que criou esse bug ao tentar corrigir (mais) um furo grave de segurança ?
É devem estar precisando de muita gente para ajudar na performance mesmo.
@Weber Jr esse mesmo.
Se pra vc é fácil, vai lá e faz tbm. Não passe vontade, já que possui competência.
:D
@Weber Jr . Quando estudamos Orientação a objetos, aprendemos a construir classes de negócio e colocar as regras de negócio nestas.
Colocar regras de negócio em um banco de dados prejudica muito o projeto, principalmente no que diz respeito a portabilidade.
Já vi muitos projetos feitos em java, onde praticamente todas as regras de negócio estariam no banco de dados, mas não os considero orientados a objeto, muito menos seguindo DDD (Domain drive design).
Através disto chego a conclusão que pra um projeto ser bem sucedido utilizando noSQL ele tem que ter suas regras de negócio bem definidas no modelo de domínio da aplicação, seja ela WEB ou Desktop ou em Grade ou qualquer outra modalidade.
Ah, sobre chaves primárias e chaves estrangeiras elas não necessariamente precisam existir em bancos de dados noSQL. Por exemplo, no dbfo a gente não precisa de chave estrangeira, é sófazer uma agregaçao e ele mapeia o objeto direto na tupla. Mesmo com chave primária, mas no caso de substituição de chave primária, é necessário implementar um método que identifique o objeto. existem técnicas muito fáceis onde isto pode ser feito.
Eu utilizo muito bancos relacionais, em praticamente todos os projetos que trabalham, por questões de mercado, mas acho muito interessante principalmente pra quem trabalha com orientação a objetos os mecanismos dos banco de dados noSQL. Acho importante qualquer desenvolvedor que queria trabalhar em projetos de grande porte estar a par do assunto.
@Igor
“Acho importante qualquer desenvolvedor que queria trabalhar em projetos de grande porte estar a par do assunto.”
Concordo plenamente. E deixando claro, eu acho bem interessantes as propostas desses bancos novos.
O que não gosto é do maniqueísmo que tem surgido: BD relacional é podre e os NoSQL são perfeitos.
“Quando estudamos Orientação a objetos, aprendemos a construir classes de negócio e colocar as regras de negócio nestas.”
De uma visão distorcida (não é teu caso) do teu raciocínio, que é correto, que vem muito da fama desses NoSQL: OO é o correto, Banco relacional, não é OO, logo, é errado.
Alguns ORM como Hibernate, com sua visão centrada no Java, sem se preocupar com detalhes do Banco ajudaram a forjar essa visão, “jogando” as coisas no banco de qualquer modo.
“Colocar regras de negócio em um banco de dados prejudica muito o projeto, principalmente no que diz respeito a portabilidade.”
E se eu quiser portar a aplicação de Java para Python ? Vou conseguir tirar do JBoss as regras de negócio e jogar direto no Zope ?
Não né?!
É uma escolha que se tem a fazer, você pode deixar portável, mas perde por não usar os recursos que a plataforma te disponibiliza.
A questão de portabilidade mudou um pouco quando se passou a ter opções software livre. Diminuiu muito o pavor de ficar “amarrado”.
Também sou contra os “movimentos” e “guerras” quando surge uma nova tecnologia que deixa a anterior passar a ser a “errada” e agora veio a “certa”.
Quem é um pouco mais antigo no mercado de informática sabe muito bem que as tendências são cíclicas e o que é uma prática ruim hoje pode ser o padrão amanhã.
Banco relacional tem as suas limitações, mas para uma grande parte dos problemas ele resolve de maneira muito simples, rápida e eficiente. Pra outras aplicações mais específicas um banco OO pode ser melhor, pra outras um NOSQL seria melhor (no caso do Twitter e outros sites web ele mostrou-se melhor), mas ficar procurando “revoluções” a trouco de pouca coisa não agrega a nada.
Estive no ENSOL [1] semana passada e assisti alguns palestras que são pertinentes nessa discussão.
A proposta do MDA [2] é justamente tirar as regras de negócio da aplicação e colocar num modelo (UML [3] com OCL [4]) que será usado para gerar o código, ficando as regras de negócio tanto independente do banco de dados utilizado, quanto da linguagem com que se implementa a aplicação, esta será gerada com um “cartucho” específico para a liguagem/banco a serem utilizados. O AndroMDA [5][6] é um SL que implementa os conceitos do MDA.
[1] http://www.ensol.org.br/oevento/programacao-html
[2] http://pt.wikipedia.org/wiki/Model_Driven_Architecture
[3] http://pt.wikipedia.org/wiki/UML
[4] http://pt.wikipedia.org/wiki/OCL
[5] http://www.AndroMDA.com.br/
[6] http://www.AndroMDA.org/
Acho que não há ainda “cartuchos” para bancos NoSQL, mas creio que com tanta exposição que essas tecnologias estão tendo, quem sabe não teremos algo breve?
Quantos aos bancos NoSQL, acredito que seja um movimento contra (o SQL) mesmo, se bem que o pessoal insiste em salientar que nem todos as soluções casam bem com esse tipo de abordagem.
No encontro tb foi exposto os problemas dos bancos relacionais têm com a escalabilidade [7] horizontal, sendo que essa maneira de incrementar o poder de processamento é bem mais barata do que substituir servidores por outros com mais CPU, memória e disco (escalabilidade vertical). Como os bancos NoSQL são pensados para serem usados nesse tipo de ambiente têm-se então um casamento perfeito. Mas deve-se usar um banco NoSQL que sejá distribuido.
Me falta agora entender melhor que tipo de aplicações são melhores para se colocar nesse tipo de banco (estima-se que 10% das aplicações atuais ficariam melhor em bancos NoSQL).
Um banco que foi falado que me chamou mais atenção foi o Riak [8], que me pareceu atender melhor os requisitos (distribuido, possui balanceamento de carga, replicação, etc.).
[7] http://pt.wikipedia.org/wiki/Escalabilidade
[8] http://riak.basho.com/
Desde quando um banco normalizado significa ter as regras de negócios no banco? Só por aí dá pra ver o nível…