Por que os bancos de dados não têm bons índices de texto completo

Por que nenhum dos principais sistemas RDBMS, como MySQL, SQL Server, Oracle, etc. tem bom suporte à indexação de texto completo?

Percebo que a maioria dos bancos de dados suporta índices de texto completo até certo ponto, mas geralmente são mais lentos e com um conjunto menor de recursos. Parece que toda vez que você deseja um índice de texto completo realmente bom, precisa sair do banco de dados e usar algo como Lucene / Solr ou Sphinx.

Por que a tecnologia desses mecanismos de pesquisa de texto completo não está completamente integrada ao mecanismo de banco de dados? Existem muitos problemas em manter os dados em outro sistema, como o Lucence, incluindo manter os dados atualizados e a incapacidade de associar os resultados a outras tabelas. Existe uma razão tecnológica específica para que essas duas tecnologias não possam ser integradas?

A resposta curta é porque a recuperação de texto não tem quase nada em comum com a maneira como os bancos de dados tradicionais são projetados e usados. Alguém que é um craque na criação / uso de um RDBMS é como um cordeiro no matadouro quando se aproxima da recuperação de texto pela primeira vez.

(Desculpe pela resposta longa, mas hoje estou doente na cama e não tenho mais nada a fazer.)

O seguinte pode vir facilmente em TL; DR, mas se você tiver tempo e interesse, o que se segue é uma parte da resposta mais longa. Nota: Estou falando de ter implementado um sistema de recuperação de informações comerciais a partir de 1986. Fomos um sucesso técnico, mas um fracasso de marketing.

A execução correta do IR (Recuperação de informações) exige que você comece pensando no que está procurando e como o encontrará usando seu mecanismo de consulta. Isso pode parecer fácil, mas é tudo menos fácil. Aqui estão apenas algumas das coisas que você terá que decidir antes mesmo de começar a digitalizar seus documentos (ou campos).

