{"id":5764,"date":"2018-09-04T10:25:40","date_gmt":"2018-09-04T17:25:40","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=5764"},"modified":"2025-06-13T20:27:48","modified_gmt":"2025-06-14T03:27:48","slug":"why-you-should-avoid-like-deep-dive-on-fts-part-1","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/why-you-should-avoid-like-deep-dive-on-fts-part-1\/","title":{"rendered":"Por qu\u00e9 debe evitar que le GUSTE % | Profundizaci\u00f3n en FTS - Parte 1"},"content":{"rendered":"

La b\u00fasqueda era probablemente una de las funciones m\u00e1s olvidadas en las aplicaciones del pasado. Sin embargo, en los \u00faltimos a\u00f1os se le ha prestado toda la atenci\u00f3n que merece, ya que por fin nos hemos dado cuenta de c\u00f3mo puede aumentar las ventas o moldear el comportamiento y el compromiso de los usuarios.<\/p>\n

En esta nueva serie de blogs, me gustar\u00eda ir de cero a experto. Como tal, al final de la misma, usted ser\u00e1 capaz de poner en pr\u00e1ctica las b\u00fasquedas \"como un profesional<\/em>\".<\/p>\n

 <\/p>\n

\u00bfPor qu\u00e9 \"Como %\" no es suficiente?<\/strong><\/h2>\n

Una b\u00fasqueda bien realizada debe ser esencialmente r\u00e1pida y pertinente; \"Como %<\/strong>\"no es ninguno de ellos. Veamos por qu\u00e9:<\/p>\n

 <\/p>\n

El problema de la velocidad<\/strong><\/h3>\n

Supongamos que queremos realizar una b\u00fasqueda de una pel\u00edcula por su t\u00edtulo. Una consulta SQL ingenua que buscara todas las pel\u00edculas de \"Star Trek\" tendr\u00eda el siguiente aspecto:<\/p>\n

Select * from Movies where title like \u201cStar Trek%\u201d<\/pre>\n
Por defecto, ejecutar\u00e1 un escaneo completo de la tabla intentando hacer coincidir este t\u00e9rmino con todas las filas. Pero puede optimizarse con un \u00edndice, que crear\u00e1 probablemente una estructura de \u00e1rbol B. Por lo tanto, incluso b\u00fasquedas como la siguiente aprovechar\u00edan parcialmente el \u00edndice:<\/p>\n
Select * from Movies where title like \u201cStar%Trek\u201d\r\nSelect * from Movies where title like \u201cSt%Trek\u201d<\/pre>\n
Pero, \u00bfy si el usuario es un gran fan de Batman y decide buscar el t\u00e9rmino \"Caballero Oscuro\"? Seg\u00fan el ejemplo anterior, nuestra consulta tendr\u00e1 el siguiente aspecto:<\/p>\n
Select * from Movies where title like \u201cDark Knight%\u201d<\/pre>\n
La b\u00fasqueda de arriba tiene el no traer\u00e1 ning\u00fan resultado como el verdadero nombre de la pel\u00edcula es \"En<\/strong> Dark Knight Rises\".  Para solucionar este problema, a\u00f1adamos un comod\u00edn al principio de nuestro t\u00e9rmino de b\u00fasqueda:<\/p>\n
Select * from Movies where title like \u201c%Dark Knight%\u201d<\/pre>\n
\u00a1Arreglado! \u00bfVerdad?  Desgraciadamente, no. La consulta anterior finalizar\u00e1 con un resultado como \"En<\/strong> Dark Knight Rises\", pero ya no aprovechar\u00e1 el \u00edndice y definitivamente no tendr\u00e1 un buen rendimiento a escala. Como %<\/strong> no \"entiende\" el contenido de su campo. M\u00e1s bien, trata un texto como algo \u00fanico, lo que hace que no sea la mejor opci\u00f3n para tratar cualquier cosa que tenga alg\u00fan tipo de estructura subyacente.<\/p>\n
Una posible soluci\u00f3n es utilizar MATCH, pero tambi\u00e9n se ha Seg\u00fan los informes, es lento<\/a> en algunas bases de datos.<\/p>\n
 <\/p>\n
El problema de la relevancia<\/strong><\/h3>\n
\u00bfY si quisi\u00e9ramos buscar tambi\u00e9n el resumen de la pel\u00edcula? Una soluci\u00f3n ingenua ser\u00eda a\u00f1adir un nuevo campo a la consulta:<\/p>\n
Select * from Movies where title like \u201c%Dark Knight%\u201d or overview like \u201c%Dark Knight%\u201d<\/pre>\n
Este enfoque introduce un nuevo problema: cualquier pel\u00edcula que mencione \"El Caballero Oscuro\" en el resumen tiene la misma relevancia que las que lo llevan en el t\u00edtulo, y el orden de los resultados es totalmente incierto.<\/p>\n
Un error com\u00fan es pensar que UNION DISTINCT podr\u00eda resolver este problema. Sin embargo, la mayor\u00eda de los planificadores de consultas de hoy en d\u00eda ejecutan cada bloque de la uni\u00f3n en paralelo, lo que volver\u00e1 a estropear el orden\/relevancia.<\/p>\n
Si realmente desea implementar alg\u00fan tipo de relevancia utilizando SQL simple, una soluci\u00f3n sencilla es ejecutar dos consultas separadas y a\u00f1adir el resultado de una a la otra. Por supuesto, esta estrategia dista mucho de ser \u00f3ptima y a\u00fan tendr\u00eda que gestionar la duplicaci\u00f3n manualmente.<\/p>\n
Los ejemplos anteriores muestran una de las verdades t\u00e1citas de la b\u00fasqueda: El verdadero reto de la b\u00fasqueda no es encontrar coincidencias, sino clasificarlas.<\/strong><\/em>. Al fin y al cabo, emparejar un texto es una tarea muy sencilla, pero darle la puntuaci\u00f3n adecuada es algo que debe elaborarse cuidadosamente.<\/p>\n
 <\/p>\n
Texto completo<\/strong> la b\u00fasqueda acude al rescate<\/strong><\/h2>\n
Hay muchas formas diferentes de buscar un t\u00e9rmino, cada una centrada en una estrategia espec\u00edfica. Cubriremos la mayor\u00eda de ellas en los pr\u00f3ximos art\u00edculos, pero por ahora, centr\u00e9monos en por qu\u00e9 FTS es mucho mejor que \"Como %<\/strong>\":<\/p>\n
 <\/p>\n
La soluci\u00f3n para la velocidad<\/strong><\/h3>\n
Para poder consultar una base de datos con FTS, primero hay que crear un \u00edndice invertido. Este \u00edndice, a grandes rasgos, es un mapa de palabras y sus ocurrencias:<\/p>\n
\"inverted_index\"<\/p>\n
Con el \u00edndice anterior en su lugar, la b\u00fasqueda de una palabra se convierte en una tarea sencilla, ya que puede obtener f\u00e1cilmente s\u00f3lo los documentos que contienen el t\u00e9rmino de destino.<\/p>\n
Tenga en cuenta que durante la creaci\u00f3n del \u00edndice invertido, hemos convertido las frases en una matriz de palabras, por lo que los comodines no son necesarios, ya que podemos comparar directamente los t\u00e9rminos de destino con nuestro \u00edndice invertido. No obstante, incluso el uso de comodines aqu\u00ed (Ej: *estrella*) seguir\u00e1 siendo m\u00e1s r\u00e1pido a escala, ya que s\u00f3lo tendr\u00e1 que iterar a trav\u00e9s de su \u00edndice para encontrar todas las coincidencias en lugar de escanear todos los documentos de su base de datos.<\/p>\n
A\u00fan no he mencionado nada sobre diccionarios, stemming, analizadores, tokenizadores y sin\u00f3nimos. Lo har\u00e9 en la segunda parte de esta serie.<\/p>\n
 <\/p>\n
La soluci\u00f3n para la pertinencia<\/strong><\/h3>\n
La estrategia para implementar un resultado de b\u00fasqueda relevante puede variar seg\u00fan el dominio en el que se est\u00e9 trabajando. En general, la relevancia puede manipularse de m\u00faltiples maneras, la m\u00e1s sencilla de las cuales se denomina \"boosting\". A grandes rasgos, el boosting es una forma sencilla de asignar un peso a las coincidencias de campo:<\/p>\n
Consulta:<\/strong><\/p>\n
T\u00edtulo:\"<\/strong>Star Trek\"^2 | Resumen:\"<\/strong>Star Trek\"<\/p>\n
En el ejemplo anterior, la puntuaci\u00f3n de una coincidencia para \"Star Trek\" en el t\u00edtulo<\/strong> valdr\u00e1 el doble que un partido en el visi\u00f3n general<\/strong> uno. B\u00e1sicamente, as\u00ed puede sugerir c\u00f3mo deben ordenarse los resultados de la b\u00fasqueda.<\/p>\n
 <\/p>\n
\u00bfPor qu\u00e9 no utiliza todo el mundo la b\u00fasqueda de texto completo?<\/strong><\/h2>\n
Por lo general, FTS exige que se configure una infraestructura completamente nueva, se a\u00f1adan nuevas dependencias, se creen varios \u00edndices y, a continuaci\u00f3n, se env\u00eden todos los cambios de los documentos a un sistema externo como B\u00fasqueda el\u00e1stica<\/a> o Solr, incluso si s\u00f3lo desea implementar una b\u00fasqueda muy simple como nuestro ejemplo anterior. As\u00ed pues, los desarrolladores tienden a evitar esta ingente cantidad de trabajo hasta que se hace estrictamente necesario.<\/p>\n
Esa es una de las razones por las que hemos decidido incorporar un motor FTS llamado Bleve<\/a> en Couchbase, entonces todo lo que necesitas hacer es crear un nuevo \u00edndice en la Consola Web:<\/p>\n
\"movie_index_creation\"<\/p>\n
Y autom\u00e1ticamente podr\u00e1s hacer b\u00fasquedas de texto completo usando el SDK de Couchbase por defecto:<\/p>\n
String indexName = \"movies_index\";\r\nPhraseQuery query = SearchQuery.phrase(\"Star Trek\");\r\nSearchQueryResult result = movieRepository.getCouchbaseOperations().getCouchbaseBucket().query(\r\n    new SearchQuery(indexName, query).highlight().limit(20));<\/pre>\n
 <\/p>\n
La mayor\u00eda de las bases de datos relacionales ya admiten b\u00fasquedas de texto completo, \u00bfpor qu\u00e9 no utilizarlas?<\/strong><\/h3>\n
\u00a0<\/strong>En realidad, podr\u00eda ser una buena opci\u00f3n para peque\u00f1os casos de uso, y he o\u00eddo algunos comentarios positivos de los desarrolladores que lo hacen. Mi recomendaci\u00f3n personal es que consideres una herramienta adecuada, como Bleve, siempre que tengas un volumen considerable de datos, o siempre que necesites escalar masivamente.<\/p>\n
Otra gran ventaja de utilizar un motor FTS adecuado es el lenguaje de consulta. La mayor\u00eda de las bases de datos relacionales intentan reutilizar SQL para ello, y puede resultar realmente complicado si se intentan escribir b\u00fasquedas avanzadas. Al fin y al cabo, SQL no se dise\u00f1\u00f3 para tratar consultas de conjunci\u00f3n\/disyunci\u00f3n, facetas, factores de clasificaci\u00f3n complejos, etc.<\/p>\n
 <\/p>\n
Serie de b\u00fasqueda de texto completo<\/strong><\/h4>\n