Pesquisa de Texto Completo

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada SQL do Azure

A Pesquisa em Texto Completo no SQL Server e na Base de Dados SQL do Azure permite que os utilizadores e as aplicações executem consultas de texto completo com dados baseados em carateres em tabelas do SQL Server.

Tarefas básicas

Este artigo fornece uma visão geral do Full-Text Search e descreve seus componentes e sua arquitetura. Se você preferir começar imediatamente, aqui estão as tarefas básicas.

• Introdução ao Full-Text Pesquisa
• Criar e gerenciar catálogos Full-Text
• Criar e gerenciar índices de texto completo
• Preencher Full-Text índices
• Consulta com Full-Text Pesquisa

Full-Text Pesquisa é um componente opcional do Mecanismo de Banco de Dados do SQL Server. Se você não selecionou Full-Text Pesquisar quando instalou o SQL Server, execute a Instalação do SQL Server novamente para adicioná-la.

Visão geral

Um índice de texto completo inclui uma ou mais colunas baseadas em caracteres em uma tabela. Essas colunas podem ter qualquer um dos seguintes tipos de dados: char, varchar, nchar, nvarchar, text, ntext, image, xml ou varbinary(max) e FILESTREAM. Cada índice de texto completo indexa uma ou mais colunas da tabela e cada coluna pode usar um idioma específico.

As consultas de texto completo realizam pesquisas linguísticas em relação a dados de texto em índices de texto completo, operando em palavras e frases com base nas regras de um idioma específico, como inglês ou japonês. As consultas de texto completo podem incluir palavras e frases simples ou várias formas de uma palavra ou frase. Uma consulta de texto completo retorna todos os documentos que contêm pelo menos uma correspondência (também conhecida como acerto). Uma correspondência ocorre quando um documento de destino contém todos os termos especificados na consulta de texto completo e atende a quaisquer outras condições de pesquisa, como a distância entre os termos correspondentes.

Full-Text Consultas de pesquisa

Depois que as colunas são adicionadas a um índice de texto completo, os usuários e aplicativos podem executar consultas de texto completo no texto nas colunas. Essas consultas podem procurar qualquer uma das seguintes condições:

• Uma ou mais palavras ou frases específicas (termo simples)
• Uma palavra ou frase em que as palavras começam com texto especificado (prefixo termo)
• Formas flexionais de uma palavra específica (termo relacionado à geração)
• Uma palavra ou frase próxima de outra palavra ou frase (termo de proximidade)
• Formas sinónimas de uma palavra específica (thesaurus)
• Palavras ou frases utilizando valores ponderados (termo ponderado)

As consultas de texto completo não diferenciam maiúsculas de minúsculas. Por exemplo, pesquisar Aluminum ou aluminum retornar os mesmos resultados.

As consultas de texto completo usam um pequeno conjunto de Transact-SQL predicados (CONTAINS e FREETEXT) e funções (CONTAINSTABLE e FREETEXTTABLE). No entanto, os objetivos de pesquisa de um determinado cenário de negócios influenciam a estrutura das consultas de texto completo. Por exemplo:

• Pesquisando um produto em um site de comércio eletrônico:

  SELECT product_id
  FROM products
  WHERE CONTAINS ((product_description), '"Snap Happy 100EZ" OR FORMSOF(THESAURUS,"Snap Happy") OR "100EZ"')
        AND product_cost < 200;
  

• Cenário de recrutamento procurando candidatos com experiência de trabalho com SQL Server:

  SELECT candidate_name,
         SSN
  FROM candidates
  WHERE CONTAINS ((candidate_resume), '"SQL Server"')
        AND candidate_division = 'DBA';
  

Para obter mais informações, consulte Pesquisa Full-Text.

Comparar consultas de pesquisa Full-Text com o predicado LIKE

Em contraste com a pesquisa de texto completo, o predicado LIKE Transact-SQL funciona apenas em padrões de caracteres. Além disso, você não pode usar o predicado LIKE para consultar dados binários formatados. Além disso, uma LIKE consulta em relação a uma grande quantidade de dados de texto não estruturados é muito mais lenta do que uma consulta de texto completo equivalente em relação aos mesmos dados. Uma LIKE consulta em milhões de linhas de dados de texto pode demorar minutos a ser devolvida, enquanto uma consulta de texto completo pode levar apenas segundos ou menos para os mesmos dados, dependendo do número de linhas retornadas.

