Full Text Search No PostgreSQL o Elefante Poliglota

download Full Text Search No PostgreSQL o Elefante Poliglota

of 3

Transcript of Full Text Search No PostgreSQL o Elefante Poliglota

Full Text Search no PostgreSQL O Elefante Poliglota Uma necessidade cada vez mais comum de muitas aplicaes, principalmente para aplicaes web, pesquisar por frases ou palavras no apenas nas colunas char ou varchar das tabelas de um banco de dados. A pesquisa baseada em palavras e frases uma das principais caractersticas das ferramentas de busca na web, como o Google, e dos sistemas de gerenciamento de documentos digitais. Para executar estas pesquisas de forma eficiente, muitos desenvolvedores criam aplicaes extremamente complexas e que no possuem a inteligncia necessria na procura de termos e frases nas colunas que armazenam textos e documentos digitais nas tabelas dos bancos de dados. Neste contexto, o Full Text Search possui grandes vantagens em relao a outras alternativas para pesquisas textuais, como por exemplo, o comando LIKE. Algumas delas so: Realizao de pesquisas textuais baseadas na lingstica. Uma pesquisa lingstica baseada em palavras ou frases de um idioma especfico levando em considerao a conjugao dos verbos, palavras derivadas, acentuao, entre outras caractersticas. Atribuio de pesos para os termos pesquisados, fazendo com que determinadas palavras sejam mais importantes do que outras dentro de uma mesma pesquisa textual; Gerao de ranqueamento, possibilitando uma melhor visualizao dos documentos que so mais relevantes de acordo com a pesquisa realizada. Ento, quem nunca se deparou com a necessidade de pesquisar informaes em textos onde os resultados so insatisfatrios devido variao semntica de um idioma? Atendo a este contexto e a esta pergunta este artigo visa analisar os detalhes de implementao e utilizao do recurso de Full Text Search no PostgreSQL. Para isso, faremos uso de um estudo de caso. Estudo de caso Considere um cenrio de elaborao de projeto onde voc atua na modelagem de dados, e um dos requisistos determina que padres de texto sejam obtidos atravs de consultas enviadas pelo usurio. Em situaes tpicas, voc, optaria pela criao de um atributo para armazenar o texto com os tipos de dados text ou bytea. Porem, para deixar nosso projeto de dados mais prximo de uma situao real, vamos considerar que ao pesquisar as informaes na base, os aspectos morfolgicos das palavras do idioma corrente devem ser considerados na pesquisa. Neste momento, deparamos com a limitao dos operadores tradicionais para comparao de texto, LIKE e ILIKE, e surge a necessidade do emprego do Full text Search, que adiciona tipo de dados, operadores e dicionrios especficos. Digresso Arquitetura do FTS O Full Text Search (FTS) um mecanismo utilizado para pesquisar e determinar a relevncia em grandes volumes de texto. Objetivo desse tipo de busca analisar com preciso uma seqncia de palavras, categoriz-las em smbolos, classificar esses smbolos e otimizar o resultado das pesquisas. A implementao de FTS no PostgreSQL suporta recursos como: criao de palavras ignoradas (stop words), vrios tipos de dicionrios de sinnimos: ispell, thesaurus, snowball e mapeamento de frases e palavras para uma nica forma. A partir da verso 8.3 este recurso foi incorporado ao servidor, deixando de ser um mdulo externo do contrib e criando todas as funes necessrias para adicionar suporte lingstico no PostgreSQL sem a necessidade de compilar um mdulo externo. As propriedades so armazenadas em tabelas do catalogo (pg_catalog) e descritas na tabela 1. No podemos utilizar os tipos text ou bytea para pesquisas utilizando os operadores do FTS. Ao invs disso, devemos adotar o tipo tsvector. Esse tipo de dado armazena uma matriz que descreve documentos normalizados para um simples radical, respeitando as regras lxicas para cada idioma. Um documento um texto em sua forma natural, exatamente como o usurio enxerga no resultado de suas pesquisas. A funo to_tsvector (ver listagem 1) recebe dois parmetros: uma configurao pr-definida no catalogo pg_ts_config.cfg-name, e o documento a ser transformado. Esta funo utilizada para percorrer toda a seqncia de palavras de um documento e retornar uma matriz to tipo tsvector com as flexes de um termo identificado e normalizado por sua ordem de ocorrncia no texto. Este formato futuramente contribui com a ordenao e a indexao para a pesquisa. No exemplo da listagem 1estamos utilizando a funo to_tsvector para converter um documento de sua forma normal para um vetor tsvector. Repare que utilizar configuraes de idiomas diferentes pode trazer resultados inesperados. No caso do nosso texto de exemplo apresentado na listagem 1, uma configurao do ingls(english)

retornaria exatamente o texto em sua forma natural. Isso acontece porque cada idioma possui um conjunto de regras especificas que definem o processo de transformao de palavras derivadas de uma mesma base ou raiz. Na listagem 2 podemos verificar, por exemplo, que as formas: correr, corria e correria, so mapeadas para uma nica base: corr. possvel configurar a linguagem padro do FTS atravs da varivel default_text_search_config (ver listagem 2). Desta forma podemos omitir o primeiro parmetro das funes FTS. Quando escolhemos a configurao pg_catalog.portuguese para default_text_search_config, estamos utilizando um dicionrio pr-definido e baseado no snowball. Este algoritmo gera bons resultados para a maioria das pesquisas. Toda via, existem situaes onde o termo pesquisado no obedece as regras morfolgicas do algoritmo de lematizao para determinado idioma, por exemplo, nos verbos irregulares e / ou anmalos, onde o radical modificado: caber, medir, ir, ser. Nestas circunstncias, podemos optar pela utilizao de um dicionrio ispell, o qual traz regras mais especializadas com classes gramaticais dos idiomas. Aprenderemos a criar novos dicionrios ispell nos prximos artigos, mas por enquanto utilizaremos o snowball. Para realizar comparaes com atributos tipados com tsvector, necessrio utilizar o tipo tsquery em conjunto com os operadores que fornecem suporte a pesquisa FTS. Nas situaes mais simples, utilizamos operadores de comparao @@ (listagem 3), precisamos verificar se um conjunto de tsquery existe dentro (IN) de outro, e para isso utilizamos os operadres @>e