NoSQL, é seguro? Quais vantagens e desvantagens? Alguém ta usando?
Eu tambem estou iniciando com mongoDB estou achando interessante. Pode ler esta Introducao sobre o mongoDB e este link
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?
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?
[quote=GustavoFreitas]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?
[/quote]
Vejo que cada banco Nosql é mais ou menos focado para resolver um tipo de problema em armazenamento.
Por que resolveu utilizar Mongo DB ?
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.
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.
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.
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.
[quote=kicolobo]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.[/quote]
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:
[quote=GustavoFreitas]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?
[/quote]
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???"
[quote=kicolobo]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?[/quote]
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!
[quote=fredferrao][quote=kicolobo]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?[/quote]
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![/quote]
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.
[quote=YvGa]
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.[/quote]
Isso garoto. Sempre duvide, seja curioso e questione “verdades absolutas”. É assim que a humanidade sempre evoluiu, evolui e evoluirá.
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
[quote=kicolobo]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[/quote]
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.
[quote=andre_salvati][quote=kicolobo]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[/quote]
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.
http://martinfowler.com/books/nosql.html[/quote]
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.
Qual seria o peso de um banco relacional?
[quote=YvGa]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. [/quote]
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.
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.
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…