Full-Text Arquitetura de pesquisa

A arquitetura de pesquisa de texto completo consiste nos seguintes processos:

• O processo do SQL Server (sqlservr.exe).

• O processo de host do daemon de filtro (fdhost.exe).

  Por motivos de segurança, os filtros são carregados por processos separados chamados anfitriões de filtro daemon. Os fdhost.exe processos são criados por um serviço iniciador FDHOST (MSSQLFDLauncher), e são executados sob as credenciais de segurança da conta de serviço iniciador FDHOST. Portanto, o serviço iniciador FDHOST deve estar em execução para que a indexação de texto completo e a consulta de texto completo funcionem. Para obter informações sobre como definir a conta de serviço para este serviço, consulte Definir a conta de serviço para o iniciador Daemon de filtro de texto completo.

Esses dois processos contêm os componentes da arquitetura de pesquisa de texto completo. Esses componentes e suas relações são resumidos na ilustração a seguir. Os componentes são descritos após a ilustração.

Processo do SQL Server

O processo do SQL Server usa os seguintes componentes para pesquisa de texto completo:

Filtrar processo do Daemon Host

O host do daemon de filtro é um processo iniciado pelo Full-Text Engine. Executa os seguintes componentes de pesquisa de texto completo, que são responsáveis por acessar, filtrar e segmentar dados de tabelas, bem como por segmentar e derivar as raízes da entrada de consulta.

Os componentes do host do daemon de filtro são os seguintes:

O SQL Server 2012 (11.x) instala uma nova versão dos separadores de palavras e lematizadores para inglês dos EUA (LCID 1033) e inglês do Reino Unido (LCID 2057). No entanto, você pode alternar para a versão anterior desses componentes se quiser manter o comportamento anterior. Para obter mais informações, consulte Alterar o separador de palavras usado para inglês dos EUA e inglês do Reino Unido.

Full-Text Processamento de pesquisa

A pesquisa de texto completo é alimentada pelo Full-Text Engine. O Full-Text Engine tem duas funções: suporte à indexação e suporte à consulta.

Full-Text processo de indexação

Quando uma população de texto completo (também conhecida como rastreamento) é iniciada, o mecanismo de Full-Text envia grandes lotes de dados para a memória e notifica o host do daemon de filtro. O host filtra e quebra os dados e converte os dados convertidos em listas de palavras invertidas. Em seguida, a pesquisa de texto completo extrai os dados convertidos das listas de palavras, processa os dados para remover palavras paradas e persiste as listas de palavras de um lote em um ou mais índices invertidos.

Ao indexar dados armazenados em uma coluna varbinary(max) ou image , o filtro, que implementa a IFilter interface, extrai texto com base no formato de arquivo especificado para esses dados (por exemplo, Microsoft Word). Em alguns casos, os componentes do filtro exigem que os dados varbinary(max) ou imagem sejam gravados na pasta filterdata, em vez de empurrados para a memória.

Como parte do processamento, os dados de texto coletados são passados através de um separador de palavras para separar o texto em tokens individuais, ou palavras-chave. A linguagem usada para tokenização é especificada no nível da coluna ou pode ser identificada em varbinary(max), image ou xml pelos dados do componente de filtro.

O processamento extra pode ser realizado para remover palavras paradas e normalizar tokens antes que eles sejam armazenados no índice de texto completo ou em um fragmento de índice.

Quando uma população é concluída, um processo de mesclagem final é acionado que mescla os fragmentos de índice em um índice mestre de texto completo. Isso resulta em um melhor desempenho da consulta, uma vez que apenas o índice mestre precisa ser consultado em vez de vários fragmentos de índice, e melhores estatísticas de pontuação podem ser usadas para classificação de relevância.

Full-Text processo de consulta

O processador de consultas transfere as secções de texto integral de uma consulta para o motor Full-Text para processamento. O Full-Text Engine executa quebra de palavras e, opcionalmente, expansões de dicionário de sinônimos, derivação e processamento de palavras paradas (noise-word). Em seguida, as partes de texto completo da consulta são representadas na forma de operadores SQL, principalmente como funções de valor de tabela em fluxo (STVFs). Durante a execução da consulta, esses STVFs acessam o índice invertido para recuperar os resultados corretos. Os resultados são devolvidos ao cliente neste momento, ou são processados antes de serem devolvidos ao cliente.

