Sign up to save your podcasts
Or
Share Programa 13 – RavenDB e bases de dados NoSQL – Bruno Lopes
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Programa 13 – RavenDB e bases de dados NoSQL – Bruno Lopes
(download)
Neste 13º episódigo tivemos connosco Bruno Lopes, co-fundador da weListen Business Solutions, webdeveloper e membro activo da comunidade NETponto.
Voltamos à conversa mais técnica e desta vez o tema abordado foi RavenDB e bases de dados NoSQL.
A WeListen e a sua estrutura
Começamos a nossa conversa a falar sore a weListen e a sua estrutura.
O Bruno indicou-nos que a weListen foi fundada em 2005/2006 por ele e mais três colegas do Técnico, pois queriam desenvolver projectos em conjunto. A empresa começou per desenvolver soluções à medida, essencialmente na área do comércio electrónico e portais, mas um projecto “engraçado” com a Mota Engil para o desenvolvimento de um portal de inovação levou-os por um caminho diferente.
O produto InnovationCast, onde a weListen está de momento focada a 100%, nasceu desta parceria em que a Mota Engil serviu de “first-case” e recebeu o produto, sendo que a weListen manteve a propriedade intelectual do mesmo.
Na empresa estão de momento 7 pessoas, divididas entre Lisboa e Porto, a desenvolver o produto que foi reescrito no último ano e meio para um versão 2 que utiliza RavenDB como uma das bases de dados principais do projecto.
A comunidade NetPonto e os eventos
Falando da comunidade “.NET” e portugal o Bruno indicou-nos que é um dos organizadores da comunidade e está envolvido na mesma há cerca de 5 anos. A Comunidade em que se encontra envolvido chama-se “NetPonto” sendo que havia uma comunidade com o nome “pontoNET.pt” que é mais antiga e que por vezes leva a alguma confusão.
Questionado sobre a localização geográfica dos eventos, que são muito em Lisboa, o Bruno indicou-nos que tentam organizar um evento mensal na cidade, sendo que o principal motivo é grande parte da organização se encontrar aí localizada. Já tentaram organizar eventos mais frequentes no Porto e outras localidades mas sem sucesso devido muitas vezes à falta de disponibilidade dos habituais organizadores dos eventos.
O que é o RavenDB
O Bruno indicou-nos que o RavenDB foi um projecto que começou há cerca de 6 anos atrás por um israelista conhecido no mundo .NET. O cognome dele é Ayende Rahien (o nome dele é Oren Eini mas a maior parte das pessoas online conhece-o por Ayende).
Ayende tinha muita experiância a lidar com bases de dados relacionais (ele antes do RavenDB tinha alguns produtos para profiling de ligações a bases de dados, em particular com nHibernate) e a certa altura deve ter decidido que bases de dados relacionais são muito úteis para muitos casos, mas se calhar podia valer a pena existirem alternativas ao modelo relacional.
Olhou para ferramentas como CouchDB, na altura MongoDB e algumas alternativas e reparou que uma das coisas que acontecia era que em .NET e em Windows havia pouca tracção, em parte porque algumas dessas alternativas eram nativas em Linux, um tipo de ambiente que não era muito condicente com .NET, e decidiu fazer esta base de dados.
O RavenDB é uma base de dados baseada em documentos, onde em vez de nós guardarmos linhas com colunas, guardamos um documento em JSON. É desenvolvido todo em .NET, é open-source (o código está aberto no GitHub), o primeiro commit foi há 6 anos atrás e neste momento vai na versão 3.0, com desenvolvimento já na 3.5.
As Características de RavenDB e como garante ACID (Atomicity, Consistency, Isolation, Durability)
O Bruno explicou-nos que o RavenDB é uma base de dados transaccional e tem como um dos maiores pontos diferenciadores garantir as características ACID para o armazenamento e obtenção dos documentos, ou seja, quando gravamos um ou vários documentos dentro de uma unidade de trabalho, uma sessão de RavenDB, ou corre tudo bem, ou se falha, falha tudo (ou seja, é atómico).
Não é possível obter dados sujos e o RavenDB garante internamente essa consistência, mas o trade-off que ele faz, ou seja, o que ele diz é que os documentos em si, essa base de dados, é transaccional, é ACID, mas as procuras são eventualmente consistentes.
Para as pesquisas o Bruno indicou-nos que pode ser útil dividir em dois “átomos” diferentes: tendo o RavenDB onde se guardam os documentos em si, cada documento é identificado por uma chave que é uma string e tem lá o JSON que se quiser (existem também metadados) e todas as operações de leitura, carregamento e remoção são atómicas, são transaccionais.
Depois existe uma outra área, que é a área das procuras, onde se definem índices sobre estes documentos e onde se fazem procuras sobre os mesmos. As procuras são baseadas em Lucene, que é basicamente uma biblioteca muito conhecida para full-text search (existe inicialmente em Java e existe também o port para .NET e mais outras linguagens) e basicamente o RavenDB faz as perguntas à base de dados por cima dos indices do Lucene e essa parte aí é toda eventualmente consistente. Ou seja, guarda-se os documentos todos em RavenDB, definem-se os índices e o que ele garante é que os documentos estão lá e eventualmente os índices estarão atualizados.
Outra das características que o RavenDB assume logo ao início é devolver os resultados logo, mesmo que esses resultados não estejam 100% atualizados e a verdade é que, na maior parte dos casos, se os dados foram atualizados à 10 milissegundos atrás, o cliente acaba por não notar, não é muito relevante, e esta separação permite algumas melhorias de performance e permite realmente responder às procuras muito depressa, mesmo que elas estejam um bocado desatualizadas.
Questionamos ao Bruno se notaram diferenças nas pesquisas do seu produto, InnovationCast, o nosso convidado indicou-nos que sim e que acima de tudo permite muito facilmente criar procuras que sejam mais ou menos complexas e mesmo assim ter um tempo de resposta muito rápido.
As diferenças para as bases de dados relacionais
Questionamos o Bruno em relação às diferenças entre os 2 tipos de bases de dados que nos parecem ser muito grandes a nível de conceito.
O Bruno explicou-nos que é uma diferença muito grande e que até a modelação de dados sofre alterações, se tentarmos criar uma base de dados documental da mesma forma que uma relacional o resultado seriam muitas dores de cabeça.
Falamos também sobre a metodologia e normalização e o Bruno indicou-nos que ao contrário das base de dados relacionais, em bases de dados documentais não existe muita formalização do processo de modelação, existem sim melhores práticas que ainda estão em constante evolução o que torna o processo engraçado e bastante orgânico.
“Schema-free? Não é bem isso. O que há é um schema implícito e coisas implícitas, em vez de explícitas, normalmente não são boa ideia.” – Martin Fowler
Questionamos o Bruno em relação à afirmação de Martin Fowler no twitter e ele indicou-nos que para ele faz sentido e existe sempre um schema que pode estar explicito numa base de dados ou explicito em código C# e que em RavenDB se olharmos apenas para a base de dados o esquema é implicito, no entanto esse schema acaba por estar bem definido no código que é programado para a consulta da base de dados.
A atualização de esquemas de dados e versionamento em RavenDB
Apresentamos ao Bruno um caso prático, em que por exemplo começamos o nosso projecto com uma entidade, “Utilizador”, com meia dúzia de campos. E, depois, queremos acrescentar mais alguns, questionamos se isso reflecte-se logo na classe ou se temos de ser nós a fazer esse tipo de versionamento?
O Bruno indicou-nos que esta é uma questão engraçada, porque é uma das barreiras que tipicamente fala quando se trata de projetos RavenDB.
É que, por consequência de todas as decisões tomadas quando o RavenDB foi construído, da forma como tudo é interligado, em 90% dos casos nós não temos que nos preocupar com essa migração.
O Bruno indicou-nos que se adicionamos um novo campo, todas as entidades que estão na base de dados, quando elas forem carregadas, esse campo vai ser também criado. Se estivermos a falar, por exemplo, o “Utilizador” que tem um nome e agora queremos acrescentar a data de nascimento, damos um valor por omissão à data de nascimento (pode ser nulo, por exemplo, para indicar que o utilizador ainda não preencheu isto) e, nos documentos que já estiverem na base de dados, se tentarmos aceder a essa propriedade ela não existe.
Automaticamente o RavenDB, quando vai buscar os dados à base de dados, cria a instância do “Utilizador”, popula com os dados que vêm da base de dados e, se existirem campos novos, esses campos ficam com o valor que têm por omissão.
Usar RavenDB, moda ou desempenho e aplicação no mundo real
Questionamos ao Bruno se existiria outro fator para além de ser “moda” que o levaria a escolher RavenDB ou outra base de dados documental para um projecto e ele indicou-nos que uma das maiores vantagens é a velocidade de desenvolvimento, especialmente quando existem entidades muito complexas. Para o Bruno o desenvolvimento acaba por ser muito mais rápido, pois não tem de se preocupar com “joins”, normalizações e migração de dados quando tem de efectuar alterações simples como acrescentar uma nova coluna.
Em relação à aplicação de bases de dados documentais em todo o tipo de projectos o Bruno indicou-nos que na sua opinião existem situações em que uma base de dados relacional é a melhor opção.
Outros tipos de bases de dados documentais
Como somos curiosos perguntamos ao Bruno se já exploraram outras base de dados documentais como o DocumentDB da Microsoft, ele indicou-nos que por o que já teve oportunidade de ver (sem experimentar propriamente) o DocumentDB parece-lhe mais indicado para outro tipo de problemas do que aqueles que se deparam no dia a dia, sendo que parece funcionar muito bem em grande escala e tem algumas restrições em relação às pesquisas efectuadas sobre ela. Outra questão é só funcionar em cima de Azure o que torna difícil a sua instalação em servidor próprio.
Em relação a outras soluções o CouchDB foi a que chamou mais atenção ao Bruno, mas como não é uma solução muito compatível com Windows a decisão caiu sobre o RavenDB devido a encaixar-se perfeitamente a ambientes windows.
O Open-source e a forma como o .NET se vai encaixar no futuro
Questionamos o Bruno sobre a sua opinião em relação à forma como o .NET se vai encaixar no futuro, tendo em conta que a maioria dos projectos atuais são desenvolvidos em tecnologia open-source.
Para o Bruno esta é uma pergunta difícil, mesmo no seu caso ele não escolheu RavenDB, Postgres ou Redis por ser open-source mas sim pelas vantagens que trazem e claro que o facto de serem open-source traz muitas, como a possibilidade de poder visualizar todo o código e perceber o que está a ocorrer e dessa forma resolver problemas, podendo depois submeter um “pull request” com a solução caso aplicável ou serem geridas por uma comunidade o que traz um maior suporte e capacidade de resolução de alguns problemas em muitos dos casos. Para o Bruno tudo isto também tem uma desvantagem que é a inexistência de alguém efectivamente “responsável” pelo software o que afasta algumas grandes empresas que necessitam dessa “garantia”.
Bases de dados NoSQL, uma moda ou veio para ficar?
Para terminar a ronda de conversa, fizemos ao Bruno a questão acima e para ele vierem para ficar e já cá estavam, as pessoas é que não notavam.
Perguntas Rápidas:
Expectativas para os próximos 12 meses a nível de web?
Qual a app mobile que não dispensarias?
Qual a ferramenta de desenvolvimento/produtividade mais indispensável para o teu dia-a-dia?
Um podcast ou livro fundamental?
Sugestão de próximo convidado
O post Programa 13 – RavenDB e bases de dados NoSQL – Bruno Lopes aparece primeiro no 10web.
View all episodes
By Ricardo Correia e Vitor Silva(download)
Neste 13º episódigo tivemos connosco Bruno Lopes, co-fundador da weListen Business Solutions, webdeveloper e membro activo da comunidade NETponto.
Voltamos à conversa mais técnica e desta vez o tema abordado foi RavenDB e bases de dados NoSQL.
A WeListen e a sua estrutura
Começamos a nossa conversa a falar sore a weListen e a sua estrutura.
O Bruno indicou-nos que a weListen foi fundada em 2005/2006 por ele e mais três colegas do Técnico, pois queriam desenvolver projectos em conjunto. A empresa começou per desenvolver soluções à medida, essencialmente na área do comércio electrónico e portais, mas um projecto “engraçado” com a Mota Engil para o desenvolvimento de um portal de inovação levou-os por um caminho diferente.
O produto InnovationCast, onde a weListen está de momento focada a 100%, nasceu desta parceria em que a Mota Engil serviu de “first-case” e recebeu o produto, sendo que a weListen manteve a propriedade intelectual do mesmo.
Na empresa estão de momento 7 pessoas, divididas entre Lisboa e Porto, a desenvolver o produto que foi reescrito no último ano e meio para um versão 2 que utiliza RavenDB como uma das bases de dados principais do projecto.
A comunidade NetPonto e os eventos
Falando da comunidade “.NET” e portugal o Bruno indicou-nos que é um dos organizadores da comunidade e está envolvido na mesma há cerca de 5 anos. A Comunidade em que se encontra envolvido chama-se “NetPonto” sendo que havia uma comunidade com o nome “pontoNET.pt” que é mais antiga e que por vezes leva a alguma confusão.
Questionado sobre a localização geográfica dos eventos, que são muito em Lisboa, o Bruno indicou-nos que tentam organizar um evento mensal na cidade, sendo que o principal motivo é grande parte da organização se encontrar aí localizada. Já tentaram organizar eventos mais frequentes no Porto e outras localidades mas sem sucesso devido muitas vezes à falta de disponibilidade dos habituais organizadores dos eventos.
O que é o RavenDB
O Bruno indicou-nos que o RavenDB foi um projecto que começou há cerca de 6 anos atrás por um israelista conhecido no mundo .NET. O cognome dele é Ayende Rahien (o nome dele é Oren Eini mas a maior parte das pessoas online conhece-o por Ayende).
Ayende tinha muita experiância a lidar com bases de dados relacionais (ele antes do RavenDB tinha alguns produtos para profiling de ligações a bases de dados, em particular com nHibernate) e a certa altura deve ter decidido que bases de dados relacionais são muito úteis para muitos casos, mas se calhar podia valer a pena existirem alternativas ao modelo relacional.
Olhou para ferramentas como CouchDB, na altura MongoDB e algumas alternativas e reparou que uma das coisas que acontecia era que em .NET e em Windows havia pouca tracção, em parte porque algumas dessas alternativas eram nativas em Linux, um tipo de ambiente que não era muito condicente com .NET, e decidiu fazer esta base de dados.
O RavenDB é uma base de dados baseada em documentos, onde em vez de nós guardarmos linhas com colunas, guardamos um documento em JSON. É desenvolvido todo em .NET, é open-source (o código está aberto no GitHub), o primeiro commit foi há 6 anos atrás e neste momento vai na versão 3.0, com desenvolvimento já na 3.5.
As Características de RavenDB e como garante ACID (Atomicity, Consistency, Isolation, Durability)
O Bruno explicou-nos que o RavenDB é uma base de dados transaccional e tem como um dos maiores pontos diferenciadores garantir as características ACID para o armazenamento e obtenção dos documentos, ou seja, quando gravamos um ou vários documentos dentro de uma unidade de trabalho, uma sessão de RavenDB, ou corre tudo bem, ou se falha, falha tudo (ou seja, é atómico).
Não é possível obter dados sujos e o RavenDB garante internamente essa consistência, mas o trade-off que ele faz, ou seja, o que ele diz é que os documentos em si, essa base de dados, é transaccional, é ACID, mas as procuras são eventualmente consistentes.
Para as pesquisas o Bruno indicou-nos que pode ser útil dividir em dois “átomos” diferentes: tendo o RavenDB onde se guardam os documentos em si, cada documento é identificado por uma chave que é uma string e tem lá o JSON que se quiser (existem também metadados) e todas as operações de leitura, carregamento e remoção são atómicas, são transaccionais.
Depois existe uma outra área, que é a área das procuras, onde se definem índices sobre estes documentos e onde se fazem procuras sobre os mesmos. As procuras são baseadas em Lucene, que é basicamente uma biblioteca muito conhecida para full-text search (existe inicialmente em Java e existe também o port para .NET e mais outras linguagens) e basicamente o RavenDB faz as perguntas à base de dados por cima dos indices do Lucene e essa parte aí é toda eventualmente consistente. Ou seja, guarda-se os documentos todos em RavenDB, definem-se os índices e o que ele garante é que os documentos estão lá e eventualmente os índices estarão atualizados.
Outra das características que o RavenDB assume logo ao início é devolver os resultados logo, mesmo que esses resultados não estejam 100% atualizados e a verdade é que, na maior parte dos casos, se os dados foram atualizados à 10 milissegundos atrás, o cliente acaba por não notar, não é muito relevante, e esta separação permite algumas melhorias de performance e permite realmente responder às procuras muito depressa, mesmo que elas estejam um bocado desatualizadas.
Questionamos ao Bruno se notaram diferenças nas pesquisas do seu produto, InnovationCast, o nosso convidado indicou-nos que sim e que acima de tudo permite muito facilmente criar procuras que sejam mais ou menos complexas e mesmo assim ter um tempo de resposta muito rápido.
As diferenças para as bases de dados relacionais
Questionamos o Bruno em relação às diferenças entre os 2 tipos de bases de dados que nos parecem ser muito grandes a nível de conceito.
O Bruno explicou-nos que é uma diferença muito grande e que até a modelação de dados sofre alterações, se tentarmos criar uma base de dados documental da mesma forma que uma relacional o resultado seriam muitas dores de cabeça.
Falamos também sobre a metodologia e normalização e o Bruno indicou-nos que ao contrário das base de dados relacionais, em bases de dados documentais não existe muita formalização do processo de modelação, existem sim melhores práticas que ainda estão em constante evolução o que torna o processo engraçado e bastante orgânico.
“Schema-free? Não é bem isso. O que há é um schema implícito e coisas implícitas, em vez de explícitas, normalmente não são boa ideia.” – Martin Fowler
Questionamos o Bruno em relação à afirmação de Martin Fowler no twitter e ele indicou-nos que para ele faz sentido e existe sempre um schema que pode estar explicito numa base de dados ou explicito em código C# e que em RavenDB se olharmos apenas para a base de dados o esquema é implicito, no entanto esse schema acaba por estar bem definido no código que é programado para a consulta da base de dados.
A atualização de esquemas de dados e versionamento em RavenDB
Apresentamos ao Bruno um caso prático, em que por exemplo começamos o nosso projecto com uma entidade, “Utilizador”, com meia dúzia de campos. E, depois, queremos acrescentar mais alguns, questionamos se isso reflecte-se logo na classe ou se temos de ser nós a fazer esse tipo de versionamento?
O Bruno indicou-nos que esta é uma questão engraçada, porque é uma das barreiras que tipicamente fala quando se trata de projetos RavenDB.
É que, por consequência de todas as decisões tomadas quando o RavenDB foi construído, da forma como tudo é interligado, em 90% dos casos nós não temos que nos preocupar com essa migração.
O Bruno indicou-nos que se adicionamos um novo campo, todas as entidades que estão na base de dados, quando elas forem carregadas, esse campo vai ser também criado. Se estivermos a falar, por exemplo, o “Utilizador” que tem um nome e agora queremos acrescentar a data de nascimento, damos um valor por omissão à data de nascimento (pode ser nulo, por exemplo, para indicar que o utilizador ainda não preencheu isto) e, nos documentos que já estiverem na base de dados, se tentarmos aceder a essa propriedade ela não existe.
Automaticamente o RavenDB, quando vai buscar os dados à base de dados, cria a instância do “Utilizador”, popula com os dados que vêm da base de dados e, se existirem campos novos, esses campos ficam com o valor que têm por omissão.
Usar RavenDB, moda ou desempenho e aplicação no mundo real
Questionamos ao Bruno se existiria outro fator para além de ser “moda” que o levaria a escolher RavenDB ou outra base de dados documental para um projecto e ele indicou-nos que uma das maiores vantagens é a velocidade de desenvolvimento, especialmente quando existem entidades muito complexas. Para o Bruno o desenvolvimento acaba por ser muito mais rápido, pois não tem de se preocupar com “joins”, normalizações e migração de dados quando tem de efectuar alterações simples como acrescentar uma nova coluna.
Em relação à aplicação de bases de dados documentais em todo o tipo de projectos o Bruno indicou-nos que na sua opinião existem situações em que uma base de dados relacional é a melhor opção.
Outros tipos de bases de dados documentais
Como somos curiosos perguntamos ao Bruno se já exploraram outras base de dados documentais como o DocumentDB da Microsoft, ele indicou-nos que por o que já teve oportunidade de ver (sem experimentar propriamente) o DocumentDB parece-lhe mais indicado para outro tipo de problemas do que aqueles que se deparam no dia a dia, sendo que parece funcionar muito bem em grande escala e tem algumas restrições em relação às pesquisas efectuadas sobre ela. Outra questão é só funcionar em cima de Azure o que torna difícil a sua instalação em servidor próprio.
Em relação a outras soluções o CouchDB foi a que chamou mais atenção ao Bruno, mas como não é uma solução muito compatível com Windows a decisão caiu sobre o RavenDB devido a encaixar-se perfeitamente a ambientes windows.
O Open-source e a forma como o .NET se vai encaixar no futuro
Questionamos o Bruno sobre a sua opinião em relação à forma como o .NET se vai encaixar no futuro, tendo em conta que a maioria dos projectos atuais são desenvolvidos em tecnologia open-source.
Para o Bruno esta é uma pergunta difícil, mesmo no seu caso ele não escolheu RavenDB, Postgres ou Redis por ser open-source mas sim pelas vantagens que trazem e claro que o facto de serem open-source traz muitas, como a possibilidade de poder visualizar todo o código e perceber o que está a ocorrer e dessa forma resolver problemas, podendo depois submeter um “pull request” com a solução caso aplicável ou serem geridas por uma comunidade o que traz um maior suporte e capacidade de resolução de alguns problemas em muitos dos casos. Para o Bruno tudo isto também tem uma desvantagem que é a inexistência de alguém efectivamente “responsável” pelo software o que afasta algumas grandes empresas que necessitam dessa “garantia”.
Bases de dados NoSQL, uma moda ou veio para ficar?
Para terminar a ronda de conversa, fizemos ao Bruno a questão acima e para ele vierem para ficar e já cá estavam, as pessoas é que não notavam.
Perguntas Rápidas:
Expectativas para os próximos 12 meses a nível de web?
Qual a app mobile que não dispensarias?
Qual a ferramenta de desenvolvimento/produtividade mais indispensável para o teu dia-a-dia?
Um podcast ou livro fundamental?
Sugestão de próximo convidado
O post Programa 13 – RavenDB e bases de dados NoSQL – Bruno Lopes aparece primeiro no 10web.