Ae pessoal, gostaria de saber o que vcs fazem para melhorar a performace de um banco de dados grande ?
Se vcs usam alguma tecnica para driblar esse problema ou deixa o proprio SGBD é cuidar disso … fiquei comigo aqui pensando alguma tecnica interessante apos pegar um banco “medio” usando postgresql (7.4) ele tem 3,4G, mais existe tabelas dentro dele que tem bastante itens!
Sei que o manuseio dessas informações no sistema é de grande valia…
Gostaria de alguns depoimento de vcs…
t+
Editado:
tamanho:
( 255mb dump com tar.gz)
( 3,4G sem compactacao )
mais nao sei se ele é um banco grande grande grande… mais que eu acho grandinho acho !
negocio é que o SGBD é o postgresql, eu acho ele bom, e no caso o fato de ser livre ta falando mais alto!
fazer algo do tipo, usar 2 banco de dados, um com dados mais recentes digamos que de 6 meses e um outro banco com os dados mais antigos e ao final de semana rolar um script que faça esse trabalho de passar de um banco para o outro… isso existe? ou vcs usam mesmo uma super maquina e deixa la todo o banco … sao coisas assim que eu queria saber!!!
[quote=sudeval]250 mb ele zipado com tar.gz
negocio é que o SGBD é o postgresql, eu acho ele bom, e no caso o fato de ser livre ta falando mais alto![/quote]
Claro que é bom!
Na maioria da vezes entre um 10g Express Edition e Postgres ou MySQL tendo a escolher os Open Source;
[quote=sudeval]Ae pessoal, gostaria de saber o que vcs fazem para melhorar a performace de um banco de dados grande ?
Se vcs usam alguma tecnica para driblar esse problema ou deixa o proprio SGBD é cuidar disso … fiquei comigo aqui pensando alguma tecnica interessante apos pegar um banco “medio” usando postgresql (7.4) ele tem uns 255mb, mais existe tabelas dentro dele que tem bastante itens!
Sei que o manuseio dessas informações no sistema é de grande valia…
Gostaria de alguns depoimento de vcs…
t+
[/quote]
Nao sei onde eu li, mas parece q o Postgresql nas versoes 7.x tem um bug de performance, e foi melhorado bastante nas versões 8.x principalmente na 8.2
nao sei se seria util pra voce, mas voce ja leu algo sobre bancos distribuidos? como ja falaram, pode particionar os dados (horizontalmente e verticalmente), mesmo que voce nao va usar é interessante ler…
mas 255mb não é tão grande… entao acho que um banco com indices certos e consultas afinadas ja pode te ajudar…
255 MB cabe dentro de um pen drive. Se você está com problemas de desempenho em um banco tão pequeno, então veja se você está com problemas de índices inadequados ou inexistentes ou queries mal-feitas.
Como eu havia dito antes o tamanho do banco acima, era de um dump zipado com o tar.gz, fui ver o tamanho real dele que é 3,4G… ainda nao sei se é um banco grande ou não para vcs, na verdade meu interesse maior é saber como que vocês trabalham para resolver problemas com bancos grandes…
tipo como amigo falou felipecruz
vou dar uma pesquisada sobre isso.
cado
sim, infelizmente é o 7.4.7 depois vou ver a possibilidade de uma migração para o 8.1 ja que uso o debian e essa é a versão estavel ainda nele.
então a maioria de vcs nao tem nenhum segredo pra agilizar a perfomace do SGBD ne, o mesmo trata de cuidar dessa questão de perfomace!!! (tirando query bem feitas, e indexes… )
na realidade minha curiosidade era essa… se tinha algumas “taticas” para melhorar
Para melhorar a performance de um BD, depende do ambiente em que ele esta instalado, do tipo de utilização, da frequência de utilização, das tabelas e constraints do seu banco de dados, do tamanho das queries, do formato dos dados, etc…
Não existe nenhuma receita de bolo e genérica para fazer tuning das configs do postgresql, nem da criação de índices, nem da melhoria de queries…
Você terá que analisar o uso do seu BD como um todo e a cada query verificar o seu retorno e o seu plano de execução.
Uma dica não faça tuning e melhorias em queries até que você perceba um gargalo naquele ponto…
Mas o que houve com o teu banco ? Com o crescimento ele tem ficado exageradamente lento ?
Além de tudo o que o flávio falou, que realmente é muito importante, mais especificamente no caso do PostgreSQL, você tem usado o VACUUM ??
Verdade VACUUM é fundamental nas ultimas versões do postgresql o vacuum pode ser agendado e feito automaticamente. Unica ressalva que eu faço qto a isso que se vc tiver acesso 24x7 com picos de uso diferentes a cada dia que alguem execute o VACUUM manualmente e não agendado, por que ele concorre com as sessões no acesso a tabelas, o que pode “travar” o acesso a determinadas tabelas durante um tempo, no meu caso isso é crucial visto que alguns segundos a mais pode inviabilizar uma pesquisa.
[quote=flaleite]Você terá que analisar o uso do seu BD como um todo e a cada query verificar o seu retorno e o seu plano de execução.
Uma dica não faça tuning e melhorias em queries até que você perceba um gargalo naquele ponto…[/quote]
vlw! tenho o problema de ainda nao saber especificamente onde está o problema, então vou ter que conseguir algo generico até descobrir o gargalho.
[quote=lucao]Mas o que houve com o teu banco ? Com o crescimento ele tem ficado exageradamente lento ?
Além de tudo o que o flávio falou, que realmente é muito importante, mais especificamente no caso do PostgreSQL, você tem usado o VACUUM ??[/quote]
na verdade tenho peguei a pouco tempo o problema, mais pelas reclamações (cliente) tenho percebido que é basicamente isso mesmo.
Ainda ontem, tive dado umas pesquisadas e vi alguns comentários sobre o VACUUM, até o momento eu não sabia o real uso dele(ele funciona como um gargabe collection ?), então fui dar uma olhada no postgresql.conf e vi que as configurações dele la estão praticamente default.
no 7.4.7 ja tem o auto-vacuum ? ( no 8.1 eu achei, mais no 7.4.7 não)
no arquivo de configuração as unicas linhas que estão descomentadas e com valor são:
tcpip_socket = true
syslog = 0
silent_mode = false
log_connections = true
log_pid = true
log_timestamp = true
stats_start_collector = true
stats_row_level = true
datestyle = 'ISO,European'
dynamic_library_path = '/usr/share/postgresql:/usr/lib/postgresql:/usr/lib/postgresql/lib'
ou seja nem se fala do auto-vacuum ou de vacuum.
a unica linha que fala algo sobre vacuum é
#vacuum_mem = 8192 # min 1024, size in KB
24 x 7 ( seria 24h 7 dias da semana ? ) não, la é de segunda a sabado (08 as 19:30)
nao acredito ter um dia que tenha um grande aumento em relacao aos demais, mais pode ter um determinado horario no dia que tenha um uso maior, tipo proximo as 17h.
tem como me dar so um toque sobre quando vc disse que ele concorre com o acesso as sessoes das tabelas ?
Na versão 7.4.X acho que não tem auto-vacuum, só nas versões 8.1.X e 8.2.X.
Primeiro veja como dar um vacuum na mão usando o psql. Ou baixe o PGAdmin e de seu terminal acesse o BD e faça o vacuum. Como isso é a primeira vez que vai fazer, faça isso fora do horario do expediente ou em um momento que não tenha ninguem acessando o BD.
Caso não vá migrar o postgresql para uma versão mais nova, vc pode agendar na crontab a execução do vacuum num horario fora do expediente (isso no caso do linux) ou usar um programinha de agendamento (no caso de Windows).
eu uso ejb 2.0 e jboss, agorinha me deparei com um probleminha, passou 8segundos para inserir uma linha em uma determinada tabela de 373733 linhas. ( detalhe essa tabela nao tem indice, é apenas para gravar uns logs ). no banco eu fiz o explain de um insert nela e ele me retornou
Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.007..0.008 rows=1 loops=1)
Total runtime: 0.180 ms
ou seja ta ok, acho que o jboss com o ejb ta brigando com algo na hora de criar.
depois vou ver a possibilidade de uma migração para o 8.1 ja que uso o debian e essa é a versão estavel ainda nele.