Arquitetura de índice de texto completo

As informações em índices de texto completo são usadas pelo Full-Text Engine para compilar consultas de texto completo que podem pesquisar rapidamente uma tabela por palavras específicas ou combinações de palavras. Um índice de texto completo armazena informações sobre palavras significativas e sua localização em uma ou mais colunas de uma tabela de banco de dados. Um índice de texto completo é um tipo especial de índice funcional baseado em token que é criado e mantido pelo Full-Text Engine for SQL Server. O processo de construção de um índice de texto completo difere da construção de outros tipos de índices. Em vez de construir uma estrutura de árvore B com base em um valor armazenado em uma linha específica, o Full-Text Engine constrói uma estrutura de índice invertida, empilhada e compactada com base em tokens individuais do texto que está sendo indexado. O tamanho de um índice de texto completo é limitado apenas pelos recursos de memória disponíveis do computador no qual a instância do SQL Server está sendo executada.

A partir do SQL Server 2008 (10.0.x), os índices de texto completo são integrados ao Mecanismo de Banco de Dados, em vez de residirem no sistema de arquivos como nas versões anteriores do SQL Server. Para um novo banco de dados, o catálogo de texto completo agora é um objeto virtual que não pertence a nenhum grupo de arquivos; é apenas um conceito lógico que se refere a um grupo de índices de texto completo. Observe, no entanto, que durante a atualização de um banco de dados do SQL Server 2005 (9.x), qualquer catálogo de texto completo que contenha arquivos de dados, um novo grupo de arquivos é criado; para obter mais informações, consulte Atualizar Full-Text pesquisar.

Só é permitido um índice de texto completo por tabela. Para que um índice de texto completo seja criado em uma tabela, a tabela deve ter uma única coluna não nula exclusiva. Você pode criar um índice de texto completo em colunas do tipo char, varchar, nchar, nvarchar, text, ntext, image, xml, varbinary e varbinary(max), que podem ser indexadas para pesquisa de texto completo. Criar um índice de texto completo em uma coluna cujo tipo de dados é varbinary, varbinary(max), image ou xml requer que você especifique uma coluna type. Uma coluna de tipo é uma coluna de tabela na qual você armazena a extensão de arquivo (.doc, .pdf, .xlse assim por diante) do documento em cada linha.

Estrutura do índice de texto completo

Uma boa compreensão da estrutura de um índice de texto completo ajuda a entender como o mecanismo de Full-Text funciona. Este artigo usa o seguinte excerto da tabela Document em AdventureWorks2025 como uma tabela de exemplo. Este excerto mostra apenas duas colunas, a coluna DocumentID e a coluna Title, e três linhas da tabela.

Neste exemplo, assumimos que um índice de texto completo foi criado na Title coluna.

Por exemplo, a tabela a seguir, que mostra o Fragmento 1, mostra o conteúdo do índice de texto completo criado na Title coluna da Document tabela. Os índices de texto completo contêm mais informações do que as apresentadas nesta tabela. A tabela é uma representação lógica de um índice de texto completo e é fornecida apenas para fins de demonstração. As linhas são armazenadas em um formato compactado para otimizar o uso do disco.

Os dados são invertidos dos documentos originais. A inversão ocorre porque as palavras-chave são mapeadas para as IDs do documento. Por esta razão, um índice de texto completo é muitas vezes referido como um índice invertido.

Observe também que a palavra-chave and é removida do índice de texto completo. Isso é feito porque and é uma palavra de parada, e remover palavras paradas de um índice de texto completo pode levar a economias substanciais de espaço em disco, o que melhora o desempenho da consulta. Para obter mais informações sobre stopwords, consulte Configurar e gerenciar stopwords e listas de paradas para Full-Text Search.

Fragmento 1

A Keyword coluna contém uma representação de um único token extraído no momento da indexação. Os separadores de palavras determinam o que compõe um token.

A ColId coluna contém um valor que corresponde a uma coluna específica que é indexada em texto completo.

