DB4O - Performance

Programação Java
#1

Olá a todos, bom pessoal, eu sei q tem vários posts ai falando sobre db4o, mas a maioria falando de dúvidas, como faço isso ou aquilo, eu to aqui pensando na tão falada performance do db4o, eu fiz a monografia da pós-graduação sobre db4o, mas não cheguei a realizar testes de performance, fiz de certa forma uma comparação com bancos relacionais, porém mais na questão de desenvolvimento, funções de agregação e agrupamento, como faria isso no db4o, enfim, coisas que tem no sql e que não tem prontas no db4o, não fiz testes em relação a performance.

mas eu tava brincando aqui ontem, e resolvi fazer um laço pra criar 1.000.000 de objetos colocando eles numa lista e depois salvá-los, deu estouro de memória quando chegou em ± 300.000, blz, mudei o laço pra criar o objeto e já salvar, tirando fora a lista, a idéia era ter um arquivo de objetos com 1.000.000 de objetos pra fazer testes, mas demora d+ pra salvar, e não é o tempo de criar o objeto não, demora pra salvar mesmo, em torno de 150 a 200 milisegundos cada objeto, e esse tempo eu cronometrei com a inclusão de um unico objeto, com o seguinte processo: clico no botão, crio o objeto, seto os dados, ligo o cronometro, salvo, desligo o cronometro calculo e imprimo o tempo gasto para incluir… sendo assim ele salva ± 6 ou 7 objetos por segundo…

criei uma tabela no postgre pra fazer o mapeamento do mesmo objeto utilizando hibernate, e usando o mesmo laço percebi que os objetos eram salvos no postgre num tempo entre 5 a 80 milissegundos.

eu deixei o programinha rodando ontem, acho q umas 2 horas ±, não marquei o tempo certinho, e quando fui ver, só tinha inserido 30.000 objetos ±, e tive a impressão de que quanto mais objetos iam sendo salvos, mais lento ficava… o que não acontece no teste com hibernate + postgre… onde 1.000.000 de objetos foram salvos no tempo de 38 min 45 seg 981 milésimos (contando o tempo de criação do objeto, setar os valores dos atributos e salvar)

  1. Esse tempo de inclusão é assim mesmo ? normal ? será q tem alguma configuração no db4o pra melhorar isso ? eu não achei nd…

a hora que sobrar mais um tempinho quero fazer testes de consultas, que até onde eu sei, o db4o deve se sair melhor do que bancos relacionais…

#2

o objeto q eu to salvando tem a seguinte estrutura

[code]public class Objeto {

private int id;
private String atributo01;
private String atributo02;
private String atributo03;
private String atributo04;
private String atributo05;
private String atributo06;
private String atributo07;
private String atributo08;
private String atributo09;
private String atributo010;
private Date atributo011;
private Boolean atributo012;
private BigDecimal atributo013;

//gets e sets

}[/code]
no caso do hibernate + postgre com as devidas annotations

#3

Ola Cleiton,

Estou trabalhando com db4o e estou tendo problema com performance também, vc conseguiu algum resultado em seus estudos?

#4

fala rodrigo blz !?

então, eu comecei aqueles testes comparando o db4o com postgre + hibernate, deu 1000 a 0 pro postgre com hibernate, e dai postei aqui, como ninguem respondeu eu acabei deixando meio de lado…

a gnt ouve muito falar da performance do db4o, mas até hj eu nao comprovei isso, ja conversei com meus professores da facul e da pós, todos falaram a mesma coisa, que ja leram sobre o db4o, fizeram testes, comprovaram a boa performance, mas nunca com uma grande quantidade de informações, sempre uns 10 50 ou 100 registros, eu fiz um sisteminha de controle de contas, coisa pessoal, pra eu usar, que funciona assim, eu cadastro as receitas, em um arquivo.yap e as despesas em outro arquivo.yap, ou seja, td certinho né, objetos diferentes em arquivos diferentes, como manda a recomendação do db4o…

