Irei desenvolver em um projeto um sistema que ira realizar um grande numero de insercoes no banco de dados (Algo em torno de 20 millhoes de registros diarios).
O problema eh que os clientes desse sistema nao necessariamente utilizam o mesmo banco de dados, portanto, o hibernate seria uma saida pra ficar independente de banco.
Entretanto, minha maior preocupacao eh com relacao a performance. Alguem ja teve alguma experiencia com o hibernate e com esse volume dados? Eh viavel?
Inserção é simples cara. O Hibernate não fará nada mais além de gerar o infernal sql de insert pra você.
Só que ao invés de perder uma tarde procurando por aspas simples, basta um session.save( object )
Problemas de performance provém de consultas que retornam quantidades excessivas de registros, já que o Hibernate criará objetos a partir dos dados buscados. Exemplo disso são consultas que retornam muitos registros para apenas somar uma coluna.
Mas o próprio Hibernate tem uma exelente engine de queries que conserta grande parte desses problemas.
Por sugestão dos criadores do treco, em casos extremos (onde mesmo com JDBC simples a coisa fica lenta) uma saída ruim, porém performática, é a utilização de procedimentos armazenados.
Portanto, se a carga do seu sistema se concentra em inserções, relaxe. Só encontrei problemas de performance com o Hibernate no exemplo citado e quando configurei o mesmo de maneira incorreta, acredite
As inserções são espalhadas durante todo o dia, ou são 20 milhões de uma vez só?
Aqui fizemos uns testes inserindo 100 mil objetos (com todos os seus relacionamentos), e isso demorava aproximadamente 1 minuto numa maquina com 4 CPUs e vários Gigabytes de memória. Mas isso depende muito de tuning do SGBD e do driver JDBC.
Se o teu volume é apenas de insersão pode ter certeza que o gargalo vai ser o banco de dados.
Uma máquina de 3.000 reais com hibernate consegue saturar um servidor de 100.000 com inserts.
E outra coisa, se for fazer testes “burros” (System.currentTimeMillis()), descarte o tempo que a SessionFactory demora pra sair do forninho, pois na sua aplicação real, ela só sera inicializada uma vez no início da aplicação.
obrigado pela resposta. Com certeza a carga (load) desses registros tambem irá pesar bastante na aplicacao.
Essa aplicacao trata-se de um sistema que gera relatorios a partir de chamadas telefonicas (celulares e fixos) das diversas centrais de cada operadora. Logo, da para se ter uma ideia da quantidade de registros que serao persistidos no banco.
Ha uma pressao muito grande aki na empresa para se utilizar stored procedures e triggers para se ganhar em performance. Entretanto, estou pensando em utilizar essa solucao apenas como ultima carta do baralho, pois ficariamos totalmente dependentes do banco utilizado.
Enfim, gostaria de ouvir sugestoes acerca desse problema.
Grato,
Marcos
Uma busca retorna 50 mil registros com 20 colunas, mas você só precisa da coluna 1 e 2? Bem, não vai criar e popular 50 mil objetos com 20 propriedades, mas sim fazer uma query simples, que retornará uma lista de arrays com os dados.
Lembre-se de sempre olhar as queries construídas pelo Hibernate, é nesse momento que percebe alguma cagada
Qualquer dúvida enche o saco do TedAloprao que o cara manja :mrgreen:
O Hibernate permite mapear classes diferentes para a mesma tabela. Com isso você pode usar o padrão “light-weight class” para os casos onde a performance é crítica e um objeto mais enxuto é suficiente.
Algo assim:
class LightUser {
Long id;
String nome;
String senha;
//getters + setters
}
class HeavyUser extends LightUser {
byte[] foto;
Collection tarefas;
//getters + setters
}
No site do proprio Hibernate tem uma explicação melhor sobre esse padrão.
Quanto a usar stored procedures. Elas tem uma performance consideravelmente superior quando é usada para fazer muitas sumarizações. Mas se começar a colocar muitas regras, condições e complexidade no fluxo a performance vai rapidinho pro vinagre.
E você está mais certo ainda. Para que jogar dinheiro fora fazendo algo que não precisa? A não ser que essa tela seja usada 90% do tempo e seja bem pesada, oque não parece ser o teu caso.
