{"id":15770,"date":"2024-05-28T15:11:01","date_gmt":"2024-05-28T22:11:01","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=15770"},"modified":"2025-06-13T20:19:14","modified_gmt":"2025-06-14T03:19:14","slug":"querying-vectors-challenges","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/querying-vectors-challenges\/","title":{"rendered":"Vectores de consulta y lo que puede fallar con ellos"},"content":{"rendered":"

Couchbase 7.6 presenta B\u00fasqueda vectorial en la arquitectura Couchbase<\/a>est\u00e1 ampliando sus capacidades de b\u00fasqueda a pasos agigantados. Este art\u00edculo muestra c\u00f3mo afecta esto a las consultas de b\u00fasqueda, c\u00f3mo tenemos que adaptarnos en determinadas situaciones y c\u00f3mo utilizar eficientemente esta \u00faltima caracter\u00edstica. Para asegurarse de que sus b\u00fasquedas vectoriales son las mejores posibles, debe ser consciente de problemas como las consultas lentas causadas por \u00edndices ineficaces, consultas ineficientes o datos que cambian con frecuencia, as\u00ed como otros casos de fallo como tiempos de espera, errores de coherencia, app herder, etc.<\/span><\/p>\n

Introducci\u00f3n a las consultas vectoriales<\/span><\/h2>\n

Hubo que adaptar las consultas de b\u00fasqueda para permitir el uso de vectores. Se trata esencialmente de un nuevo tipo de consulta que permite <\/span>b\u00fasqueda de similitudes<\/span><\/i> en lugar de la b\u00fasqueda exacta. La diferencia es que ya no buscamos coincidencias exactas cuando se trata de vectores, sino las m\u00e1s pr\u00f3ximas al vector especificado en la consulta:<\/span><\/p>\n

{\r\n  \"consulta\": {\r\n    \"match_none\": {}\r\n  },\r\n  \"knn\": [\r\n    {\r\n      \"field\": \"vector\",\r\n      \"vector\": [0.04603520780801773, ..., -0.08424953371286392],\r\n      \"k\": 3\r\n    }\r\n  ]\r\n}<\/pre>\n
Se trata de una consulta vectorial. Difiere bastante de una consulta normal. Todas las partes vectoriales de la consulta est\u00e1n bajo una nueva clave llamada knn<\/em>introducido con el \u00fanico fin de realizar consultas vectoriales. El sitio k<\/em> en la consulta determina el n\u00famero de documentos que queremos en los resultados. Esto es necesario porque en lugar de buscar la coincidencia exacta, nos preocupa encontrar la k<\/em> vectores m\u00e1s cercanos al vector buscado. Esta consulta acabar\u00e1 devolviendo tres vectores que la b\u00fasqueda considera que son los m\u00e1s cercanos al vector de consulta.<\/span><\/p>\n
{\r\n  \"consulta\": \"content:car\",\r\n  \"knn\": [\r\n    {\r\n      \"field\": \"vector\",\r\n      \"vector\": [0.04603520780801773, ..., -0.08424953371286392],\r\n      \"k\": 3\r\n    }\r\n  ]\r\n}<\/pre>\n
Tambi\u00e9n puede combinar una consulta vectorial con una consulta normal para obtener un <\/span>b\u00fasqueda h\u00edbrida<\/span><\/i><\/a>. En este caso, la b\u00fasqueda realiza la consulta en dos fases. En la primera fase se realiza la b\u00fasqueda vectorial, fusionando todos los resultados de las distintas particiones, y en la segunda fase se realiza la b\u00fasqueda regular, utilizando los resultados de la primera fase. Este enfoque permite un mejor rendimiento tanto en t\u00e9rminos de tiempo como de cantidad de datos pasados entre los nodos.<\/span><\/p>\n
Ahora que ya sabemos c\u00f3mo consultar vectores, repasemos las situaciones de fallo m\u00e1s habituales. \u00bfQu\u00e9 puede fallar durante una consulta vectorial?<\/span><\/p>\n
Identificaci\u00f3n de consultas lentas<\/span><\/h2>\n
Uno de los tipos m\u00e1s comunes de fallo de consulta es la consulta lenta. Se denomina consulta lenta a aquella que permanece mucho tiempo proces\u00e1ndose en el sistema. Dependiendo del tiempo de espera establecido para esta consulta, puede permanecer en ejecuci\u00f3n durante mucho tiempo.<\/span><\/p>\n
Hay muchas razones por las que esto ocurre. Una de las m\u00e1s sencillas es que la ejecuci\u00f3n de una consulta sea demasiado costosa. Esto puede deberse a que haga referencia a demasiados documentos, a que el n\u00famero de documentos indexados sea enorme o a que el tipo de consulta sea comparativamente ineficiente.<\/span><\/p>\n
En t\u00e9rminos vectoriales, las causas m\u00e1s comunes de una consulta lenta se deben a un gran tama\u00f1o del \u00edndice con un n\u00famero insuficiente de particiones, un gran valor K en la consulta o incluso una alta tasa de ingesta de datos.<\/span><\/p>\n
Ahora que sabemos lo que es una consulta lenta, la siguiente pregunta que nos viene a la cabeza es, \u00bfc\u00f3mo sabemos que hay una consulta lenta en ejecuci\u00f3n? Una de las mejores maneras de hacerlo es comprobar los registros. Una consulta lenta se registrar\u00e1 cada 5 segundos. Este temporizador puede cambiarse utilizando las opciones del gestor y la l\u00ednea de registro tendr\u00e1 el siguiente aspecto:<\/span><\/p>\n
\"\"<\/a><\/span><\/p>\n
Otra forma es mirar las estad\u00edsticas. Hay una estad\u00edstica disponible en <\/span>\/api\/nsstats<\/span><\/i> llamado <\/span>total_consultas_lentas<\/span><\/i> que registrar\u00e1 el n\u00famero de veces que se ha detectado una consulta lenta:<\/span><\/p>\n
\"\"<\/a><\/p>\n
Tambi\u00e9n hay algunas estad\u00edsticas m\u00e1s que se pueden observar en el mismo endpoint que podr\u00edan darnos alguna pista sobre lo que est\u00e1 ocurriendo con la consulta internamente y d\u00f3nde podr\u00edan estar los problemas:<\/span><\/p>\n