¿Por qué las bases de datos no tienen buenos índices de texto completo?

¿Por qué ninguno de los principales sistemas RDBMS como MySQL, SQL Server, Oracle, etc. tiene un buen soporte de indexación de texto completo?

Me doy cuenta de que la mayoría de las bases de datos admiten índices de texto completo hasta cierto punto, pero que generalmente son más lentas y con un conjunto de características más pequeño. Parece que cada vez que desea un índice de texto completo realmente bueno, debe salir de la base de datos y usar algo como Lucene / Solr o Sphinx.

¿Por qué la tecnología en estos motores de búsqueda de texto completo no está completamente integrada en el motor de la base de datos? Hay muchos problemas para mantener los datos en otro sistema, como Lucence, que incluyen mantener los datos actualizados y la imposibilidad de unir los resultados con otras tablas. ¿Existe una razón tecnológica específica por la que estas dos tecnologías no pueden integrarse?

La respuesta corta es porque la recuperación de texto no tiene casi nada en común con cómo se diseñan y usan las bases de datos tradicionales. Alguien que es un as en la creación / uso de un RDBMS es como un cordero al matadero cuando se acercan a la recuperación de texto por primera vez.

(Perdón por la larga respuesta, pero hoy estoy enfermo en la cama y no tengo nada más que hacer).

Lo siguiente podría entrar fácilmente en TL; DR, pero si tiene el tiempo y el interés, lo que sigue es una parte de la respuesta más larga. Nota: estoy hablando de haber implementado un sistema de recuperación de información comercial a partir de 1986. Fuimos un éxito técnico, pero un fracaso de marketing.

Hacer IR (recuperación de información) correctamente requiere que comience pensando en lo que está buscando y cómo lo encontrará utilizando su mecanismo de consulta. Esto puede sonar fácil, pero es todo menos fácil. Estas son solo algunas de las cosas que tendrá que decidir antes de comenzar a escanear sus documentos (o campos).

1. ¿Importa el caso? ¿DoD es lo mismo que dod? ¿Qué tal "flame" y "FLAME" (una colonia basada en el Burger King Whopper (sí, de verdad)).
2. ¿Qué tipo de tokens indexarás? Obviamente quieres indexar "papi". Probablemente quieras indexar "daddy123". ¿Quieres indexar "123"? "12.3"? "192.168.1.1"?
3. ¿Cómo manejas cosas como la separación silábica? Un ejemplo algo desactualizado es "base de datos", "base de datos" y "base de datos", todos los cuales se utilizaron simultáneamente en 1986.
4. Si su lenguaje de consulta admite el concepto de "Buscar A en la misma oración que B", ¿cómo determina los saltos de oración? A pesar de que '?' y '!' son bastante fáciles, esos son una perra. Piense en cosas como "Sr.", "2.", "etc.", etc.
5. ¿Vas a apoyar la derivación? Si es así, ¿cuán cuidadoso será para no cambiar accidentalmente el POS (Parte del discurso)? Por ejemplo, "gatos" pueden derivar a "gato", pero los "ciegos" pueden o no ser "ciegos". Si se tratara de un verbo ("Él me ciega"), entonces puedes detenerlo, pero si fuera un sustantivo ("Me gustan tus ciegas") no puedes (o al menos no deberías). El tallo es muy seductor, pero Es un pantano de la Primera Orden.
6. ¿Qué idiomas vas a admitir? Lo que funciona en inglés puede fallar mucho en francés o alemán, aunque, curiosamente, tenderá a funcionar bien para los japoneses en la representación de Hepburn Romanji .

Y la lista sigue y sigue ...

Luego tenemos que pensar en nuestro lenguaje de consulta. Puede parecer que si todo lo que va a admitir es simple booleano, entonces debería ser fácil, pero lo único que se acuerda universalmente es que el booleano puro apesta al texto. Por ejemplo, necesitará operadores adicionales para especificar el orden y la proximidad, y vaya, vaya, eso hace que la vida sea más complicada. También necesita saber en qué sección se encuentra: título, encabezado, cuerpo, etc., lo que conduce a todo tipo de diversión de análisis específica de la colección. Pero ahora ya no es suficiente tener una lista de tokens que ocurren en el documento, debes saber dóndeen el documento ocurren. Esto da como resultado una tupla de dirección de (docID, sectionID, para-in-section, oración-en-para, palabra-en-oración). Almacenar y buscar de manera eficiente esta información puede volverse complicado para una colección que no sea de juguete.

Luego está la estructura real de su almacén de datos. Los sistemas de texto normalmente se implementan como una "inversión completa" de los documentos. ¿Cuántos índices tiene el DB promedio? 10? 50? 500? En IR no es raro tener 5,000,000 o más índices, uno para cada token separado. Y cualquier ficha dada puede tener 1 instancia (por ejemplo, "narfle" o "garthok") o 10,000,000 de instancias (por ejemplo, "the"). Esto significa que todo tu método para crear y actualizar índices tiene que ser muy rápido o vas a hundirte en el pantano. Y todavía tiene muchos de los otros problemas que tiene una base de datos tradicional: administración de espacio en disco, recuperación de fallas, instantánea coherente de un sistema en ejecución, etc., etc.