1. O caso importa? DoD é o mesmo que Dod? Que tal "chama" e "chama" (uma colônia baseada no Burger King Whopper (sim, na verdade)).
2. Quais tipos de tokens você indexará? Você obviamente deseja indexar "papai". Você provavelmente deseja indexar "daddy123". Deseja indexar "123"? "12,3"? "192.168.1.1"?
3. Como você lida com coisas como hifenização? Um exemplo um pouco desatualizado é "banco de dados", "banco de dados" e "banco de dados", que estavam em uso simultaneamente em 1986.
4. Se o seu idioma de consulta suportar o conceito de "Localizar A na mesma frase que B", como você determina as quebras de frase? Apesar '?' e '!' são fáceis o suficiente, esses '.'s são uma cadela. Pense em coisas como "Sr.", "2.", "etc." etc.
5. Você vai apoiar o stemming? Em caso afirmativo, qual o seu cuidado para não alterar acidentalmente o POS (parte do discurso)? Por exemplo, "gatos" podem resultar em "gato", mas "persianas" podem ou não resultar em "cegos". Se fosse um verbo ("Ele me cega"), então você pode conter, mas se for um substantivo ("Eu gosto de suas cortinas), você não pode (ou pelo menos não deveria). é um pântano da Primeira Ordem.
6. Quais idiomas você vai apoiar? O que funciona em inglês pode falhar bastante em francês ou alemão, embora, estranhamente, ele tende a funcionar bem para o japonês na representação de Hepburn Romanji .

E a lista continua.

Então temos que pensar na nossa linguagem de consulta. Pode parecer que, se tudo o que você vai apoiar é booleano simples, deve ser fácil, mas a única coisa que é universalmente aceita é que o booleano puro é uma merda de texto. Por exemplo, você precisará de operadores adicionais para especificar pedidos e proximidade, e, oh, garoto, isso torna a vida ainda mais complicada. Você também precisa saber em qual seção você está - título, cabeçalho, corpo etc. - o que leva a todo tipo de diversão de análise específica da coleção. Mas agora não é mais suficiente apenas ter uma lista de tokens que ocorrem no documento, você precisa saber ondeno documento que eles ocorrem. Isso resulta em uma tupla de endereço de (docID, sectionID, para-na-seção, frase-para-para, palavra-na-frase). Armazenar e pesquisar com eficiência essas informações pode tornar-se complicado para uma coleção que não seja de brinquedos.

Depois, há a estrutura real do seu armazenamento de dados. Os sistemas de texto são normalmente implementados como uma "inversão total" dos documentos. Quantos índices o DB médio possui? 10? 50? 500? Em RI, não é incomum ter 5.000.000 ou mais índices, um para cada token separado. E qualquer token fornecido pode ter 1 instância (por exemplo, "narfle" ou "garthok") ou 10.000.000 instâncias (por exemplo, "the"). Isso significa que todo o seu método para criar e atualizar índices deve ser extremamente rápido ou você vai afundar no pântano. E você ainda tem muitos dos outros problemas que um banco de dados tradicional apresenta: gerenciamento de espaço em disco, recuperação de falhas, instantâneo coerente de um sistema em execução, etc., etc.

Finalmente, há classificação de resultados. Um conjunto de resultados sem classificação de uma consulta booleana em uma grande coleção é inútil para um humano. Pode ser útil para um programa, mas não era com isso que eu estava lidando. Embora nosso sistema tenha implementado booleano, nosso ponto de venda foi que fomos o primeiro sistema comercialmente disponível a oferecer suporte à pesquisa de similaridade , com base no coeficiente cosseno . A matemática e a lógica desse tipo de pesquisa (basicamente um produto escalar normalizado do vetor de consulta em relação a milhões de vetores de documentos) exigiam abordagens radicalmente diferentes para representação e armazenamento de dados do que o Booleano - definitivamente não há algo disponível em seu banco de dados médio.

Tudo isso (e mais) é por que "recuperação de texto" e "banco de dados" quase não pertencem à mesma frase juntos. Eu acho que seria melhor escolher um bom banco de dados para suas necessidades "normais" e depois usar um sistema de RI externo para indexar / pesquisar os "documentos" no seu banco de dados primário.

A Oracle possui recursos sofisticados de pesquisa de texto completo como parte do Oracle Text e o possui há mais de uma década. O SQL Server 2008 também oferece suporte à pesquisa de texto completo . Portanto, não tenho certeza de que a premissa da sua pergunta esteja correta.

Se sua pergunta for realmente mais parecida com "por que não fazemos mais pesquisas de texto completo nos bancos de dados do que nas camadas intermediárias", existem alguns fatores. Os desenvolvedores de banco de dados geralmente desejam armazenar dados normalizados, não dados não estruturados ou semiestruturados. Portanto, eles geralmente preferem projetar sistemas que analisem os dados recebidos em campos pesquisáveis ​​separados, em vez de oferecer suporte à pesquisa de texto completo. Os desenvolvedores de aplicativos também tendem a não querer armazenar dados não estruturados ou semiestruturados nos campos CLOB / BLOB no banco de dados, porque consideram mais fácil armazenar os dados em um sistema de arquivos e não desejam que o banco de dados fique muito grande. Não sou fã desse argumento, mas é comum. Como resultado, a maioria das pessoas acaba com os dados que eles ' gostaria de fazer pesquisas de texto completo vivendo fora de um banco de dados, para que ele precise ser indexado fora de um banco de dados. Se mesmo uma fração razoavelmente pequena de seus dados estiver fora do banco de dados, o índice da camada intermediária se tornará uma solução muito mais agradável.

Se você armazenar seus dados não estruturados e semiestruturados no Oracle, eu colocaria o Oracle Text recurso por recurso com qualquer uma das soluções independentes de indexação de texto completo.

Eu nunca tive muitos problemas com o STF no PG.

http://www.postgresql.org/docs/current/static/textsearch.html

Dito isto, não é esfinge ou luceno, ou o que seja. Eu acho que existem algumas razões principais (algumas apontadas acima). Eu acho que o único que eles perderiam seria o fator de custo.

O STF não é gratuito. É preciso memória, CPU e recursos de disco para pesquisar. Os bancos de dados geralmente têm bastante trabalho envolvido sem fazer o STF. Escalar 1 banco de dados que faz STF e armazenamento estruturado de dados geralmente é doloroso. Escalar coisas separadas (lucene / esfinge / qualquer que seja) e Escalar um banco de dados geralmente é menos doloroso.

Principalmente, o dimensionamento e quais são suas necessidades. Tentar criar algo como o Google (ou pesquisa na web ampla) com o FTS da PG ou o Oracle Text está causando problemas.

Uso os recursos de STF do PG em um ambiente de produção, mas mantenho o material que quero pesquisar bastante pequeno / limitado. Não estou pesquisando documentos do Word, estou pesquisando registros inteiros (uma combinação de linhas do banco de dados). Por exemplo, uma de nossas funções de pesquisa é procurar pessoas. Em nosso banco de dados, queremos armazenar seus nomes em locais separados (nome, sobrenome, etc). Além disso, muitas pessoas têm mais de um nome (eu sei que pode parecer loucura, mas é totalmente verdade). Além disso, muitas pessoas querem que seus tremas sejam respeitados e respeitem os caracteres não-ascii em seu nome (digamos, quando impressos em seu cheque), mas ninguém se lembrará de como digitar o trema para encontrar a pessoa, por isso permitimos que você pesquise com ou sem sem e geralmente encontra a pessoa que você deseja.

Mesmo com vários nomes e armazenamento de ASCII simples e UTF-8, não estamos falando de muito espaço de pesquisa E os dados já estão no banco de dados (onde pertence), portanto, fazê-lo dentro do banco de dados faz MUITO sentido. .

Mas inserir 1 milhão de documentos do Word em um banco de dados apenas para usar o STF neles não faz sentido. Eles já são arquivos no sistema de arquivos, e o sistema de arquivos faz um trabalho melhor do que um banco de dados poderia manter esses dados seguros e saudáveis, então vamos usar o Lucene, ou sphinx ou qualquer outra coisa para pesquisar esses dados.

Use a ferramenta certa para o trabalho! Mas dizer que os bancos de dados não têm STF não é verdade, mas acredito que o caso de uso seja diferente.

A maioria dos aplicativos de um banco de dados não precisa de pesquisa de texto completo.

Se fosse construído, ainda enfrentaria os mesmos problemas que um indexador externo enfrentaria, você apenas pagaria por isso (em tempo / espaço / custo / complexidade), independentemente de precisar ou não.

A pesquisa de texto completo não é o objetivo de um sistema de gerenciamento de banco de dados relacional . Heck, existem muitos buracos na parte relacional. (Você leu o livro de Chris Date?)