Comparação de bancos de dados incorporados de Java

Eu pretendo desenvolver um pequeno aplicativo (Java) para gerenciar minhas finanças. Acredito que preciso usar um database incorporado, mas não tenho experiência com esse problema. Eu tentei olhar para alguns dos produtos disponíveis , mas não posso decidir qual deles seria mais adequado para mim. H2 , HSQLDB , Derby e Berkeley DB parecem bons candidatos, mas ainda não vejo como eles se comparam. Agradeço sua ajuda comparando-os e ajudando-me a decidir qual deles usar.

Eu pretendo usar o Hibernate para o meu aplicativo (a menos que você recomendaria usar a API fornecida pelo DBMS), mas também quero ter a capacidade de editar o database facilmente usando uma ferramenta de navegação do SQL (modificando o esquema e alterando dados).

Obrigado.

Ou

  • HSQLDB – Usado pelo OpenOffice, testado e estável. É fácil de usar. Se você quiser editar seus dados de database, basta abrir o arquivo e editar as instruções de inserção.

ou

  • H2 – Disse ser mais rápido (pelo desenvolvedor, que originalmente projetou o hsqldb também)

Qual deles você usa depende de quanto desempenho e quanta estabilidade você precisa.

O desenvolvedor do H2 fez uma boa avaliação de desempenho:
http://www.h2database.com/html/performance.html

Eu uso o Apache Derby para praticamente todas as minhas necessidades de database incorporado. Você também pode usar o Java DB da Sun baseado no Derby, mas a versão mais recente do Derby é muito mais recente. Ele suporta muitas opções que os bancos de dados comerciais e nativos suportam, mas é muito menor e mais fácil de incorporar. Eu tive algumas tabelas de database com mais de um milhão de registros sem problemas.

Eu costumava usar o HSQLDB e o Hypersonic há cerca de 3 anos. Tem alguns problemas de desempenho importantes no momento e eu mudo para o Derby por causa desses problemas. O Derby foi sólido mesmo quando estava na incubadora do Apache.

Eu precisava usar o database Java incorporado em um dos meus projetos e fiz muita pesquisa entendendo os prós e contras de cada database. Eu escrevi um blog listando os prós e contras dos populares bancos de dados java embarcados (H2, HSQLDB, Derby, ObjectDB, Neo4j e OrientDB), você pode dar uma olhada nele. Eu escolhi H2 como eu pensei que melhor atendesse às minhas necessidades. Link para o blog: http://sayrohan.blogspot.in/2012/12/choosing-light-weight-java-database.html Espero que ajude!

Eu iria com o H2, o desempenho é muito melhor do que o Derby. Leia http://www.h2database.com/html/performance.html para mais informações.

O HSQLDB é um bom candidato (o fato de que ele é usado no OpenOffice pode convencer alguns de vocês), mas para uma aplicação pessoal tão pequena, por que não usar um database de objects (em vez de um database clássico)?

Eu usei DB4O em um dos meus projetos, e estou muito satisfeito com isso. Sendo orientado a objects, você não precisa da camada Hibernate inteira e pode inserir / atualizar / excluir / consultar objects diretamente! Além disso, você não precisa se preocupar com o esquema, você trabalha diretamente com os objects e o DB4O faz o resto!

Eu concordo que pode levar algum tempo para se acostumar com este novo tipo de database, mas verifique o tutorial do DB40 para ver como é fácil trabalhar com o DB!

EDIT: Como dito nos comentários, DB4O manipula automaticamente as versões mais recentes das classs. Além disso, uma ferramenta para navegar e atualizar o database fora do aplicativo está disponível aqui: http://code.google.com/p/db4o-om/

O Java DB (distribuição do Apache Derby da Sun) agora é enviado no JDK 6!

Eu tenho vontade de fazer algo parecido com Jason Cohen e tenho pensado que essa parece ser a maneira mais fácil de estar na distro JDK (que da semana passada é um requisito para o meu aplicativo). Ou talvez eu seja apenas preguiçoso assim.

Usamos o HSQLDB em produção como uma opção “sem configuração” para nosso aplicativo. Ele permite que as pessoas experimentem sem o incômodo de configurar um database real.

No entanto, não oferecemos suporte para uso normal. As razões são várias:

  1. Diminui proporcionalmente ao tamanho dos dados.
  2. Difícil de acessar fora do nosso aplicativo (por exemplo, para relatórios personalizados).
  3. Transações / synchronization de disco são difíceis de acertar, por isso é fácil perder dados.

Pelo menos (2) e (3), há maneiras de contornar isso, mas é difícil; é muito mais fácil, por exemplo, instalar o MySQL.

neo4j é:

um mecanismo de persistência Java totalmente transacional e baseado em disco, que armazena dados estruturados em charts e não em tabelas

Eu não tive a chance de experimentar ainda – mas parece muito promissor. Observe que isso não é um database SQL – seu gráfico de object é persistente para você – portanto, pode não ser apropriado para seu aplicativo existente.

Uma boa ferramenta de comparação pode ser encontrada aqui: http://www.jpab.org/All/All/All.html

Observe também as comparações frente a frente de DBMS / JPA

Eu sou um grande fã do DB4O para ambos .Net e Java .

O desempenho se tornou muito melhor desde os primeiros lançamentos. O modelo de licenciamento também não é ruim. Eu particularmente gosto das opções disponíveis para consultar seus objects. Consulta por exemplo é muito poderosa e fácil de se acostumar.

Quais critérios você usará para avaliá-los? Se você ainda não sabe, então não precisa decidir agora. Tente tornar seu aplicativo o mais agnóstico possível para o database – fornecendo os wrappers, os objects de access a dados, etc. apropriados, e tome essa decisão quando tiver todos os fatos à mão e tiver que decidir.

Se você estiver usando bancos de dados relacionais e SQL, o acima não deve ser muito difícil (usando JDBC, etc). Certifique-se de que você tenha vários testes para que, quando quiser alternar entre os bancos de dados, possa determinar que a funcionalidade do seu aplicativo permaneça a mesma.

Eu encontrei o mesmo problema há algum tempo atrás. Eu não sabia qual database usar, então minha primeira solução usou o Derby (ou HSQLDB?), E mais tarde fui capaz de mudar para HSQLDB (ou Derby? Não lembro qual solução funcionou) assim que determinei onde Eu tive problemas (relacionados ao desempenho) e qual solução realmente funcionaria para mim.

A maioria das coisas já foi dita, mas posso apenas acrescentar que usei o HSQL, Derby e Berkely DB em alguns dos meus projetos favoritos e eles funcionaram muito bem. Então eu não acho que realmente importa muito ser honesto. Uma coisa que vale a pena mencionar é que o HSQL se salva como um arquivo de texto com instruções SQL, o que é muito bom. Torna muito fácil quando você está desenvolvendo testes e dados de configuração rapidamente. Também pode fazer edições rápidas, se necessário. Acho que você poderia facilmente transferir tudo isso para qualquer database, se você precisar mudar também 🙂

HSQLDB pode causar problemas para aplicativos grandes, não é tão estável.

O melhor que já ouvi (não em primeira mão, no entanto) é o berkleyDB. Mas a menos que você o abra, vai custar-lhe um arm e uma perna para usar devido ao licenciamento … veja este http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html para detalhes.

ps. O berkleyDB não é um database relacional no caso de você não saber.

Eu usei o Derby e eu realmente odeio as funções de conversão de tipo de dados, especialmente funções de data / hora. (Tipo de Número) <-> Conversão Varchar é uma dor.

Portanto, se você planeja usar conversões de tipo de dados em suas instruções de database, considere o uso de outro database incorporado, e aprendo isso tarde demais.

Conversões de tipo de dados mais recentes da versão do Derby

Se eu estiver correto, H2 é dos mesmos caras que escreveram HSQLDB. É muito melhor se você confiar nos benchmarks em seu site. Além disso, há alguma noção de que a comunidade do sol saltou muito rapidamente para o Derby.

Eu pessoalmente sou a favor do HSQLDB, mas principalmente porque foi o primeiro que tentei.

Diz-se que H2 é mais rápido e fornece uma interface GUI mais agradável (que é genérica e funciona com qualquer driver JDBC, a propósito).

Pelo menos HSQLDB, H2 e Derby fornecem modos de servidor que são ótimos para desenvolvimento, porque você pode acessar o database com seu aplicativo e alguma ferramenta ao mesmo tempo (que o modo embutido geralmente não permite).

Eu sei que você mencionou a navegação no SQL, mas tudo o mais na sua pergunta me faz querer sugerir que você também considere o DB4O , que é um ótimo e simples object DB .

Acho que estou um pouco atrasado (muito atrasado ;-)) para este post, mas gostaria de adicionar o Perst, um database embutido orientado a objects de código-fonte aberto para Java e .NET. para sua consideração. O Prest é um database embutido de código aberto / licença dupla para Java. A distribuição é compatível com a plataforma Android do Google e também inclui o Perst Lite for Java ME. Nós até construímos um benchmark do Android e produzimos um white paper sobre o assunto … você pode dar uma olhada aqui: http://www.mcobject.com/index.cfm?fuseaction=download&pageid=581&sectionid=133

Tudo de bom, Chris