Pergunta

Atualmente estou testando o db4o (a versão java) e gosto muito do que vejo.Mas não posso deixar de me perguntar como ele funciona em um ambiente real (web).Alguém tem alguma experiência (boa ou ruim) para compartilhar sobre a execução do db4o?

Foi útil?

Solução

Executamos a versão DB40 .NET em um grande projeto cliente/servidor.

Nossa experiência mostra que você pode obter potencialmente um desempenho muito melhor do que os bancos de dados relacionais típicos.

No entanto, você realmente precisa ajustar seus objetos para obter esse tipo de desempenho.Por exemplo, se você tiver uma lista contendo muitos objetos, a ativação dessas listas pelo DB4O será lenta.Existem várias maneiras de contornar esse problema, por exemplo, invertendo a relação.

Outra dor é a ativação.Quando você recupera ou exclui um objeto do DB4O, por padrão ele ativará toda a árvore de objetos.Por exemplo, carregar um Foo carregará Foo.Bar.Baz.Bat, etc, até que não haja mais nada para carregar.Embora isso seja bom do ponto de vista de programação, o desempenho diminuirá quanto mais aninhamento em seus objetos.Para melhorar o desempenho, você pode informar ao DB4O quantos níveis de profundidade devem ser ativados.Isso é demorado se você tiver muitos objetos.

Outra área problemática foi a pesquisa de texto.A pesquisa de texto do DB4O é muito, muito mais lenta que a indexação de texto completo SQL.(Eles dirão isso diretamente em seu site.) A boa notícia é que é fácil configurar um mecanismo de pesquisa de texto no DB4O.Em nosso projeto, conectamos o Lucene.NET para indexar os campos de texto que desejamos.

Algumas APIs parecem não funcionar, como as APIs GetField, úteis na aplicação de atualizações de banco de dados.(Por exemplo, se você renomeou uma propriedade e deseja atualizar seus objetos existentes no banco de dados, será necessário usar essas APIs de "reflexão" para localizar objetos no banco de dados.Outras APIs, como o atributo [Index] não funcionam na versão 6.4 estável e, em vez disso, você deve especificar índices usando Configure().Index("someField"), que não é fortemente digitado.

Testemunhamos a degradação do desempenho quanto maior for o seu banco de dados.Temos um banco de dados de 1 GB no momento e as coisas ainda estão rápidas, mas não tão rápidas como quando começamos com um banco de dados minúsculo.

Encontramos outro problema em que Db4O.GetByID fechará o banco de dados se o ID não existir mais no banco de dados.

Descobrimos que a sintaxe Native Query (a sintaxe mais natural e integrada à linguagem para consultas) é muito, muito mais lenta do que as consultas SODA menos amigáveis.Então, em vez de digitar:

// C# syntax for "Find all MyFoos with Bar == 23".
// (Note the Java syntax is more verbose using the Predicate class.)
IList<MyFoo> results = db4o.Query<MyFoo>(input => input.Bar == 23);

Em vez desse código de consulta legal, você precisa de uma consulta SODA feia, baseada em string e não fortemente digitada.

Para o pessoal do .NET, eles introduziram recentemente um provedor LINQ-to-DB4O, que fornece a melhor sintaxe até agora.No entanto, ainda não se sabe se o desempenho estará à altura das feias consultas SODA.

O suporte DB4O tem sido decente:conversamos com eles por telefone várias vezes e recebemos informações úteis.Seus fóruns de usuários são quase inúteis, no entanto, quase todas as perguntas ficam sem resposta.O rastreador de bugs do JIRA recebe muita atenção; portanto, se você tiver um bug persistente, registre-o no JIRA e ele será corrigido com frequência.(Tivemos 2 bugs que foram corrigidos e outro que foi corrigido de forma meia-boca.)

Se tudo isso não o assustou, deixe-me dizer que estamos muito felizes com o DB4O, apesar dos problemas que encontramos.O desempenho que obtivemos superou algumas estruturas de O/RM que testamos.Eu recomendo.

atualização de julho de 2015 Lembre-se de que esta resposta foi escrita em 2008.Embora eu aprecie os votos positivos, o mundo mudou desde então e esta informação pode não ser tão confiável como era quando foi escrita.

Outras dicas

A maioria das consultas nativas pode e é convertida com eficiência em consultas SODA nos bastidores, de modo que isso não deve fazer diferença.É claro que usar NQ é preferível, pois você permanece no domínio da linguagem de digitação forte.Se você tiver problemas para fazer o NQ usar índices, sinta-se à vontade para postar seu problema no fóruns db4o e tentaremos ajudá-lo.

Goran

O principal problema que encontrei são os relatórios.Simplesmente não parece haver nenhuma maneira de executar relatórios eficientes em uma fonte de dados db4o.

Judah, parece que você não está usando a ativação transparente, que é um recurso da versão de produção mais recente (7.4)?Talvez se você especificou a versão que está usando, pois pode haver outros problemas que agora foram resolvidos na versão mais recente?

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top