Finalmente hay clasificación de resultados. Un conjunto de resultados sin clasificar de una consulta booleana en una gran colección es inútil para un humano. Puede ser útil para un programa, pero eso no era con lo que estaba tratando. Aunque nuestro sistema implementó Boolean, nuestro punto de venta fue que fuimos el primer sistema disponible comercialmente para admitir la búsqueda de similitudes , basado en el Coeficiente de coseno . La matemática y la lógica de este tipo de búsqueda (básicamente un producto de puntos normalizado del vector de consulta contra millones de vectores de documentos) requería enfoques radicalmente diferentes para la representación y el almacenamiento de datos que los booleanos, definitivamente no es algo disponible en su DB promedio.

Todo esto (y más) es la razón por la cual "recuperación de texto" y "base de datos" casi no pertenecen a la misma oración. Creo que sería mejor elegir una buena base de datos para sus necesidades "normales", y luego usar un sistema IR externo para indexar / buscar los "documentos" en su base de datos primaria.

Oracle tiene capacidades de búsqueda de texto completo bastante sofisticadas como parte de Oracle Text y lo ha tenido durante más de una década. SQL Server 2008 también admite la búsqueda de texto completo . Así que no estoy seguro de que la premisa de su pregunta sea correcta.

Si su pregunta es realmente más similar a "por qué no hacemos más búsquedas de texto completo en bases de datos en lugar de en niveles intermedios", hay algunos factores. Los desarrolladores de bases de datos generalmente desean almacenar datos normalizados, no estructurados o semiestructurados. Por lo tanto, generalmente preferirían diseñar sistemas que analicen los datos entrantes en campos de búsqueda separados en lugar de admitir la búsqueda de texto completo. Los desarrolladores de aplicaciones también tienden a no querer almacenar datos no estructurados o semiestructurados en los campos CLOB / BLOB en la base de datos porque consideran que es más fácil almacenar los datos en un sistema de archivos y no quieren que la base de datos sea demasiado grande. No soy fanático de este argumento, pero es común. Como resultado, la mayoría de las personas terminan con los datos que ' desearía realizar búsquedas de texto completo en vivir fuera de una base de datos, por lo que debe indexarse ​​fuera de una base de datos. Si incluso una fracción razonablemente pequeña de sus datos vive fuera de la base de datos, tener el índice de nivel medio se convierte en una solución mucho más aceptable.

Si almacena sus datos no estructurados y semiestructurados en Oracle, agregaría Oracle Text característica por característica con cualquiera de las soluciones independientes de indexación de texto completo.

Nunca he tenido muchos problemas con FTS en PG.

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

Dicho esto, no es esfinge o lucene, o lo que sea. Creo que hay algunas razones principales (algunas señaladas anteriormente). Creo que lo único que se perdieron sería el factor costo.

FTS no es gratis. Se necesitan recursos de memoria, CPU y disco para buscar. Las bases de datos generalmente tienen suficiente trabajo involucrado sin hacer FTS. Escalar 1 base de datos que realiza FTS y almacenamiento de datos estructurados suele ser doloroso. Escalar cosas separadas (lucene / sphinx / lo que sea) y Escalar una base de datos suele ser menos doloroso.

Principalmente se trata de dimensionamiento y cuáles son sus necesidades. Intentar construir algo como Google (o una búsqueda en la web amplia) con FTS de PG u Oracle Text es pedir problemas.

Utilizo las funciones de FTS de PG en un entorno de producción, pero mantengo las cosas que quiero buscar bastante pequeñas / limitadas. No estoy buscando documentos de Word, estoy buscando registros completos (una combinación de filas DB). Por ejemplo, una de nuestras funciones de búsqueda es buscar personas. En nuestra base de datos, queremos almacenar sus nombres en lugares separados (nombre, apellido, etc.). Además, muchas personas tienen más de 1 nombre (sé que puede sonar loco, pero es totalmente cierto). Además, muchas personas quieren que se respeten sus diéresis y no se respeten los caracteres que no son ascii en su nombre (por ejemplo, cuando están impresos en su cheque), pero nadie recordará cómo escribir la diéresis para encontrar a la persona, por lo que le permitimos buscar en contra o con sin y generalmente encuentra a la persona que desea.

Incluso con múltiples nombres y almacenamiento de ASCII y UTF-8, no estamos hablando de MUCHO espacio de búsqueda Y los datos ya están en la base de datos (donde pertenece), por lo que hacerlo dentro de la base de datos tiene MUCHO sentido .

Pero insertar los documentos de 1 millón de palabras de HR en una base de datos solo para usar FTS en ellos no tiene sentido. Ya son archivos en el sistema de archivos, y el sistema de archivos hace un mejor trabajo que un DB para mantener esos datos seguros y sanos, así que usemos Lucene, o sphinx o lo que sea para buscar esos datos.

¡Use la herramienta adecuada para el trabajo! Pero decir que los DB no tienen FTS no es cierto, pero creo que el caso de uso es diferente.

La mayoría de las aplicaciones de una base de datos no necesitan búsqueda de texto completo.

Si se construyera, aún enfrentaría los mismos problemas que un indexador externo, solo estaría pagando por él (en tiempo / espacio / costo / complejidad) si lo necesitara o no.

La búsqueda de texto completo no es el objetivo de un sistema de gestión de bases de datos relacionales . Diablos, hay muchos agujeros en la parte relacional. (¿Has leído el libro de Chris Date?)