O foco do H2 é aplicações com poucas conexões concorrentes e sendo usado embutido na aplicação. Por este comparativo, é muito mais rápido do que o Derby 10.1.3.1 e compara bem com o HSQLDB 1.8.0.5, MySQL 5.0.22 e Postgresql 8.1.4.
Tem facilidades comparáveis ao MySQL e ao PostgreSQL:
views,
subqueries,
triggers,
clustering,
role based security,
encryption,
user defined functions,
disk and in-memory usage,
embedded and client-server usage,
referential integrity,
scrollable result sets,
schema support,
transaction isolation.
Tem um console via browser com auto-complete
Nesta versão 1.0 ainda faltam algumas coisas como
atualmente só permite lock da tabela inteira,
não suporta full outer joins
o drive ODBC ainda é ‘experimental’
API para transações distribuídas (two-phase commit) está incompleta.
A licença Open Source MPL 1.1 permite:
* You can use H2 for free. You can integrate it into your application (including commercial applications), and you can distribute it.
* Files containing only your code are not covered by this license (it is ‘commercial friendly’).
* Modifications to the H2 source code must be published.
* You don’t need to provide the source code of H2 if you did not modify anything.
However, nobody is allowed to rename H2, modify it a little, and sell it as a database engine without telling the customers it is in fact H2 (isto aconteceu com o HSQLDB)
E a entrevista com seu criador Thomas Mueller ao Infoq em:
Interessante, mas agora fiquei bem curioso.
Ou o HSQLDB melhorou muito ou o Derby que piorou muito. Ha um ano atras ± usamos o Derby em um projeto, a principio seria HSQLDB mas ele foi teve um desempenho muito a baixo do Derby inclusive dando OutOffMemory em alguns inserts.
Quem testar no modo Embedded reporte se o arquivo que ele grava é binário ou é texto. Isso é um fato que inviabiliza de certa forma usar o modo embedded num aplicativo desktop (onde o usuario poderia tentar alterar o arquivo e zicar…)
Posso estar falando besteira, mas que eu entendi o H2 segue o mesmo principio do Hipersonic e por consequencia do HSQLDB, logo mesmo sem testar o H2 acredito que o mesmo armazena em arquivos binarios.
Opiniao pessoal, seria muito amadorismo dos caras fazerem com arquivo texto.
[quote=Insônia]nao, nao Fabio, a noticia fala sobre o H2, e nao sobre o HSQLDB
O comparativo é entre o Derby e o H2…[/quote]
Acho que tu nao clicou no link, mas tudo bem.
Luca,
Eu até li, entendi no conparativo do H2 com o Derby ou com o HSQLDB, mas nao consigo entender como o HSQLDB foi melhor que o Derby, visto que ele tem (ou tinha pode ser isso) serios problemas de gerenciamento de memoria.
Teste comparativo de desempenho de base de dados é muito difícil de entender. Há muitas diferenças nos objetivos dos sistemas de gerenciamento. Alguns funcionam melhor com determinado tipo de consulta e assim, se este tipo for escolhido no teste, eles parecerão melhores. Outra coisa clara é que quanto mais robusto e mais completo um sistema de gerenciamento, mais coisas precisa fazer e mais coisas carrega na memória. Assim não tem nenhuma vantagem comparar um banco levinho com outro com propósito diferente. Foi assim que durante muito tempo o MySQL fez sucesso nas comparações com Oracles e outros grandões do mesmo porte.
Você que é do ramo talvez conheça um antigo site de uma empresa que vive exclusivamente de rodar benchmarks em bases de dados e de vender os relatórios bem caro. Não me lembro o site, mas me lembro das dificuldades que apontavam nas comparações.
Já usei muito o HSQLDB e agora na minha máquina tenho vários derbys instalados que vieram junto com servidores como o glassfish, activemq e outros. O H2 chegou ao mercado um pouco atrasado pois o derby vindo junto com o Java 6 vai desestimular seu uso. Mas eu ainda pretendo testá-lo (não sei quando).
Consegui fazer todo o sistema rodar normalmente, não é muito grande nem muito complicado, mas é um bom teste, tem o diagrama de tabelas em anexo aí, o Hibernate criou todas as tabelas com as suas referidas chaves estrangeiras. Funciona de forma bem parecida com o Derby e o HSQLDB, extremamente simples de configurar no modo Embbedded, mas em modo server eu achei o Derby mais simples (especialmente se você vai inicialiar ele dentro da sua própria aplicação).
O tempo de startup não é tão alto quanto eu imaginava, ele inicializa realmene muito rápido.
Mas partindo pro principal, que são as queries, ele realmente é perceptivelmente mais rápido que o Derby. O outro desenvolvedor do projeto nem sabia que eu tinha trocado o banco rpa fazer os testes mas comentou logo como o sistema estava “mais rápido”, o tempo de resposta dele pras consultas, tanto selects, inserts e updates é muito bom, enquanto que com o derby dava pra “sentir” a máqiuna executando as buscas (era visivelmente lento).
O dialeto do Hibernate parece estar funcionando corretamente, todas as quries aqui funcionaram normalmente e nenhuma exeção do Hibernate foi lançada. O controle de transações também está funcionando corretamente para o driver.
Não, antes que alguém pergunte, não tem nenhuma medida oficial aqui, tudo é na base do achismo mesmo
Mal comecei a usar, já vou aposentar o Derby :lol:
Posso estar falando besteira, mas que eu entendi o H2 segue o mesmo principio do Hipersonic e por consequencia do HSQLDB, logo mesmo sem testar o H2 acredito que o mesmo armazena em arquivos binarios.
Opiniao pessoal, seria muito amadorismo dos caras fazerem com arquivo texto.
]['s[/quote]
O HSQLDB no modo Embedded cria um arquivo texto com todos os SQLs nele. Pelo menos eu nunca vi onde modificar para gravar em modo binário. Você pode estar confundindo com ele rodando em modo Server…
Caused by: org.h2.jdbc.JdbcSQLException: Timeout trying to lock table OUVINTES [HYT00-26]
org.h2.jdbc.JdbcSQLException: Timeout trying to lock table OUVINTES [HYT00-26]
at org.h2.message.Message.getSQLException(Message.java:67)
at org.h2.message.Message.getSQLException(Message.java:49)
at org.h2.table.TableData.lock(TableData.java:270)
at org.h2.command.dml.Insert.update(Insert.java:86)
at org.h2.command.CommandContainer.update(CommandContainer.java:64)
at org.h2.command.Command.executeUpdate(Command.java:119)
at org.h2.server.TcpServerThread.process(TcpServerThread.java:246)
at org.h2.server.TcpServerThread.run(TcpServerThread.java:124)
at java.lang.Thread.run(Unknown Source)
quando vou salvar um objeto (save(obj))…
a pergunta eh, pq a tabela está ficando bloqueada depois q dou
um commit?
Olá pessoal! Alguém aí tá usando o H2 pra valer?
Aqui na empresa nós usamos o PostgreSQL que tem atendido bem as necessidades de um dos nossos sistemas. Porém, estamos com dificuldades em distribuí-lo por se tratar de uma aplicação desktop cliente/servidor…
Daí estamos fortemente inclinados a migrar para um banco que possa ser embutido e distribuído junto com a aplicação. Cogitamos usar o Firebird, mas o modo “mixed” do H2 me chamou a atenção, visto que é possível iniciar o servidor a partir da app e ainda assim fazer uma das apps conectar usando o modo embedded. No caso, a app que inicializaria o servidor conectaria em modo embedded e as demais conectariam em modo cliente/servidor. Em nosso caso a maior parte dos clientes terá apenas 1 ou 2 máquinas rodando o sistema. Em alguns casos atípicos teremos 5 ou 10 máquinas fazendo o acesso. O modo mixed seria interessante pois no caso de apenas 1 app, esta acessaria de maneira muito mais rápida no modo embedded.
Se alguém usou ou estiver usando o H2 em produção e puder dar uma opinião a respeito eu fico agradecido!
