{"id":16437,"date":"2024-10-09T16:21:05","date_gmt":"2024-10-09T23:21:05","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=16437"},"modified":"2025-06-13T16:36:38","modified_gmt":"2025-06-13T23:36:38","slug":"couchbase-xattrs-vector-search","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/couchbase-xattrs-vector-search\/","title":{"rendered":"Mejora del rendimiento mediante XATTR para el almacenamiento y la b\u00fasqueda de vectores"},"content":{"rendered":"

Con la introducci\u00f3n de b\u00fasqueda vectorial<\/a>ahora los usuarios pueden almacenar matrices de vectores de gran tama\u00f1o<\/em>-a menudo formados por n\u00fameros aparentemente arbitrarios- dentro de sus documentos. Dado que estos datos no son necesarios para la mayor\u00eda de las consultas est\u00e1ndar, ahora los usuarios pueden aprovechar atributos ampliados<\/em> (XATTRs), que forman parte de los metadatos del documento, para almacenar vectores y otros contenidos voluminosos. De este modo, se mejora el rendimiento al mantener los datos pesados fuera de la ruta de consulta principal. En este art\u00edculo se explica qu\u00e9 son los XATTR, se destacan sus ventajas y se muestra c\u00f3mo pueden utilizarse en las b\u00fasquedas.<\/p>\n

\u00bfD\u00f3nde est\u00e1n \u00bfXATTRs?<\/span><\/h2>\n

Los XATTR son los metadatos de un documento que un usuario puede modificar o cambiar sin alterar el contenido del documento. Esto permite separar el documento en dos partes. Los servicios que necesiten los documentos los obtendr\u00e1n del almac\u00e9n de valores clave (KV), que obtiene el contenido de los XATTR s\u00f3lo cuando es necesario.<\/span><\/p>\n

Tomemos un ejemplo en el que el usuario est\u00e1 intentando indexar datos de un hotel cuya estructura documental tiene el siguiente aspecto:<\/span><\/p>\n

{\r\n  \"t\u00edtulo\": \"Gillingham (Kent)\",\r\n  \"name\": \"Albergue Juvenil Medway\",\r\n  \"address\": \"Capstone Road, ME7 3JE\",\r\n  \"directions\": null,\r\n  \"phone\": \"+44 870 770 5964\",\r\n  \"tollfree\": null,\r\n  \"email\": null,\r\n  \"fax\": null,\r\n  \"url\": \"https:\/\/www.yha.org.uk\",\r\n  \"checkin\": null,\r\n  \"checkout\": null,\r\n  \"price\": null,\r\n  \"geo\": {\r\n    \"lat\": 51.35785,\r\n    \"lon\": 0.55818,\r\n    \"accuracy\": \"RANGO_INTERPOLADO\"\r\n  },\r\n  \"id\": 10025,\r\n  \"country\": \"Reino Unido\",\r\n  \"city\": \"Medway\",\r\n  \"estado\": null,,\r\n  \"vacante\": true\r\n  \"descripci\u00f3n\": \"Albergue de verano de 40 camas a unos 5 km de Gillingham, ubicado en una intrincada Oast House reconvertida en un entorno semirural\",\r\n  \"description_vector\": [0.9293051,...(108 m\u00e1s float32s)...,0.41247833],\r\n  \"pets_ok\": true,\r\n  \"free_breakfast\": true,\r\n  \"free_internet\": false,\r\n  \"free_parking\": true\r\n}<\/pre>\n
Esta estructura de documento incluye todos los campos necesarios para un hotel, junto con una descripci\u00f3n vectorizada utilizada para encontrar hoteles con descripciones similares. El vector de descripci\u00f3n (l\u00ednea 25), que es un vector de 110 dimensiones, ocupa unos 1.400 bytes, mientras que el resto del documento tiene un tama\u00f1o de unos 1.400 bytes.<\/span><\/p>\n
En los casos de uso habituales, cuando un usuario ejecuta una consulta no vectorial con SQL++ sin un \u00edndice de cobertura, se obtiene el documento completo. Esto significa que, aunque el vector, que ocupa casi la mitad del documento, no sea necesario, se recupera junto con el resto del documento, con el consiguiente derroche de recursos.<\/span><\/p>\n
Imaginemos una situaci\u00f3n en la que el usuario no utiliza XATTRs y tiene la totalidad de los datos dentro del contenido del documento y ninguno de ellos dentro de XATTRs. Cualquier servicio, como los de consulta y b\u00fasqueda, que intente recuperar documentos tendr\u00e1 que procesar todo el contenido del documento para obtener lo que desea.<\/span><\/p>\n
\"\"<\/p>\n
Una forma mejor de estructurar este documento ser\u00eda almacenar el vector como parte de XATTRs. Esto significar\u00eda que los servicios que vienen en busca de los datos no vectoriales s\u00f3lo ir\u00e1n a trav\u00e9s del contenido del documento no XATTRs reduciendo as\u00ed la cantidad de datos transferidos a la mitad.<\/span><\/p>\n
\"\"<\/p>\n
Los usuarios pueden incluso llevar esto al extremo a\u00f1adiendo otros campos poco utilizados, como informaci\u00f3n geogr\u00e1fica, datos de contacto, etc., tambi\u00e9n en XATTR. Esto reduce a\u00fan m\u00e1s la cantidad de datos innecesarios transferidos.<\/span><\/p>\n
\"\"<\/p>\n
C\u00f3mo indexar Couchbase XATTRs<\/span><\/h2>\n
A partir de Couchbase Server 7.6.2, la funci\u00f3n servicio de b\u00fasqueda<\/a> ofrece a los usuarios la posibilidad de ingerir datos presentes en XATTRs s\u00f3lo cuando lo requiera la asignaci\u00f3n del \u00edndice durante el proceso de creaci\u00f3n del mismo. Si los datos de XATTRs no son relevantes y no existe una asignaci\u00f3n de XATTRs en la definici\u00f3n del \u00edndice, los usuarios pueden esperar una ingesta de datos y una indexaci\u00f3n m\u00e1s r\u00e1pidas, ya que se obtiene una carga \u00fatil m\u00e1s ligera del servicio de datos.<\/span><\/p>\n
Supongamos que un usuario ha creado un \u00edndice que indexa el contenido de XATTRs. La definici\u00f3n del \u00edndice ser\u00eda algo parecido a esto, con XATTRs indexados en las l\u00edneas 10-27:<\/span><\/p>\n
{\r\n    \"nombre\": \"ejemplo-index\",\r\n    \"type\": \"fulltext-index\",\r\n    \"params\": {\r\n    \"mapping\": {\r\n    \"default_mapping\": {\r\n    \"enabled\": true\r\n    \"dynamic\": true,\r\n    \"properties\": {\r\n      \"_$xattrs\": {\r\n        \"enabled\": true\r\n        \"dynamic\": true,\r\n        \"properties\": {\r\n        \"textField\": {\r\n        \"enabled\": true\r\n        \"dynamic\": false,\r\n        \"fields\": [\r\n            {\r\n            \"name\": \"textField\",\r\n            \"type\": \"text\",\r\n            \"store\": false\r\n            \"index\": true\r\n            \"include_term_vectors\": false,\r\n            \"include_in_all\": falso,\r\n            \"docvalues\": false\r\n            }\r\n        ]\r\n        }\r\n        }\r\n        }\r\n    }\r\n    },\r\n    \"default_type\": \"_default\",\r\n    \"default_analyzer\": \"standard\",\r\n    \"default_datetime_parser\": \"dateTimeOptional\",\r\n    \"default_field\": \"_all\",\r\n    \"store_dynamic\": false,\r\n    \"index_dynamic\": true,\r\n    \"docvalues_dynamic\": false\r\n    },\r\n    \"store\": {\r\n    \"indexType\": \"scorch\",\r\n    \"kvStoreName\": \"\"\r\n    },\r\n    \"doc_config\": {\r\n    \"mode\": \"type_field\",\r\n    \"type_field\": \"type\",\r\n    \"docid_prefix_delim\": \"\",\r\n    \"docid_regexp\": \"\"\r\n    }\r\n    },\r\n    \"sourceType\": \"couchbase\",\r\n    \"sourceName\": \"sample-bucket\",\r\n    \"sourceUUID\": \"602c579bc2a74e67dc1f051eb769e702\",\r\n    \"sourceParams\": {},\r\n    \"planParams\": {\r\n    \"maxPartitionsPerPIndex\": 1024,\r\n    \"numReplicas\": 0,\r\n    \"indexPartitions\": 1\r\n    },\r\n    \"uuid\": \"\"\r\n}<\/pre>\n
Tras la creaci\u00f3n del \u00edndice mediante una definici\u00f3n de \u00edndice como la anterior, la b\u00fasqueda obtendr\u00e1 todo el contenido del documento y el contenido XATTRs del servicio de datos.<\/span><\/p>\n
\"\"<\/p>\n
En este caso, tras obtener el contenido, el servicio de b\u00fasqueda combinar\u00e1 ambos en un \u00fanico documento. Los datos presentes en los XATTR se asignar\u00e1n al contenido del documento mediante una asignaci\u00f3n especial de campos denominada _$xattrs<\/code><\/em>\u00a0durante el proceso de indexaci\u00f3n.<\/span><\/p>\n
\"\"<\/p>\n
Para consultar los campos presentes en el contenido de los XATTRs, debe tenerse en cuenta que este contenido se colocar\u00e1 bajo un campo especial denominado _$xattrs<\/code> y la consulta debe reflejarlo. Tambi\u00e9n existe una restricci\u00f3n inherente al tama\u00f1o del nombre del campo XATTRs, que es de 12 caracteres.<\/span><\/p>\n
Este es el aspecto de la consulta de un documento de ejemplo con XATTRs<\/span>:<\/p>\n
{\r\n    \"explicar\": true\r\n    \"fields\": [\r\n        \"*\"\r\n    ],\r\n    \"highlight\": {},\r\n    \"consulta\": {\r\n        \"query\": \"_$xattrs.textField:*\"\r\n    },\r\n    \"size\": 10,\r\n    \"from\": 0\r\n}<\/pre>\n
Los XATTR no se limitan a almacenar vectores. Siempre que haya campos que se utilicen con poca frecuencia, campos s\u00f3lo espec\u00edficos del servicio de b\u00fasqueda o campos voluminosos, es aconsejable a\u00f1adirlos a las XATTR. De esta forma, los servicios que no necesiten estos campos tendr\u00e1n que obtener menos datos de KV.\u00a0<\/span><\/p>\n
Pr\u00f3ximos pasos<\/span><\/h2>\n