A DocId coluna contém valores para um inteiro de 8 bytes que mapeia para um determinado valor de chave de texto completo em uma tabela indexada de texto completo. Esse mapeamento é necessário quando a chave de texto completo não é um tipo de dados inteiro. Nesses casos, os mapeamentos entre valores de chave de texto completo e valores de DocId são mantidos numa tabela separada chamada tabela DocId Mapping. Para consultar esses mapeamentos, use o procedimento armazenado do sistema sp_fulltext_keymappings . Para satisfazer uma condição de pesquisa, DocId os valores da tabela anterior precisam ser unidos à DocId tabela de mapeamento para recuperar linhas da tabela base que está sendo consultada. Se o valor da chave de texto completo da tabela base for um tipo inteiro, o valor servirá diretamente como o DocId e nenhum mapeamento será necessário. Portanto, o uso de valores de chave de texto completo inteiro pode ajudar a otimizar consultas de texto completo.

A Occurrence coluna contém um valor inteiro. Para cada valor de DocId, há uma lista de valores de ocorrências que correspondem aos deslocamentos relativos das palavras da determinada palavra-chave dentro desse DocId. Os valores de ocorrência são úteis para determinar correspondências de frase ou proximidade, por exemplo, frases têm valores de ocorrência numericamente adjacentes. Eles também são úteis no cálculo de pontuações de relevância; por exemplo, o número de ocorrências de uma palavra-chave em um DocId pode ser usado na pontuação.

Fragmentos de índice de texto completo

O índice lógico de texto completo geralmente é dividido em várias tabelas internas. Cada tabela interna é chamada de fragmento de índice de texto completo. Alguns desses fragmentos podem conter dados mais recentes do que outros. Por exemplo, se um usuário atualizar a seguinte linha cujo DocId é 3 e a tabela é controlada automaticamente por alterações, um novo fragmento será criado.

No exemplo a seguir, que mostra o Fragmento 2, o fragmento contém dados mais recentes sobre DocId 3 em comparação com o Fragmento 1. Portanto, quando o utilizador consulta Rear Reflector, os dados do Fragmento 2 são usados para o DocId 3. Cada fragmento é marcado com um carimbo de data/hora de criação que pode ser consultado usando a vista de catálogo sys.fulltext_index_fragments.

Fragmento 2

Como pode ser visto no Fragmento 2, as consultas de texto completo precisam consultar cada fragmento internamente e descartar entradas mais antigas. Portanto, um elevado número de fragmentos no índice de texto completo pode levar a uma degradação substancial no desempenho das consultas. Para reduzir o número de fragmentos, reorganize o catálogo de texto completo usando a opção REORGANIZE da instrução ALTER FULLTEXT CATALOGTransact-SQL. Esta instrução executa uma mesclagem mestre, que mescla os fragmentos em um único fragmento maior e remove todas as entradas obsoletas do índice de texto completo.

Depois de ser reorganizado, o índice de exemplo conteria as seguintes linhas:

Diferenças entre índices de texto completo e índices regulares do SQL Server

Full-Text pesquisar componentes linguísticos e suporte linguístico

A pesquisa de texto completo suporta quase 50 idiomas diferentes, como inglês, espanhol, chinês, japonês, árabe, bangla e hindi. Para obter uma lista completa dos idiomas de texto completo suportados, consulte sys.fulltext_languages. Cada uma das colunas contidas no índice de texto completo está associada a um identificador de localidade do Microsoft Windows (LCID) que equivale a um idioma suportado pela pesquisa de texto completo. Por exemplo, LCID 1033 equivale ao inglês dos EUA, e LCID 2057 equivale ao inglês britânico. Para cada idioma de texto completo com suporte, o SQL Server fornece componentes linguísticos que dão suporte à indexação e consulta de dados de texto completo armazenados nesse idioma.

Os componentes específicos do idioma incluem os seguintes itens:

Os separadores de palavras (e lematizadores) e filtros são executados no processo de host do daemon de filtro (fdhost.exe).

Conteúdo relacionado

• Introdução ao Full-Text Pesquisa
• Criar e gerenciar catálogos Full-Text
• Criar e gerenciar índices de texto completo
• Preencher Full-Text índices
• Consulta com Full-Text Pesquisa