o que acontece é q agora estou aqui com umas 100 receitas cadastradas ± e umas 200 despesas, faz 3 meses q estou usando, e cara, o treco tah ficando cada vez mais lerdo, sabe quando vc clica no botão salvar ? demora quase 1 segundo pra salvar, vc percebe o botão salvar ficando com o foco um tempinho sabe, q a tela fica travada… e olha só, são pouquissimos registros…

e quanto aos teste q eu estava fazendo, quanto a salvar 1.000.000 de registros pra fazer testes de consultas, eu até parei, deixei 2 dias rodando o laço pra inserir os objetos e ainda estava nos 300.000… o postgre + hibernate demorou se não me engano 33 minutos pra inserir 1.000.000 de registros, com o mesmo laço, a unica coisa q mudava era o comando de salvar, do hibernate para o do db4o…

nao sei cara, se eu estou fazendo algo errado, se tem alguma configuração de performance, mas eu acredito q não, eu penso q o db4o por padrão nao deveria vir com uma configuração que desempenhasse essa performance tao fraca… masssss… pode ser q esteja faltando algo mesmo, ou q eu esteja fazendo errado…

mas o seu problema é esse tbem, de performance nas operações crud ? ou é quanto a redução do arquivo ?

vlw t+

#5

Ola Cleiton,

Estou trabalhando com db4o em um projeto para dispositivos móveis, nós carregamos os dados do nosso sistema e geramos um arquivo db4o para enviar para o coletor de dados. Toda vez que o usuário for usar o sistema no dispositivo ele tem que carregar todos os dados, pois onde o usuário utiliza o coletor não tem como usar wireles ou qualquer tipo de conexão, então o dispositivo móvel trabalhar off-line.
O usuário precisa carregar uma gama muito grande de dados, o processo de transferencia esta demorando atualmente entre 50 minutos à 1 hora. Temos que reduzir este tempo crítico, pois é inviável ao usuário aguardar todo esse tempo.

Encontrei este tutorial na net e vamos fazer alguns testes de performance.

Item Configuração:
http://www.linhadecodigo.com.br/Artigo.aspx?id=962&pag=2

Se alguém puder ajudar, agradeço.

#6

pois é, eu tbem ja li esse tutorial, ja fiz as configurações q ele menciona ali, mas eu nao percebi diferença…

#7

no seu caso, acho q vai ser dificil reduzir o tamanho dos arquivos, sendo que são dados que vc precisa para o sistema off line funcionar… eu uso um sistema parecido aqui na empresa…

é desenvolvido em delphi, mas a lógica vc pode usar no seu sistema tbem, no delphi tem o componente clientdataset, que é capaz de manipular um arquivo xml como banco de dados, e o sistema off line, que roda em notebooks dos vendedores, usa esses xml, é o mesmo esquema, em uma maquina aqui na empresa, eu gero as atualizações, e via ftp os vendedores atualizam os dados, porem eu disponibilizo esses arquivos xml, compactados para download, e dai o sistema do notebook, baixa e descompacta… vc pode compactar seus arquivos.yap, eu fiz um testezinho agora, no meu arquivo despesa.yap, de 41 kb, compactado ele fica com 12 kb, ou seja, ja reduziu mais de 3 vezes o tamanho…

mas quanto a performance em operações crud, ainda nao achei nd de interessante…

#8

Pois é Cleiton,

Também usamos ftp pra transpferencia, mas meu problema não chega a ser a transferencia, mas sim a geração mesmo.

#9

ah tah, entendi, vcs tem uma base dados relacional mesmo, dai um sistema q gera o arquivo.yap e a demora esta na geração do arquivo.yap, ou seja, justamente na hora de salvar os dados o banco relacional para o arquivo do db4o… é isso?

#10

isso mesmo…

#11

é cara então a gnt vai ter q tentar descobrir algo pra melhorar essa performance… hahahha

eu vou dar uma pesquisa… apesar q agora estou meio corrido aqui no trabalho, mas qq coisa posto ai, e vc tbem qq novidade avisa ai, vamos ver se conseguimos melhorar isso…

vlw

#12