NoSQL, é seguro? Quais vantagens e desvantagens? Alguém ta usando?
NoSQL
G
94 Respostas
S
Eu tambem estou iniciando com mongoDB estou achando interessante. Pode ler esta Introducao sobre o mongoDB e este link
K
O grande lance do NoSql é apresentar opções ao modelo relacional, que virou o “martelo” (dê a uma criança um martelo e o mundo se torna um prego) do desenvolvimento, sendo aplicado a todas as situações, inclusive aquelas em que não se encaixa.
Com relação a segurança e tal, vai depender da tecnologia que você adotar. Não é raro um ou outro banco comprometer algum dos princípios do ACID em prol de algo. Mas nestes casos a documentação do produto já deixa, ou ao menos deveria, deixar isto explicito.
A pergunta que se deveria fazer aqui portanto é: o banco de dados X é seguro?
G
Estou começando em um projeto que a idéia é usar o MongoDB, eu semprei usei Oracle, Sql Serv e PostgreSql. Nem preciso falar da seguranca e da robustez do oracle. No sistema que implementei era mais de 30.00 registro dia só em uma tabela do banco.
Será que esse mongoDB é realmente seguro, ele tem controle das trasnsações etc etc etc?
A
Estou começando em um projeto que a idéia é usar o MongoDB, eu semprei usei Oracle, Sql Serv e PostgreSql. Nem preciso falar da seguranca e da robustez do oracle. No sistema que implementei era mais de 30.00 registro dia só em uma tabela do banco.
Será que esse mongoDB é realmente seguro, ele tem controle das trasnsações etc etc etc?
Vejo que cada banco Nosql é mais ou menos focado para resolver um tipo de problema em armazenamento.
Por que resolveu utilizar Mongo DB ?
G
Não fui eu, o projeto já está em andamento. Vamos trabalhar com muita imagem e precisamos de tempo de resposta. Mas pelo que estou vendo em alguns sites ele é seguro e rápido.
A
Imagino que está perguntando se é seguro no sentido de ser confiável né?
Que não vai perder seus dados?
Apesar de ser confiável, eu só alertaria para ler bem o manual antes de sair fazendo.
Semana sim, semana não, leio 1 post (em blogs) de alguém que começou a usar sem ler e se deu mal por algum motivo.
Tem muita coisa que a gente tem como garantida, em bancos relacionais, que não se aplicam em todos os bancos nosql.
Perguntei o motivo da escolha, justamente para saber se quem escolheu, conhece essas “pegadinhas”.
E respondendo uma das suas perguntas, até onde eu sei não existe o conceito de transação no mongodb.
Mas como você grava um documento, que pode representar um objeto inteiro, talvez não precise delas.
A
Bom ponto. Inclusive, operações JOIN também não são suportadas.
Bancos NoSQL lidam com um volume de dados a uma velocidade que faria qualquer banco relacional surtar!! Twitter, Google e Facebook que o digam. Mas, para que isso aconteça, eles podem não garantir o ACID por completo.
K
Mais que isto, é uma questão de saber quando usar um ou outro.
Por exemplo: uma base documental normalmente não tem esquema, isto é, os documentos não são obrigados a possuir um atributo ou outro.
Quando você usa? Quando sua modelagem gera num modelo relacional tabelas dispersas, isto é, aquelas em que há campos que pouquíssimas vezes são preenchidos e a presença destes campos não preenchidos é grande.
Baseado em grafos: quando você precisa tirar proveito de relacionamentos num nível muito mais complexo que no modelo relacional. Exemplo: relacionamentos em redes sociais.
Chave/Valor: quando você precisa buscar apenas pela chave e quer uma base de dados para cacheamento, envio de mensagens do tipo publicador/resposta, etc.
Nestes casos, você está lidando com situações que puxam demais o modelo relacional, tornando-o uma alternativa ruim.
Tirando isto, o modelo relacional é top, e já te atende bem.
Atualmente estou escrevendo um artigo sobre Redis e, neste processo, tenho lidado bastante com esta questão (quando usar, por que usar, etc). Isto deve gerar um post no meu blog, que posto aqui assim que acabar.
A
Mais que isto, é uma questão de saber quando usar um ou outro.
…Nestes casos, você está lidando com situações que puxam demais o modelo relacional, tornando-o uma alternativa ruim.
Tirando isto, o modelo relacional é top, e já te atende bem.
Atualmente estou escrevendo um artigo sobre Redis e, neste processo, tenho lidado bastante com esta questão (quando usar, por que usar, etc). Isto deve gerar um post no meu blog, que posto aqui assim que acabar.
Isto tem muito a ver com a questão de valor que você levantou aqui dias atrás.
Há um grande hype em cima dos bancos NoSql hoje em dia.
Muita gente vai querer usar, não por ser a melhor opção, mas por ser legal, pra conhecer, pra ganhar experiência.
E em algumas situações o modelo relacional poderia ter atendido tranquilamente.
Pra ficar claro, não estou dizendo que seja o caso do autor do tópico!
Há um vídeo que virou meme na internet, ironizando justamente essa situação:
A
Estou começando em um projeto que a idéia é usar o MongoDB, eu semprei usei Oracle, Sql Serv e PostgreSql. Nem preciso falar da seguranca e da robustez do oracle. No sistema que implementei era mais de 30.00 registro dia só em uma tabela do banco.
Será que esse mongoDB é realmente seguro, ele tem controle das trasnsações etc etc etc?
Nouussa, eu tenho mais de 20 milhões de registros só em uma entidade no meu NoSQL (Datastore do Google App Engine). Deve ser bastante… 
A pergunta não é “o banco X é mais seguro q o Y???”
A pergunta é " o banco X escala, é robusto e tem recursos que atendem aos requisitos de sua aplicação???"
F
O grande lance do NoSql é apresentar opções ao modelo relacional, que virou o “martelo” (dê a uma criança um martelo e o mundo se torna um prego) do desenvolvimento, sendo aplicado a todas as situações, inclusive aquelas em que não se encaixa.Com relação a segurança e tal, vai depender da tecnologia que você adotar. Não é raro um ou outro banco comprometer algum dos princípios do ACID em prol de algo. Mas nestes casos a documentação do produto já deixa, ou ao menos deveria, deixar isto explicito.
A pergunta que se deveria fazer aqui portanto é: o banco de dados X é seguro?
Mas o problema que ando vendo hoje em dia, é que estão transformando os NoSql em uma baita de uma marreta :shock:
Sério, até pra fazer um blog nego ta usando MongoDB, ok, se for pra aprender a tecnologia até concordo, mas acho que ja começaram os exageros, o hype!
Y
O grande lance do NoSql é apresentar opções ao modelo relacional, que virou o “martelo” (dê a uma criança um martelo e o mundo se torna um prego) do desenvolvimento, sendo aplicado a todas as situações, inclusive aquelas em que não se encaixa.Com relação a segurança e tal, vai depender da tecnologia que você adotar. Não é raro um ou outro banco comprometer algum dos princípios do ACID em prol de algo. Mas nestes casos a documentação do produto já deixa, ou ao menos deveria, deixar isto explicito.
A pergunta que se deveria fazer aqui portanto é: o banco de dados X é seguro?
Mas o problema que ando vendo hoje em dia, é que estão transformando os NoSql em uma baita de uma marreta :shock:
Sério, até pra fazer um blog nego ta usando MongoDB, ok, se for pra aprender a tecnologia até concordo, mas acho que ja começaram os exageros, o hype!
Cara, acho que eu to virando um fa dos hypes e fanboys, hehehe. Desde que longe das minhas orelhas com seus argumentos maravilhosos.
Eles forçam o alvo de suas paixoes ao extremo. Ótimo que NoSQL esteja virando marreta, assim ele será dilapidado e nós teremos mais chance de saber o que é prego e o que não é.
Eu estou bastante curioso com o NoSQL, mas ainda não tive coragem de por pra funcionar (muito por não saber onde ele se encaixa), e tambem não tive tempo para um projeto menor com ele. Eu espero ansiosamente a morte dos bancos relacionais, suas verdades milenares absolutas e suas mumias guardiãs. Mas tenho minhas duvidas se verei esse dia.
A
Eu estou bastante curioso com o NoSQL, mas ainda não tive coragem de por pra funcionar (muito por não saber onde ele se encaixa), e tambem não tive tempo para um projeto menor com ele. Eu espero ansiosamente a morte dos bancos relacionais, suas verdades milenares absolutas e suas mumias guardiãs. Mas tenho minhas duvidas se verei esse dia.
Isso garoto. Sempre duvide, seja curioso e questione “verdades absolutas”. É assim que a humanidade sempre evoluiu, evolui e evoluirá.
K
Publiquei no meu blog um post sobre os critérios que adoto na escolha de uma base de dados NoSQL.
Neste post incluo uma planilha que contém uma série de requisitos (funcionais ou não) que me guiam neste processo.
Talvez possa lhe ajudar: http://www.itexto.net/devkico/?p=1199
A
Publiquei no meu blog um post sobre os critérios que adoto na escolha de uma base de dados NoSQL.
Neste post incluo uma planilha que contém uma série de requisitos (funcionais ou não) que me guiam neste processo.
Talvez possa lhe ajudar: http://www.itexto.net/devkico/?p=1199
Achei sua planilha muito parcial, puxando sardinha para os relacionais…
Já no primeiro item vc dá a entender que transações só existem no mundo relacional, porém existem NoSQLs que possuem esses recursos.
Sua planilha também ignora itens fundamentais para quem acaba optando pelo uso de NoSQLs: produtividade e escalabilidade.
De qq maneira, caso alguém esteja interessado em uma análise mais profundas sobre o assunto, deixo a referência do livro mais recente do Martin Fowler.
Y
Publiquei no meu blog um post sobre os critérios que adoto na escolha de uma base de dados NoSQL.
Neste post incluo uma planilha que contém uma série de requisitos (funcionais ou não) que me guiam neste processo.
Talvez possa lhe ajudar: http://www.itexto.net/devkico/?p=1199Achei sua planilha muito parcial, puxando sardinha para os relacionais…
Já no primeiro item vc dá a entender que transações só existem no mundo relacional, porém existem NoSQLs que possuem esses recursos.
Sua planilha também ignora itens fundamentais para quem acaba optando pelo uso de NoSQLs: produtividade e escalabilidade.
De qq maneira, caso alguém esteja interessado em uma análise mais profundas sobre o assunto, deixo a referência do livro mais recente do Martin Fowler.
Dessa vez, tendo a concordar com o Andre. Achei que voce deu uma “pendida” pro lado do relacional. Mas como eu já disse, minha experiencia nesse assunto é só de leitura, alem de uma ou outra brincadeira com o Mongo.
ACID: Esse é uma aspecto muito relativo. Sempre quando eu penso em NoSQL eu costumo avaliar as aplicações com as quais eu trabalho e esse é um ponto que pesa. Mas o fato é que a imensa minoria, talvez nenhuma, aplicação com a qual eu trabalho precisa realmente do conceito ACID. E mesmo assim os DBAs arrancariam os cabelos se lessem isso aqui.
Sim, todas estas aplicações, sem exceção precisam estar dentro de uma transação e estarem consistentes após a operação. Mas tem que ser assim porque assim é o modelo relacional. Num banco documental, por exemplo, eu vou ter a mesma atomicidade dos meus dados, mas de forma diferente. Tudo num mesmo documento.
E nas pouquissimas situações em que a atomicidade entre documentos seria necessária eu tenho minhas dúvidas se o peso do banco relacional compensaria essa “segurança”.
Portabilidade: A portabilidade que você se refere é entre bancos do mesmo tipo? Se sim, você tem razão, bancos relacionais são mais portáveis entre si, mas entre si. De um relacional para um NoSQL, acho que a portabilidade seria dificil também.
Relatórios Gerenciais: Esse é o meu grande ponto de dúvida. Até que ponto eu consigo substituir a versatilidade do sql com esse novo paradigma? Eu sei que se eu forçar um SQL-Like em ambiente gigante de documentos eu saio perdendo. Mas há alternativas?
Integridade Referencial: Esta também acho uma afirmativa vaga. Em um mundo onde o pensamento sobre bancos de dados é relacional este quesito mata qualquer contra-argumento. Mas, de novo, ele é uma verdade somente dentro do paradigma relacional. Se você perguntar a qualquer um se integridade referencial é importante, ele vai dizer: “é lógico que é. Tá maluco??!!”
Mas será que a integridade referencial é que é importante ou é a implementação relacional que faz com que seja. Em muitas circunstâncias eu não preciso de integridade referencial porque eu não preciso da referência, eu tenho a própria informação, completa e íntegra, que por força das circunstâncias o mundo relacional me obriga a apenas referenciar.
Os outros tópicos não vou comentar ou por concordar ou por não ter conhecimento pra discordar.
E, concordando ou não, obrigado pelo post. Trouxe informação à discussão e coisas para eu pesquisar.
F
Qual seria o peso de um banco relacional?
Integridade Referencial: Esta também acho uma afirmativa vaga. Em um mundo onde o pensamento sobre bancos de dados é relacional este quesito mata qualquer contra-argumento. Mas, de novo, ele é uma verdade somente dentro do paradigma relacional. Se você perguntar a qualquer um se integridade referencial é importante, ele vai dizer: “é lógico que é. Tá maluco??!!”Mas será que a integridade referencial é que é importante ou é a implementação relacional que faz com que seja. Em muitas circunstâncias eu não preciso de integridade referencial porque eu não preciso da referência, eu tenho a própria informação, completa e íntegra, que por força das circunstâncias o mundo relacional me obriga a apenas referenciar.
Acho q nao entendi bem esta parte. Tem algum exemplo? Que tal o famigerado 1 Funcionario -> N Dependentes, ou algum outro que vc tenha em mente.
K
Opa, bacana que tenha pontos de discordância, sinal de que esta vai ser uma discussão das boas! 
Revendo esta planilha, da pra perceber que sim, há uma tendência em prol do modelo relacional. Fiquei aqui pensando um pouco a respeito, me auto avaliando e tal, e a conclusão que cheguei é a seguinte.
Fato: o modelo relacional ainda atende a maior parte das demandas, o que fica provado pelo seu sucesso no decorrer do tempo:
- Há um padrão que nos permite aprender de forma uniforme o modelo e, com isto, obter alguma (nunca total) independência de fornecedor.
- Na maior parte das vezes, estamos lidando com casos mais simples, cuja modelagem se encaixa bem em tabelas não esparsas e de fácil manipulação
Relendo a planilha, percebo que para cada requisito eu devia ter escrito um post, porque são situações que vão além de uma descrição tão básica. Mas vamos aos pontos que geraram mais dúvida.
-
Existência de transações: sem dúvidas, não queria passar esta impressão. No Neo4J por exemplo você sempre trabalha em uma transação. Varia de banco pra banco isto. Bom ponto.
-
Integridade referencial: parece ser um atributo apenas do modelo relacional, mas acaba se tornando em diversos casos um requisito funcional. Explicando melhor: sempre há uma entidade cujos dados serão compartilhados por outra(s). Registro/Documento/whatever que não queremos ver duplicado em inúmeros pontos do sistema porque sua manutenção se tornaria difícil. Imagine por exemplo um cadastro de funcionários no qual cada funcionário esteja relacionado a uma única empresa, gerando um “um para muitos” (cai no relacional de novo, eu sei).
Se fosse para implementar com o modelo documental, eu acabaria tendo de criar links entre meus documentos, e com isto perderia o que há de bacana neste modelo que é justamente a redundância de dados e o fato de não precisarmos fazer ligações. O mesmo pode ser dito do modelo chave/valor. O que mais chega próximo disto seria o baseado em grafos, mas neste caso teríamos uma integridade meio cambota, porque não é sempre que podemos obrigar a existência de uma aresta.
Sendo assim, do ponto de vista funcional, temos aqui um porquê do uso da integridade referencial. -
ACID: há casos em que precisamos ter a integridade da informação garantida por alguma tecnologia mais forte. No caso do modelo documental, tudo bem que salvo tudo em uma única transação ao incluir tudo em um único documento. O problema é: e quando preciso tocar diversos documentos? E quando precisamos ter a certeza de que o dado foi inteiramente persistido? Entra aqui também mais do que a persistência, temos a questão da atomicidade e do isolamento. O melhor exemplo - e infelizmente o mais distante de nós - é o de transações bancárias, mas já trabalhei em algumas situações dentro da telecom em que ACID se mostrou fundamental. Talvez um ACID completo com documental fosse o perfeito para estes casos, mas infelizmente com os bancos que temos, não podemos ter esta certeza sempre.
A
Não, isso não é fato, é opinião. Curioso que vc sequer cita o maior NoSQL (e provavelmente o maior banco de dados) do planeta no seu blog, a saber, o Datastore do App Engine.
Quantos projetos vc já fez para migrar de fornecedor de banco?? Em 12 anos de experência eu nunca fiz. Acredite, no fundo, no fundo, isso não é importante e no mundo SQL tb existem problemas de vendor lock-in.
NoSQL (pelo menos o que eu uso) é mais simples, mais produtivo e mais escalável do que SQL.
Eu ainda acho que receitas de bolo (ou planilhas dizendo melhor aqui, pior ali) não funcionam em projetos de TI. O que conta é conhecimento e experiência…
Y
Voce ter toda a estrutura do teu modelo duplicada num banco de dados, com todas as suas gambiarras/mapeamento para que esta estrutura se encaixe ao modelo relacional.
Sim, assim como num modelo OO, um funcionario tem N dependentes e não N chaves estrangeiras apontando para dependentes. Quando voce guarda o seu funcionario, guarda junto com ele os seus dependentes.
Se voce estava se referindo a relacao entre funcionarios de cargos distinto, como o funcionario gerente e o funcionario operador, talvez então ele se encaixe no outro topico do kikolobo. Naquele em que diz que redundancia eh um problema. E nesse caso entao o uso do banco relacional seja mais efetivo.
K
Oi André,
no caso, eu não citei o Datastore da App Engine porque no post estou dizendo minha vivência no assunto. Nunca trabalhei com ele, desculpa. 
Sobre migração de bancos de dados, diversos. É muito comum por exemplo no desenvolvimento de produtos, em que você precisa fazer adequações para que se encaixe à infra do cliente (sim, acontece).
André, agora, com relação à produtividade: de que maneira os bancos NoSQL aumentam a sua?
No caso, a produtividade não viria mais da adequação do seu modelo ao mecânismo de persistência que você adotou?
Y
Concordo, mas como postei no outro comentario, esse caso se encaixa mais na necessidade de evitar dados duplicados. No exemplo de funcionario/cargos, acho que, a primeira vista, o modelo relacional atende melhor. Mas talvez estas sejam exceções e não regras.
Será que tambem essas situações de transação entre documentos não são mais excepcionais do que podem parecer a principio? Transacao bancaria é um exemplo clássico que pede controle rigoroso de transação, você citou mais uma com a qual teve experiência. Será que há tantas assim que de tão importante não poderiam ser ficar confiadas apenas a aplicação?
A mim parece, assim como o quesito de integridade referencial, que os bancos relacionais seriam usados nas exceções e não nas regras.
Só pra situar quem chega ao tópico. Tudo que eu falo é baseado apenas no que tenho lido, não tenho a menor experiência com bancos NoSQL, embora esteja querendo dar uma olhada “mais de perto”.
K
Oi YvGa, interessantíssimo o seu post. Quero entender melhor isto. Me explica duas coisas:
Neste caso, o problema não seria do modelo relacional, mas sim de quem fez a análise errada e optou pelo modelo equivocado? O peso aí estaria em quem fez a escolha errada, não?
Um outro ponto que eu acho interessante é o seguinte: vejo muita gente cometendo o erro de no modelo documental ter documentos gigantescos cuja extração e manutenção acaba ficando bastante cara.
Nestes casos, o sujeito acaba quebrando o documento em mais de um e em seguida linkando-os, como o faria no modelo relacional.
Nesta situação, não seria mais negócio ir para o modelo relacional? Qual o limite do documental na sua opinião?
K
Para enriquecer a discussão, sugiro a leitura deste artigo: “The Cost of Data”.
É muito interessante, porque trata justamente do custo da informação semi definida (aonde entra o NoSQL e sai o SQL).
Basicamente o autor mostra que informação não estruturada vale à pena ser mantida como tal e que a tipificação normalmente só adiciona custo desnecessário e acréscimo de complexidade.
Link: http://queue.acm.org/detail.cfm?id=1103843
K
Oi de novo YvGa,
De novo, acho que não sejam situações tão excepcionais assim estas nas quais é preciso lidar com mais de um documento. Em sistemas complexos, em que exista a integração de entidades entre si, estas acabam ocorrendo.
Além disto, é importante mencionar também que indiferente de ser com um ou dois documentos, outro ponto importante a ser lembrado é o da isolabilidade. Será que conseguimos garantir sempre a isolabilidade no modelo NoSQL (eu sei que cada caso é um)? Este é um ponto que a gente tem de ter em mente sempre.
Tudo bem: pode ser raro mais de um cliente acessando e modificando o mesmo documento, porém quando você para pra pensar em uma empresa composta por departamentos, cada qual com mais de um funcionário - que normalmente estão lidando com a mesma coisa - o negócio se torna bem mais comum.
Y
Sobre migração de bancos de dados, diversos. É muito comum por exemplo no desenvolvimento de produtos, em que você precisa fazer adequações para que se encaixe à infra do cliente (sim, acontece).
Concordo nesse ponto, eu já precisei fazer ao menos tres grandes migrações de bases de dados por que o cliente já possuia licença de outra empresa. E em tres empresas diferentes. Então acho que esse é um ponto a ser considerado sim, na adoção ou não de NoSQL.
André, agora, com relação à produtividade: de que maneira os bancos NoSQL aumentam a sua?
No caso, a produtividade não viria mais da adequação do seu modelo ao mecânismo de persistência que você adotou?
Mas é essa adequação o grande problema dos bancos relacionais. É dificil, trabalhosa, manual e com workarounds (como mapeamento de heranca, lazy loading por conta de chaves estrangeiras, utilizar linguagens quase sql ao invés de sql puro, entre outras gamiarritas mas).
K
Oi YvGa, concordo com você.
Na realidade, o grande ganho que o NoSQL trouxe na minha opinião foi o fato de ter nos acordado pro fato de que estávamos usando o modelo relacional como a solução para todos os problemas, o que, para qualquer tecnologia, não é verdade nunca.
Eu sou a favor de uma abordagem mais híbrida, na qual mais de um modelo (relacional ou não) sejam aplicados, um em cada caso. Assim a gente evita transformar um modelo específico, por exemplo, o documental, no “relacional de amanhã”, entende?
A
Sobre migração de bancos de dados, diversos. É muito comum por exemplo no desenvolvimento de produtos, em que você precisa fazer adequações para que se encaixe à infra do cliente (sim, acontece).
Concordo nesse ponto, eu já precisei fazer menos tres grandes migrações de bases de dados por que o cliente já possuia licença de outra empresa. E em tres empresas diferentes. Então acho que esse é um ponto a ser considerado sim, na adoção ou não de NoSQL.
Srs, uma coisa é IMPLANTAR um produto em diversos clientes que usam fornecedores de banco diferentes. Outra coisa é MIGRAR um banco pq um cliente, a partir de agora, quer em banco X e não mais em banco Y. A segunda situação ocorre com bastante raridade.
Seria ingenuidade acreditar que vc não tem que lidar com vendor lock-in, mesmo sendo migração SQL -> SQL.
K
Sobre migração de bancos de dados, diversos. É muito comum por exemplo no desenvolvimento de produtos, em que você precisa fazer adequações para que se encaixe à infra do cliente (sim, acontece).
Concordo nesse ponto, eu já precisei fazer menos tres grandes migrações de bases de dados por que o cliente já possuia licença de outra empresa. E em tres empresas diferentes. Então acho que esse é um ponto a ser considerado sim, na adoção ou não de NoSQL.
Srs, uma coisa é IMPLANTAR um produto em diversos clientes que usam fornecedores de banco diferentes. Outra coisa é MIGRAR um banco pq um cliente, a partir de agora, quer em banco X e não mais em banco Y. A segunda situação ocorre com bastante raridade.
Seria ingenuidade acreditar que vc não tem que lidar com vendor lock-in, mesmo sendo migração SQL -> SQL.
Oi André, discordo. A segunda alternativa ocorre com bastante frequencia também.
Anos atrás, por exemplo, era muito comum o pessoal que precisava gastar bastante com licença em Oracle fazer migrações para o MySQL, PostgreSQL, etc. Eu mesmo cheguei a participar de algumas situações assim.
Porém, nesta discussão, até agora ninguém falou da segunda opção, mas mais da primeira mesmo. Que o padrão SQL não é igual em todos os bancos, isto todo mundo já sabe, prova disto são os dialetos no Hibernate, porém é uma situação mais gerenciável do que a que encontramos no ambiente NoSQL.
A
Oi André,no caso, eu não citei o Datastore da App Engine porque no post estou dizendo minha vivência no assunto. Nunca trabalhei com ele, desculpa.
Quando o assunto é NoSQL, qq generalização é falha.
André, agora, com relação à produtividade: de que maneira os bancos NoSQL aumentam a sua?
No caso, a produtividade não viria mais da adequação do seu modelo ao mecânismo de persistência que você adotou?
O principal motivo é pq o banco é schema free. Não preciso me preocupar com inclusões de campos em tabelas, migrações de bd, etc. Isso libera tempo e recursos para focarmos em melhorias de funcionalidade da app.
Dá uma olhada na primeira parte dessa entrevista, o carinha explica bem isso:
M
BREAKING NEWS
Posso só dar um comentário simples? É que falaram de redes sociais… no último QCon SP teve uma palestra sobre o Facebook… e aí foi dito que eles usavam MySql em uma gambiarra para fingir que era NoSql (concatenando todos os campos numa stringona)
pronto, podem voltar a falar de migração. Aliais, acrescentando um ponto de vista:
uma vez numa empresa tive que migrar de um banco MySql para um Oracle, porque o cliente quis. Motivo? Funcionários de TI do cliente chegaram a conclusão que seria mais seguro (ahn?? com base no que? precisam assim de tanto grau de segurança?) e houve algumas semanas de trabalho por causa de registros (imagina, usavam windows server. Já viu né?) e boa parte do trabalho foi por causa da ferramenta de ORM mesmo).
Bacana. Mas…daria trabalho, dependendo de como você tinha trabalhado antes e como vai trabalhar depois, de qualquer forma. Então acho que não é válido a idéia de que “NoSql dá trabalho para migrar”. Vai dar trabalho. Tudo. Okay, pode dar até um pouco de trabalho a mais, mas, acho que nem vai ocorrer mudanças de banco a toda hora. Imagino que se você está usando NoSql você sabe melhor o que está fazendo e para o que vai precisar, logo não vai ter problemas como os que eu tive em que o cliente achou mais seguro e quis mudar. Creio que você vai ter mais controle da situação, não?
A
BREAKING NEWS
Posso só dar um comentário simples? É que falaram de redes sociais… no último QCon SP teve uma palestra sobre o Facebook… e aí foi dito que eles usavam MySql em uma gambiarra para fingir que era NoSql (concatenando todos os campos numa stringona)
Twitter e Google tb usam NoSQL. Engraçado, os que mais escalam…
Isso mesmo. Até para atualizar uma app é infinitamente mais fácil com o NoSQL devido às características q mencionei no post anterior.
K
Mas ai que tá André e Mayumi, migração é só um detalhe na hora de escolher.
É um entre diversos critérios que o arquiteto/desenvolvedor/whatever tem de levar em consideração no momento de escolha da base.
Mas aí eu te cutuco de novo André: você acha que todo modelo pode ser usado pelo documental então? Neste caso, você não estaria repetindo o erro de estar usando uma única solução para tudo?
Em quais casos o documental pularia fora na sua opinião? Em que situações o relacional seria uma boa pra você?
A
Mas aí eu te cutuco de novo André: você acha que todo modelo pode ser usado pelo documental então? Neste caso, você não estaria repetindo o erro de estar usando uma única solução para tudo?
Em quais casos o documental pularia fora na sua opinião? Em que situações o relacional seria uma boa pra você?
Não há bala de prata em desenvolvimento de SW.
Cada caso é um caso e deve ser analisado detalhamente, o que fica difícil em um fórum de discussões.
Só discordo de receitinhas de bolo para tomada de decisões.
K
Mas aí eu te cutuco de novo André: você acha que todo modelo pode ser usado pelo documental então? Neste caso, você não estaria repetindo o erro de estar usando uma única solução para tudo?
Em quais casos o documental pularia fora na sua opinião? Em que situações o relacional seria uma boa pra você?Não há bala de prata em desenvolvimento de SW.
Cada caso é um caso e deve ser analisado detalhamente, o que fica difícil em um fórum de discussões.
Só discordo de receitinhas de bolo para tomada de decisões.
André, que não há bala de prata, isto todo mundo já sabe né?
Vou melhorar minha pergunta: na sua opinião/experiência, já topou com situações em que o modelo documental não fosse bacana? Este tipo de experiência seria muito bacana pra enriquecer a discussão. NO entanto, apesar de cada caso ser um caso, sempre há alguma diretriz que você leva em consideração na sua escolha não?
A
São várias diretrizes e é mais provável que decisões políticas afetem mais as decisões técnicas do que o inverso.
Coloca o seu caso atual aí para analisarmos…
K
Sem esquivar André
Não teve nenhum caso até hoje em que o modelo relacional não se aplicava melhor pra você? Nenhuma experiência?
A
Sem esquivar AndréNão teve nenhum caso até hoje em que o modelo relacional não se aplicava melhor pra você? Nenhuma experiência?
Até tem, mas aí já vira consultoria…
H
Ou então parece que alguém não quer dar o braço a torcer…Sem esquivar AndréNão teve nenhum caso até hoje em que o modelo relacional não se aplicava melhor pra você? Nenhuma experiência?
Até tem, mas aí já vira consultoria… ;)
Desculpe entrar no meio, mas estou acompanhando e foi isso que me pareceu… ^^
K
Sem esquivar AndréNão teve nenhum caso até hoje em que o modelo relacional não se aplicava melhor pra você? Nenhuma experiência?
Até tem, mas aí já vira consultoria… ;)
Ara André!
Não é consultoria man, é só pra enriquecer a discussão, ver os casos mais interessnates justamente pro pessoal poder ter uma compreensão melhor sobre o assunto.
Faz uma forcinha aí vai!
D
Sem esquivar AndréNão teve nenhum caso até hoje em que o modelo relacional não se aplicava melhor pra você? Nenhuma experiência?
Até tem, mas aí já vira consultoria… ;)
andre_salvati uses flee.
A
Ou então parece que alguém não quer dar o braço a torcer…Sem esquivar AndréNão teve nenhum caso até hoje em que o modelo relacional não se aplicava melhor pra você? Nenhuma experiência?
Até tem, mas aí já vira consultoria… ;)
Desculpe entrar no meio, mas estou acompanhando e foi isso que me pareceu… ^^
Eu estava justamente escrevendo algo parecido aqui…saídas pela tangente…
Cada caso é um caso e deve ser analisado detalhamente, o que fica difícil em um fórum de discussões.[…]
Coloca o seu caso atual aí para analisarmos…
[…]
Até tem, mas aí já vira consultoria
A
Ou então parece que alguém não quer dar o braço a torcer…Sem esquivar AndréNão teve nenhum caso até hoje em que o modelo relacional não se aplicava melhor pra você? Nenhuma experiência?
Até tem, mas aí já vira consultoria… ;)
Desculpe entrar no meio, mas estou acompanhando e foi isso que me pareceu… ^^
Já disse que não existe BALA DE PRATA.
SQL ainda é válido em alguns casos, mas seria bom considerarem seriamente uma solução NoSQL no seu próximo projeto.
Não sabe avaliar se é melhor ou não?? Chame quem já apanhou para dar uma ajuda…
A
Ou então parece que alguém não quer dar o braço a torcer…Sem esquivar AndréNão teve nenhum caso até hoje em que o modelo relacional não se aplicava melhor pra você? Nenhuma experiência?
Até tem, mas aí já vira consultoria… ;)
Desculpe entrar no meio, mas estou acompanhando e foi isso que me pareceu… ^^
Já disse que não existe BALA DE PRATA.
SQL ainda é válido em alguns casos, mas seria bom considerarem seriamente uma solução NoSQL no seu próximo projeto.
Não sabe avaliar se é melhor ou não?? Chame quem já apanhou para dar uma ajuda…
Ou usa a planilha do colega aí…kkkkk
H
Ou então dê uma resposta evasiva… -_-’’Ou então parece que alguém não quer dar o braço a torcer…Sem esquivar AndréNão teve nenhum caso até hoje em que o modelo relacional não se aplicava melhor pra você? Nenhuma experiência?
Até tem, mas aí já vira consultoria… ;)
Desculpe entrar no meio, mas estou acompanhando e foi isso que me pareceu… ^^
Já disse que não existe BALA DE PRATA.
SQL ainda é válido em alguns casos, mas seria bom considerarem seriamente uma solução NoSQL no seu próximo projeto.
Não sabe avaliar se é melhor ou não?? Chame quem já apanhou para dar uma ajuda…
Ou usa a planilha do colega aí…kkkkk
K
Bom gente, andando por pisos mais sólidos, alguém aqui já experimentou problemas interessantes com bases NoSQL que acabaram por fazerem voltar a avaliar o modelo relacional como solução?
É interessante termos este tipo de situação pra podermos discutir e entender melhor a questão.
M
Ou então parece que alguém não quer dar o braço a torcer…Sem esquivar AndréNão teve nenhum caso até hoje em que o modelo relacional não se aplicava melhor pra você? Nenhuma experiência?
Até tem, mas aí já vira consultoria… ;)
Desculpe entrar no meio, mas estou acompanhando e foi isso que me pareceu… ^^
Já disse que não existe BALA DE PRATA.
SQL ainda é válido em alguns casos, mas seria bom considerarem seriamente uma solução NoSQL no seu próximo projeto.
Não sabe avaliar se é melhor ou não?? Chame quem já apanhou para dar uma ajuda…
Ou usa a planilha do colega aí…kkkkk
Ou vai na sorte #flame
M
Bom gente, andando por pisos mais sólidos, alguém aqui já experimentou problemas interessantes com bases NoSQL que acabaram por fazerem voltar a avaliar o modelo relacional como solução?É interessante termos este tipo de situação pra podermos discutir e entender melhor a questão.
Na verdade, Kiko grande mestre, só usei NoSql duas vezes: um era graphos porque eu precisava travalhar com relacionamentos em um lvl muito profundo, ficar indo e vindo pelas relações. Aí achei que era uma boa idéia. A segunda opção foi por que eu fiz um mini crawler e não vi motivos para usar sql, e pq ficava na nuvem e tal, “na nuvem é mais simples noSql” e tal.
Em todos os outros casos da minha loooonga vida de dev eu sempre vi Sql como uma boa saida e sem motivos para não usar.
PS: tenho só 21 anos e 3 de carreira, não passei por muitas coisas assim
F
Qual seria o peso de um banco relacional?
Voce ter toda a estrutura do teu modelo duplicada num banco de dados, com todas as suas gambiarras/mapeamento para que esta estrutura se encaixe ao modelo relacional.
Sim, assim como num modelo OO, um funcionario tem N dependentes e não N chaves estrangeiras apontando para dependentes. Quando voce guarda o seu funcionario, guarda junto com ele os seus dependentes.
Se voce estava se referindo a relacao entre funcionarios de cargos distinto, como o funcionario gerente e o funcionario operador, talvez então ele se encaixe no outro topico do kikolobo. Naquele em que diz que redundancia eh um problema. E nesse caso entao o uso do banco relacional seja mais efetivo.
Mas mesmo no modelo OO, os dependentes estão numa estrutura separada, no caso um List, e o BD no caso esta em uma tabela a parte, até existe alguns BD’s que tem o tipo Array, só não sei se é conveniente usar.
Sobre lazy loading, bom, lazy tem seus motivos, performance, trafego de dados, etc, e creio que esta questão é inerente a ser relacional ou não, por exemplo em um MongoDB da vida, como ficaria? SEMPRE que puxarmos um Funcionario ou uma NotaFiscal, todos os dependentes/itens virão?? Independente se vamos usar naquele momento ou não? Imagina alguma coisa com 100 dependentes, como ficaria isto ja que esta tudo mo mesmo Documento?
A
Bom gente, andando por pisos mais sólidos, alguém aqui já experimentou problemas interessantes com bases NoSQL que acabaram por fazerem voltar a avaliar o modelo relacional como solução?É interessante termos este tipo de situação pra podermos discutir e entender melhor a questão.
Apenas para complementar, eu gostaria de fazer a pergunta inversa :
Quais foram os problemas que já enfrentaram com bancos relacionais que foram resolvidos com NoSql ?
Eu não cheguei a implementar projetos com NoSQL, mas vi o Sql patinar quando precisei:
-
Controlar hierarquia de auto-relacionamento, como responder quem é o chefe do chefe do chefe…
-
Atributos variáveis e opcionais para as mesmas entidades ( a tabela esparsa que é citada no post).
Utilizar aquela técnica de EAV costuma causar graves problemas de performance.
K
Bom gente, andando por pisos mais sólidos, alguém aqui já experimentou problemas interessantes com bases NoSQL que acabaram por fazerem voltar a avaliar o modelo relacional como solução?É interessante termos este tipo de situação pra podermos discutir e entender melhor a questão.
Apenas para complementar, eu gostaria de fazer a pergunta inversa :
Quais foram os problemas que já enfrentaram com bancos relacionais que foram resolvidos com NoSql ?Eu não cheguei a implementar projetos com NoSQL, mas vi o Sql patinar quando precisei:
Controlar hierarquia de auto-relacionamento, como responder quem é o chefe do chefe do chefe…
Atributos variáveis e opcionais para as mesmas entidades ( a tabela esparsa que é citada no post).
Utilizar aquela técnica de EAV costuma causar graves problemas de performance.
Abel, EXCELENTE pergunta.
Vamos às respostas:
Eu constantemente passo por um problema (que inclusive ilustrei no meu post http://www.itexto.net/devkico/?p=1199) que é o de ter tabelas muito esparsas no banco de dados.
O que acontecia: eu precisava lidar com diversos registros pertencentes a um determinado tipo (equipamento pra ilustrar), e que eram salvos em uma base relacional.
Problema: cada um com seus próprios tipos de atributo e, pra piorar, que podiam variar o tempo inteiro. Então surgiam colunas que eram usadas em, por exemplo, um registro.
Pra resolver o problema, a outra abordagem seria criar uma estrutura muito complicada envolvendo meta-informações, contendo quais os campos que cada tipo de equipamento tinha… Uma meleca.
E o interessante é que temos um software gigantesco (Smartplant, da Intergraph) que funciona exatamente assim: tabelas ultra esparsas, com milhões de registros nos quais há colunas usadas por um, dois registros.
O modelo documental sem esquema resolveu o problema, porque assim eu podia armazenar todos os atributos que eu quisesse para cada equipamento de uma forma muito mais simples e fácil. E com a vantagem de que não precisava de joins complicados e este tipo de monstruosidade.
Outro caso em que o modelo relacional se mostrou limitado para mim (e ainda se mostra) diz respeito a soluções nas quais eu precise lidar com grafos. Por exemplo: um sistema de comissionamento. Comissionamento é o processo de teste de todos os equipamentos que vão fazer parte de uma planta. Para que a planta funcione direito, é necessário que seus dependentes também estejam ok, e por aí vai.
No modelo relacional representar grafos é bastante complicado. Questões do tipo: “me mostre as dependências de suas dependências” é complicado de implementar.
Usando o Neo4J, baseados em grafos, fica banal.
Como pode ver, são questões em que o seu domínio não é bem representado pelo relacional, ou seja, naqueles casos em que você vai além da visão bidimensional da tabela, ou que precisaria de tantas junções pra obter o mesmo resultado que simplesmente não justifica.
No entanto, em minha experiência estes se mostraram casos raros, bem raros mesmo infelizmente. Pra todos os outros, existe o relacional (desculpa MasterCard).
A
Bom gente, andando por pisos mais sólidos, alguém aqui já experimentou problemas interessantes com bases NoSQL que acabaram por fazerem voltar a avaliar o modelo relacional como solução?É interessante termos este tipo de situação pra podermos discutir e entender melhor a questão.
Apenas para complementar, eu gostaria de fazer a pergunta inversa :
Quais foram os problemas que já enfrentaram com bancos relacionais que foram resolvidos com NoSql ?Eu não cheguei a implementar projetos com NoSQL, mas vi o Sql patinar quando precisei:
Controlar hierarquia de auto-relacionamento, como responder quem é o chefe do chefe do chefe…
Atributos variáveis e opcionais para as mesmas entidades ( a tabela esparsa que é citada no post).
Utilizar aquela técnica de EAV costuma causar graves problemas de performance.
Eu gostaria muito de ter usado NoSQL neste cenário:
1- Dados eram consumidos de um webservice externo
2- Os dados eram gravados em um schema do banco
3- Posteriormente, esses dados gravados eram convertidos para um outro schema do banco a fim de alimentar um sistema legado
O passo 2 poderia ser feito com uma base usando Document pois o webservice mandava dados que não seguiam um formato bem definido para termos um schema confável. Por causa disso, toda hora precisávamos fazer alterações no schema. Sem contar os relacionamentos que vinham furados porque os dados estavam incompletos em alguns casos. Tínhamos tabelas com mais de 50 campos onde somente 3 ou 4 eram preenchidos, tabelas que nunca eram populadas, e por aí vai…
Talvez tenha sido melhor efetuar as conversões no momento do acesso ao webservice (é aquela velha história de “quando eu cheguei estava assim, só terminei a bagaça”) mas é um exemplo de uso do NoSQL.
A
No modelo relacional representar grafos é bastante complicado. Questões do tipo: “me mostre as dependências de suas dependências” é complicado de implementar.
Usando o Neo4J, baseados em grafos, fica banal.
Me veio à cabeça, com esse exemplo, os gerenciadores de pacotes do Linux.
K
No modelo relacional representar grafos é bastante complicado. Questões do tipo: “me mostre as dependências de suas dependências” é complicado de implementar.
Usando o Neo4J, baseados em grafos, fica banal.Me veio à cabeça, com esse exemplo, os gerenciadores de pacotes do Linux.
Boa!
Y
Sobre lazy loading, bom, lazy tem seus motivos, performance, trafego de dados, etc, e creio que esta questão é inerente a ser relacional ou não, por exemplo em um MongoDB da vida, como ficaria? SEMPRE que puxarmos um Funcionario ou uma NotaFiscal, todos os dependentes/itens virão?? Independente se vamos usar naquele momento ou não? Imagina alguma coisa com 100 dependentes, como ficaria isto ja que esta tudo mo mesmo Documento?
Sim, vem todos pra memoria. Pra que isso representasse realmente algum peso para aplicação precisariam milhoes e milhoes de dependentes/itens.
O lazy não é exatamente para que eu não traga os dependentes/itens de um funcionario/nota, mas para que eu não suba o banco inteiro pra memoria em uma consulta por id. Porque a nota tem os itens, os itens se relacionam aos produtos, os produtos, às categorias. A nota ao cliente, o cliente ao bairro, às formas de pagamento, às faturas vencidas, às por vencer, a outras notas.
Para isso existe o lazy load. Não para que eu economize e não traga alguns filhos, coisa que muito dificilmente vai fazer diferença, usando-os ou não.
A
Olá amiguinhos,
já tentaram uma ajudinha do Google??
É engraçado como o brasileiro gosta de discutir as coisas sem fundamentos.
R
Olá amiguinhos,já tentaram uma ajudinha do Google??
É engraçado como o brasileiro gosta de discutir as coisas sem fundamentos.
Bom, você estava aqui discutindo até que te apertaram na parede e você não conseguiu mais escapar.
Até lá não era sem sentido?
O motivo do tópico não é porque não existem outras fontes de informação, todo mundo sabe que uma busca no google traz muitos resultados.
A ideia aqui é justamente ouvir opiniões de pessoas diferentes (enquanto em um blog, você lê a opinião de um), discutir experiências e (para aqueles que conseguem) aprender algo com tudo isso.
O fórum é livre pra quem quiser entrar, e do mesmo jeito, é livre pra quem quiser sair.
A
Olá amiguinhos,já tentaram uma ajudinha do Google??
É engraçado como o brasileiro gosta de discutir as coisas sem fundamentos.
Bom, você estava aqui discutindo até que te apertaram na parede e você não conseguiu mais escapar.Até lá não era sem sentido?
O motivo do tópico não é porque não existem outras fontes de informação, todo mundo sabe que uma busca no google traz muitos resultados.A ideia aqui é justamente ouvir opiniões de pessoas diferentes (enquanto em um blog, você lê a opinião de um), discutir experiências e (para aqueles que conseguem) aprender algo com tudo isso.
O fórum é livre pra quem quiser entrar, e do mesmo jeito, é livre pra quem quiser sair.
Vai treinando aqui no fórum. Vc vai ficar bom em NoSQL…
R
Opa, obrigado pela dica!
K
Bem, voltando ao que realmente importa no tópico, e chave/valor gente, já usaram?
Em 2010 eu tive uma experiência muito bacana com o memcached, e neste estou usando Redis.
Ambos se mostraram ferramentas maravilhosas para cacheamento e acesso rápido a informações que mudam muito rápido.
No caso do redis da inclusive pra implementar um sistema de mensageria no estilo JMS.
Alguma experiência bacana?
Y
Bem, voltando ao que realmente importa no tópico, e chave/valor gente, já usaram?
Em 2010 eu tive uma experiência muito bacana com o memcached, e neste estou usando Redis.Ambos se mostraram ferramentas maravilhosas para cacheamento e acesso rápido a informações que mudam muito rápido.
No caso do redis da inclusive pra implementar um sistema de mensageria no estilo JMS.Alguma experiência bacana?
Eu estou tendo problemas de desempenho em uma aplicação, por conta de cache, ou pela falta dele. Tenho muita coisa com o cache de segundo nivel do hibernate, mas já não me atende porque o que consigo cachear são informações usadas o tempo todo, que fazem parte da exceção e que não são as que trazem problemas.
Estou de olho no mem cached pela possibilidade de dividir o cache em vários nós e não sobrecarregar um servidor só.
Em que circunstancia voce usou o memcached? O que você cacheou?
K
Bem, voltando ao que realmente importa no tópico, e chave/valor gente, já usaram?
Em 2010 eu tive uma experiência muito bacana com o memcached, e neste estou usando Redis.Ambos se mostraram ferramentas maravilhosas para cacheamento e acesso rápido a informações que mudam muito rápido.
No caso do redis da inclusive pra implementar um sistema de mensageria no estilo JMS.Alguma experiência bacana?
Eu estou tendo problemas de desempenho em uma aplicação, por conta de cache, ou pela falta dele. Tenho muita coisa com o cache de segundo nivel do hibernate, mas já não me atende porque o que consigo cachear são informações usadas o tempo todo, que fazem parte da exceção e que não são as que trazem problemas.
Estou de olho no mem cached pela possibilidade de dividir o cache em vários nós e não sobrecarregar um servidor só.
Em que circunstancia voce usou o memcached? O que você cacheou?
Opa, no meu caso foi a otimização de uma aplicação desktop.
Publiquei o estudo de caso no meu blog na época com mais detalhes. Aqui o link: http://www.itexto.net/devkico/?p=692
A
Bem, voltando ao que realmente importa no tópico, e chave/valor gente, já usaram?
Em 2010 eu tive uma experiência muito bacana com o memcached, e neste estou usando Redis.Ambos se mostraram ferramentas maravilhosas para cacheamento e acesso rápido a informações que mudam muito rápido.
No caso do redis da inclusive pra implementar um sistema de mensageria no estilo JMS.Alguma experiência bacana?
oi,
Aqui no trabalho usamos o Infinispan. que também é chave/valor.
Ele pode ser configurado para ser usado com memcached mas não usamos assim
Utilizamos uma interface REST para publicar e recuperar os dados no Cache do Infinispan.
Existe um sistema Java que fazia a leitura de arquivos do file sytem, esses arquivos agora são lidos do cache do Infinispan que está rodando em um ambiente em cluster com vários Tomcats…
O Infinispan usa uma biblioteca chamada JGroups a qual se encarrega dos detalhes da comunicação sobre o TCP/IP
Sobre o fato de usar ou não NoSQL na minha opinião vale a mesma coisa para a escolha de outras tecnologias
Sem uma POC (Proof of concept) e sem teste de performance qualquer opinião para mim é chutômetro…
J
Ou então parece que alguém não quer dar o braço a torcer…Sem esquivar AndréNão teve nenhum caso até hoje em que o modelo relacional não se aplicava melhor pra você? Nenhuma experiência?
Até tem, mas aí já vira consultoria… ;)
Desculpe entrar no meio, mas estou acompanhando e foi isso que me pareceu… ^^
Porque será que certos usuários precisam transformar toda e qualquer discussão no GUJ em uma quebra de braço entre os debatores?
J
Bancos NoSQL lidam com um volume de dados a uma velocidade que faria qualquer banco relacional surtar!! Twitter, Google e Facebook que o digam. Mas, para que isso aconteça, eles não podem garantir o ACID por completo.
Fontes?
A
Bancos NoSQL lidam com um volume de dados a uma velocidade que faria qualquer banco relacional surtar!! Twitter, Google e Facebook que o digam. Mas, para que isso aconteça, eles não podem garantir o ACID por completo.Fontes?
Na verdade foi um erro de grafia, o correto seria “eles podem não garantir o ACID por completo”. Seguem as fontes:
Em negrito:
Bancos NoSQL lidam com um volume de dados a uma velocidade que faria qualquer banco relacional surtar!! Twitter, Google e Facebook que o digam. Mas, para que isso aconteça, eles não podem garantir o ACID por completo.
Em itálico:
Bancos NoSQL lidam com um volume de dados a uma velocidade que faria qualquer banco relacional surtar!! Twitter, Google e Facebook que o digam. Mas, para que isso aconteça, eles podem não garantir o ACID por completo.
Sublinhado:
Bancos NoSQL lidam com um volume de dados a uma velocidade que faria qualquer banco relacional surtar!! Twitter, Google e Facebook que o digam. Mas, para que isso aconteça, eles podem não garantir o ACID por completo.
Tudo junto com fonte maior (essa é brinde):
[size=18]Bancos NoSQL lidam com um volume de dados a uma velocidade que faria qualquer banco relacional surtar!! Twitter, Google e Facebook que o digam. Mas, para que isso aconteça, eles podem não garantir o ACID por completo.[/size]
Tá bom assim?
H
Esquenta a cabeça com o Ignácio não mano. Ele é troll. Olha o histórico dele. ^^
Bancos NoSQL lidam com um volume de dados a uma velocidade que faria qualquer banco relacional surtar!! Twitter, Google e Facebook que o digam. Mas, para que isso aconteça, eles não podem garantir o ACID por completo.Fontes?
Na verdade foi um erro de grafia, o correto seria “eles podem não garantir o ACID por completo”. Seguem as fontes:
H
Porque será que certos usuários precisam transformar toda e qualquer discussão no GUJ em uma quebra de braço entre os debatores?Isso geralmente acontece quando pessoas não fornecem fontes ou não respondem perguntas né?! :lol: :lol: :lol: :lol:
A
Esquenta a cabeça com o Ignácio não mano. Ele é troll. Olha o histórico dele. ^^
Bancos NoSQL lidam com um volume de dados a uma velocidade que faria qualquer banco relacional surtar!! Twitter, Google e Facebook que o digam. Mas, para que isso aconteça, eles não podem garantir o ACID por completo.Fontes?
Na verdade foi um erro de grafia, o correto seria “eles podem não garantir o ACID por completo”. Seguem as fontes:
É…eu tinha percebido…pelo menos serviu pra eu corrigir o post…hehe
Tá complicado ver tópicos tão bons ficarem assim…
K
Bom, mas voltando ao tópico de novo
Um banco de dados que sou louco pra ver alguma experiência é o Cassandra. Alguém aqui já tentou?
Li alguns anos atrás (ou seriam meses, não lembro) que havia sido um desastre no Digg.com por que havia sido mal aplicado e tal.
Alguma experiência legal?
E com CouchDB? Alguma também?
K
Sobre os problemas com o Cassandra que o Digg enfrentou, aqui está a matéria: http://techcrunch.com/2010/09/07/digg-struggles-vp-engineering-door/
R
Não faz muito tempo eu li uma discussão aqui no GUJ bastante interessante sobre Cassandra x MongoDB, onde apontaram uns pontos bastante importantes, referentes a diferenças de complexidade e escalabilidade entre os 2, segue o link:
R
Kico, e quanto aos iniciantes?
Aposto que tem bastante gente acompanhando o tópico que não sabe nada de NoSQL além do significado da sigla (tipo eu :))
Você tem alguma dica de por onde começar? qual modelo é mais simples para aqueles que só conhecem o mundo relacional?
K
Oi Rodrigo, o post que escrevi no meu blog ( http://www.itexto.net/devkico/?p=1199 ) foi pensando nos iniciantes.
Eu pessoalmente gosto muito da documentação do MongoDB e do Redis, inclusive há sites que permitem ao iniciante experimentar alguns comandos online, o que é bem bacana.
A
Acho que esse livro aqui é uma boa para isso:
http://martinfowler.com/nosql.html
Estou pensando em adquirir em breve.
O autor costuma ser ponderado nas conclusões, o que tem sido cada vez mais raro na nossa área.
A
Tenho! Mas aí já é consultoria
Acho que esse livro aqui é uma boa para isso:
http://martinfowler.com/nosql.html
Também pensei nesse livro. Alguém já leu ele?
J
Na verdade ele respondeu motivação política. Mas claro, cada um lê (ou deixa de ler) o que quiser…
K
Sabe, esta discussão tava muito boa, e eu quero que volte a ser.
Será que da pra parar de avacalhar este negócio?
A
Um outro conceito que começou a surgir, mas acho que não vingou ainda, é o MoreSQL ou NewSQL.
O termo surgiu meio que com ironia, em relação ao NoSQL, mas já tem algumas implementações nessa linha.
O Google tem um projeto chamado Tenzing (acho que ainda é esse) que permite o Sql que conhecemos de forma escalável em data sets gigantescos.
Um outro que segue nessa linha é o VoltDB.
Eu como fã de SQL, confesso que tenho muita esperança no sucesso dessas alternativas.
Acho que a gente acaba perdendo muito recurso, se trocar o relacional, apenas visando escabilidade.
Alguém tem alguma experiência com algum desses?
F
Kico, e quanto aos iniciantes?Aposto que tem bastante gente acompanhando o tópico que não sabe nada de NoSQL além do significado da sigla (tipo eu :))
Você tem alguma dica de por onde começar? qual modelo é mais simples para aqueles que só conhecem o mundo relacional?
O mongoDB me parece facil de aprender para um iniciante, eu tambem nao vi praticamente nada de NoSQL, apenas peguei um dia e fui dar uma olhada no MongoDB, no site deles tu vai fazendo um tuto ja rodando uns comandos e tals, é bem bacana, a instalação(default) dele tambem achei muito tranquilo, se me lembro bem, é só descompactar o arquivo e rodar um comando.
O Foursquare teve um problema sério com o MongoDB, não que a culpa tenha sido exatamente do MongoDB, aqui a matéria: http://www.infoq.com/news/2010/10/4square_mongodb_outage
Isto mostra que antes de sair adotando, é bom conhecer muito bem a ferramenta, mesmo os que conhecem podem enfrentar problemas, como foi o caso do 4square.
A
Sabe, esta discussão tava muito boa, e eu quero que volte a ser.
Será que da pra parar de avacalhar este negócio?
Foi mal, Kico. Eu devia ter ficado na minha de início pra não dar corda.
A
Porque será que certos usuários precisam transformar toda e qualquer discussão no GUJ em uma quebra de braço entre os debatores?Isso geralmente acontece quando pessoas não fornecem fontes ou não respondem perguntas né?! :lol: :lol: :lol: :lol:
Acho que vc deve reler todo o tópico, até agora eu fui o único q forneci fontes por aqui…
J
Foi mal, Kico. Eu devia ter ficado na minha de início pra não dar corda.
Pena que optou por sair pela tangente ao invés de contribuir com a discussão.
Mas continuando… alguém sabe de algum bancos nosql capaz de garantir ACID ?
A
Acho que esse livro aqui é uma boa para isso:
http://martinfowler.com/nosql.html
Estou pensando em adquirir em breve.
O autor costuma ser ponderado nas conclusões, o que tem sido cada vez mais raro na nossa área.
Mais uma referência que eu havia dado no início…
Créditos???
A
Foi mal, Kico. Eu devia ter ficado na minha de início pra não dar corda.Pena que optou por sair pela tangente ao invés de contribuir com a discussão.
Mas continuando… alguém sabe de algum bancos nosql capaz de garantir ACID ?
Opá, pra variar, Datastore do App Engine…
https://developers.google.com/appengine/docs/python/datastore/transactions
A
Um link interessante:
A
Oi André,no caso, eu não citei o Datastore da App Engine porque no post estou dizendo minha vivência no assunto. Nunca trabalhei com ele, desculpa.
Pô kico,
depois de tudo isso vc ainda não modificou aquele primeiro item da sua receita de bolo que diz q só o relacional tem suporte à transações.
Aí é vc q não quer dar o braço a torcer, não é mesmo?
M
um link clássico com uma “comparação” entre os bancos NoSQL:
K
um link clássico com uma “comparação” entre os bancos NoSQL:
Muito bacana!
Sabem o que eu observo? Muitas vezes o abuso do padrão relacional criou um tipo de programador que só conhece como estrutura de dados a tabela.
Vejo por aí uma galera que sequer sabe o que é uma lista, uma tabela de hash, nada.
Achei muito interessante uma conversa que vi outro dia em que um cara tava achando ultra cool uns “termos novos” que o pessoal usava na documentação do Redis. Sabem o que era? Notação O.
Vocês tem esta impressão também?
J
Muito bacana!Sabem o que eu observo? Muitas vezes o abuso do padrão relacional criou um tipo de programador que só conhece como estrutura de dados a tabela.
Vejo por aí uma galera que sequer sabe o que é uma lista, uma tabela de hash, nada.
Achei muito interessante uma conversa que vi outro dia em que um cara tava achando ultra cool uns “termos novos” que o pessoal usava na documentação do Redis. Sabem o que era? Notação O.
Vocês tem esta impressão também?
Até onde sei esse profissional se chama DBA e é muito bem remunerado.
A menos que esteja falando de criar seu próprio BD, não vejo porque alguém precisa conhecer estruturas de dados exóticas ou notação O pra ser um bom programador.
J
Opá, pra variar, Datastore do App Engine…https://developers.google.com/appengine/docs/python/datastore/transactions
http://www.oracle.com/technetwork/database/nosqldb/overview/nosql-transactions-497227.html
Hm… alguma alternativa opensource?
R
um link clássico com uma “comparação” entre os bancos NoSQL:Muito bacana!
Sabem o que eu observo? Muitas vezes o abuso do padrão relacional criou um tipo de programador que só conhece como estrutura de dados a tabela.
Vejo por aí uma galera que sequer sabe o que é uma lista, uma tabela de hash, nada.
Achei muito interessante uma conversa que vi outro dia em que um cara tava achando ultra cool uns “termos novos” que o pessoal usava na documentação do Redis. Sabem o que era? Notação O.
Vocês tem esta impressão também?
Mas aí entra nessa sacola também aquela galera orientada a RAD e framework. Justamente porque a maioria dos RAD’s e frameworks são construídos para trabalharem com bancos relacionais.
Não sei, acho que bons DBA’s tem que pelo menos saber ler um plano de execução e tunar queries. Para fazer isso ele precisa saber pelo menos a diferença entre uma busca linear e uma busca por hash, que em outras palavras é a diferença entre um algoritmo O(n) e O(1). Enfim, tem que conhecer pelo menos o básico de notação O.
J
Não sei, acho que bons DBA’s tem que pelo menos saber ler um plano de execução e tunar queries. Para fazer isso ele precisa saber pelo menos a diferença entre uma busca linear e uma busca por hash, que em outras palavras é a diferença entre um algoritmo O(n) e O(1). Enfim, tem que conhecer pelo menos o básico de notação O.
Se seu negócio for otimização de algoritmos/queries, sem dúvida. Mas não acho que seja ESSENCIAL para um programador/DBA normal.
Criado 9 de novembro de 2012
Ultima resposta 19 de nov. de 2012
Respostas 94
Participantes 16