Banco de Dados em Java - Comparações entre o Derby (JavaDB), HSQL, BDB e outros

20 de janeiro de 2008 2 respostas

Dieval_Guizelini 20 de janeiro de 2008

Senhores,

Estou escrevendo um trabalho que será uma extensão a um banco de dados, precisarei incluir funções, tipos de dados e duas estruturas em particular (complementares a tabelas). Os outros elementos necessários são facilmente encontrados nos banco de dados, como funções matemáticas, visões, logs, transações, concorrência etc.

Em função deste trabalho já realizei uma pesquisa em vários bancos open-source, estudando sua arquitetura e código fonte para avaliar qual melhor, ou melhor dizendo, qual obtenho melhores resultados.

Nesta linha, tenho um arsenal de informações sobre os bancos MySQL, PostgreSQL, BDB, Oracle e os escritos em java (Derby, HSQL, BDB).

Mas ainda estou colhendo opniões e gostaria de saber de quem já utilizou na prática um desses bancos escrito em java, comparado com os em código nativos ou comparados entre eles. Vale qualquer experiência que possa nos ajudar a realizar a escolha.

Principalmente as dificuldades.
Por exemplo, perda de informação, crash, compatibilidade com RAID, SO, consumo de memória, rede, número de usuários concorrentes, tamanho da base de dados armazenada, se usa ou não blobs.

Até o momento eu não entendi porque a SUN optou pelo Derby para ser o JavaDB e não uma implementação do BDB como o SleepyCat (atualmente mantido pela Oracle, mas ainda com a licença do tipo BSD).

Em termos de parse, o derby utiliza o conhecido javacc, o SleepyCat e o HSQL possui parses próprios, alias o do HSQL acaba sendo dividido em várias parte do código (um dos pontos negativos para o meu trabalho).

quais bancos de dados puro java vocês já utilizaram?
Vocês conhecem alguma coisa sobre a arquitetura desses bancos?
Qual tecnologia que utilizam para o parse?
Tipo de índices suportados?
estruturas de blob?
Recursos de backup/recuperação?
failover? arquived logs?

Vamos lá pessoal, qualquer comentário eu agradeço, pode me indicar algo que eu ainda não li ou preciso aprofundar.

Referência para os interessados:
http://www.oracle.com/database/berkeley-db/index.html
http://hsqldb.org/
http://db.apache.org/derby/

Artigos interessantes:
http://weblogs.java.net/blog/davidvc/archive/2006/11/oracle_benchmar_1.html
http://dev.mysql.com/tech-resources/crash-me.php - benchmark da mysql
http://www.oracle.com/database/docs/Berkeley-DB-v-Relational.pdf
Comparação entre os bancos, feito pelo PolePosition:
http://polepos.sourceforge.net/results/PolePosition.pdf

vw
8)

2 Respostas

Aldrin_Leal 20 de jan. de 2008

Obviamente, isso tende a ser menos considerado. A Maioria destes bancos é feita pra ser embutida em outras aplicações.

Dieval Guizelini:
Até o momento eu não entendi porque a SUN optou pelo Derby para ser o JavaDB e não uma implementação do BDB como o SleepyCat (atualmente mantido pela Oracle, mas ainda com a licença do tipo BSD).

Dieval Guizelini:
Em termos de parse, o derby utiliza o conhecido javacc, o SleepyCat e o HSQL possui parses próprios, alias o do HSQL acaba sendo dividido em várias parte do código (um dos pontos negativos para o meu trabalho).

Não vi esta referência. (Ok, acabei de ver. Sim, é javacc. Confundi com o javac). O que sei é que o Derby, após compilar os planos de execução, gera bytecodes. Inclusive, isto é utilizado pela IBM como um mecanismo pra testar a regressão das JVMs.

Sleepycat não possui parser. Até aonde eu saiba, não possui parser.

Além do HSQL, eu sugiro que você dê uma olhada no h2, que é uma reescrita do hsql pelo autor original. Ele apresenta algumas características interessantes. Em particular, acho que acho um grande ponto positivo para o derby e para o h2 está na capacidade dos dois de servirem para prototipação de bancos de dados, pois o derby, via DRDA, permite que você possa criar aplicações para o DB2 sem a necessidade de ter um DB2 (e acredite, eu já fiz isso), e o h2 permite isso em relação ao PostgreSQL.

Dieval_Guizelini 21 de jan. de 2008

Obviamente, isso tende a ser menos considerado. A Maioria destes bancos é feita pra ser embutida em outras aplicações.
[/quote]
Acho que deve ser considerado sim, seria frustante eu investir dois anos ou mais em um projeto e depois deparar com problemas como esse…
Mas acho que a maioria não deve ter esse problema por não fazer acessos via jni.

BDB não é BSD. É GPL. O JavaDB é que é BSD (ou melhor, Apache 2/APSL). Outros dois motivos é porque o JavaDB é um banco Relational/SQL (que o BDB não se propõe a ser), e também pelo JavaDB já ser utilizado há anos no Tutorial J2EE da Sun, com o nome original (Cloudscape).
[/quote]
Eu disse que o SleepyCat tem uma licença do tipo da licença BSD, veja mais em:
http://www.opensource.org/licenses/sleepycat.php

Aldrin Leal:
Além do HSQL, eu sugiro que você dê uma olhada no h2, que é uma reescrita do hsql pelo autor original. Ele apresenta algumas características interessantes. Em particular, acho que acho um grande ponto positivo para o derby e para o h2 está na capacidade dos dois de servirem para prototipação de bancos de dados, pois o derby, via DRDA, permite que você possa criar aplicações para o DB2 sem a necessidade de ter um DB2 (e acredite, eu já fiz isso), e o h2 permite isso em relação ao PostgreSQL.

Legal, vou dar uma olhada no H2.

até mais,

Dieval

Criado 20 de janeiro de 2008

Ultima resposta 21 de jan. de 2008

Respostas 2

Participantes 2

2 Respostas

Topicos relacionados