Jump to content
fo_11

Optimizar a procurar de registos numa tabela

Recommended Posts

fo_11

Viva,

Tenho uma base de dados com apenas uma tabela com três colunas que contém 400 milhões de registos. Quando faço uma procura como por exemplo: SELECT nome, data FROM tabela1 where id ==1; o tempo de execução está na ordem dos 120 segundos e retorna uma tabela com apenas 12 mil registos. Neste momento já estou a utilizar indices no id. EDIT: O id não é chave primária.

Alguém sabe como posso melhorar a performance nas procuras deste tipo? Estou a utilizar postgres.

Cumprimentos.

Edited by fo_11

Share this post


Link to post
Share on other sites
HappyHippyHippo

como é que uma pesquisa por uma coluna indexada (que deverá ter valores únicos) retorna mais do que 1 único registo ?


IRC : sim, é algo que ainda existe >> #p@p

Share this post


Link to post
Share on other sites
HappyHippyHippo

Uma coluna indexada não tem que ter necessarimente valores únicos.

bom ... ora já ai tens uma razão para teres os tempos que tens.

se estás a indexar campos não únicos, a indexação perde o seu intuito, tornado mesmo a base de dados mais lenta por estar a gerir uma segunda estrutura de dados auxiliar

mas se mesmo assim, continuares a trabalhar nesse paradigma, só estou a ver uma solução para o teu problema : http://www.postgresql.org/docs/8.2/static/high-availability.html


IRC : sim, é algo que ainda existe >> #p@p

Share this post


Link to post
Share on other sites
fo_11

Obrigado pelo comentário mas novamente isso não é verdade. Quando se faz indexação está-se a criar uma nova estrutura de dados. No meu caso é uma árvore binária que se encontra ordenada logo faz sentido sim aplicar indexação a uma tabela cuja os campos podem aparecer repetidos uma vez que acelera na mesma a pesquisa.

Não leves a mal mas certifica-te primeiro que o que estás a dizer faz realmente sentido antes de comentares. E obrigado pelo link mas a base de dados vai estar numa única máquina que irá servir de servidor pessoal.

Share this post


Link to post
Share on other sites
HappyHippyHippo

Obrigado pelo comentário mas novamente isso não é verdade. Quando se faz indexação está-se a criar uma nova estrutura de dados. No meu caso é uma árvore binária que se encontra ordenada logo faz sentido sim aplicar indexação a uma tabela cuja os campos podem aparecer repetidos uma vez que acelera na mesma a pesquisa.

Não leves a mal mas certifica-te primeiro que o que estás a dizer faz realmente sentido antes de comentares. E obrigado pelo link mas a base de dados vai estar numa única máquina que irá servir de servidor pessoal.

como queiras :

http://stackoverflow.com/questions/1108/how-does-database-indexing-work

When should it be used?

Given that creating an index requires additional disk space (277,778 blocks extra from the above example), and that too many indexes can cause issues arising from the file systems size limits, careful thought must be used to select the correct fields to index.

Since indexes are only used to speed up the searching for a matching field within the records, it stands to reason that indexing fields used only for output would be simply a waste of disk space and processing time when doing an insert or delete operation, and thus should be avoided. Also given the nature of a binary search, the cardinality or uniqueness of the data is important. Indexing on a field with a cardinality of 2 would split the data in half, whereas a cardinality of 1,000 would return approximately 1,000 records. With such a low cardinality the effectiveness is reduced to a linear sort, and the query optimizer will avoid using the index if the cardinality is less than 30% of the record number, effectively making the index a waste of space.

deixa só demarcar esta frase:

"With such a low cardinality the effectiveness is reduced to a linear sort, and the query optimizer will avoid using the index if the cardinality is less than 30% of the record number, effectively making the index a waste of space."


IRC : sim, é algo que ainda existe >> #p@p

Share this post


Link to post
Share on other sites
fo_11

Com esse fundamento consigo concordar mais contigo e perceber mais o teu ponto de vista. No entanto volto ao ponto de partida que me levou a criar este post. Como posso acelerar as queries tendo em conta que é para ser utilizado apenas numa máquina?

Share this post


Link to post
Share on other sites
Rechousa

Viva,

Qual é o SGBD ? Vou partir do principio que seria SQL Server, pois é o que conheço melhor.

Podes explicar um pouco um cenário que tens? Qual o número de vezes que em que os dados se repetem ou qual o número de dados diferentes que podes ter na coluna ID? Exemplo: Se for uma tabela que guarda notas de alunos, vai por exemplo de 0 a 20 e só existem 21 tipos de dados diferentes. Li que para 400 milhoes de registos, obtiveste 12000 registos com o ID = 1.

Se tiveres um cenário destes que descrevi, podes tentar usar um COLUMNSTORE INDEX.

As estatísticas estão atualizadas? O Índice que tens inclui as colunas nome e data? Exemplo: CREATE INDEX tabela1_IDX ON tabela1 (ID) INCLUDE (NOME, DATA)

Já analisaste o plano de execução?

Espero ter ajudado,

  • Vote 1

Pedro Martins

Sharing is Knowledge!

http://www.linkedin.com/in/rechousa

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.