[quote=andre_salvati][quote=kicolobo]
A propósito, tem algo de construtivo para adicionar a esta discussão?[/quote]
Já discutimos isso, ou vc esqueceu?
Eu tenho um banco com redundância e alta disponibilidade com mais 400 milhões de registros e 1TB de dados, não preciso de DBA e todas as minhas telas têm tempo de resposta na faixa de 1,5 seg. Devo muito disso ao NOSQL (BigTable do Google).
Vamos ser mais pragmáticos e parar de lero-lero.[/quote]
Na minha opinião esse é apenas mais 1 caso que deu certo em que outros milhares deram errado assim como no mundo SQL também existe seus casos de sucesso e suas falhas .
Não se pode comparar um buscador Google com uma rede social com um twitter com um ERP ou um blog . Um modelo não faz o outro ser melhor , nem anulam um ao outro , alias ao meu ver nem tem sentido essa bobeira de comparar um ao outro , já que a maioria de conceitos não são aplicáveis entre si ou são aplicáveis de um modo diferente . Tudo depende do que se quer fazer e de qual objetivo se quer atingir . Hoje em dia por experiencias boas e ruins utilizo o melhor dos 2 mundos ou seja EM CONJUNTO quando aplicáveis é lógico .
Um caso real pra agregar mais a discussão .
Desenvolvi uma rede social (não vem ao caso no momento qual é) em que 60% era registros básicos , 20% era buscas globais e 20% eram conexões em grafos . Na primeira semana atingi um numero alto de usuários cadastrados (isso porque estava liberado num versão beta só pra efeito de consulta de aceitação de mercado) e ai começaram os problemas já nesse começo .
Me arrependo profundamente de ter escolhido o GAE e um banco 100% NoSQL para o piloto . Deveria ter estudado melhor cada modulo e feito no modelo que melhor se aplicava e encaixava (pois sinceramente fui na onda do hype NoSQL e “achei” que não teria problema de qualquer tipo) e no meu caso o principal fator era e é ainda escalabilidade assim como garantia dos dados registrados . Alguns problemas que enfrentei :
- Era muito imaturo na época e não tinha quase nada de recurso ainda (FullTextSearch,etc) , hoje em dia é um pouco melhor .
- Fiquei totalmente preso a API deles em quase todas as features que precisava desenvolver . Ou seja quando pensei em migrar pra rodar em outro Cloud em varios cluster que escalava do mesmo jeito me vinha o pensamento do esforço gigantesco necessário para tal obra. Já que quase nada era compatível .
- Pra mim foi mais complicado e menos produtivo delegar quase 100% da responsabilidade para a aplicação se preocupar .
- Tarefas básicas que precisava realizar para fazer deploy de melhorias sempre acabava em código fonte pra rodar os map reduce e acertar ou melhorar algo no banco de dados . No mundo SQL com meia duzia de comandos eu faria a mesma coisa em muito menos tempo .
Hoje remontando e revendo e migrando aos poucos estou utilizando 3 modelos de banco de dados diferentes para um mesmo sistema . SQL e NoSQL chave-valor e grafos para as buscas e ligações da rede . Se amanha começar a trabalhar com alguma funcionalidade que envolva documentos já precisaria de outro modelo .
Um sistema nunca vai dar certo porque voce escolheu um banco de dados NoSQL X , se alguem pensa assim eu acho que esta se iludindo . Ele da certo porque o seu sistema e seu modelo de dados deve ser compatível em maior parte ou todo com um modelo NoSQL .
Fica ai meus 0,50 centavos de contribuição e vou enviar a fatura relativa a minha consultoria pro ABREU .
