Con la introducción de búsqueda vectorialahora los usuarios pueden almacenar matrices de vectores de gran tamaño-a menudo formados por números aparentemente arbitrarios- dentro de sus documentos. Dado que estos datos no son necesarios para la mayoría de las consultas estándar, ahora los usuarios pueden aprovechar atributos ampliados (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ículo se explica qué son los XATTR, se destacan sus ventajas y se muestra cómo pueden utilizarse en las búsquedas.
¿Dónde están ¿XATTRs?
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án del almacén de valores clave (KV), que obtiene el contenido de los XATTR sólo cuando es necesario.
Tomemos un ejemplo en el que el usuario está intentando indexar datos de un hotel cuya estructura documental tiene el siguiente aspecto:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
{ "título: "Gillingham (Kent)", "nombre": "Albergue Juvenil Medway", "dirección": "Capstone Road, ME7 3JE", "direcciones": null, "teléfono": "+44 870 770 5964", "tollfree": null, "email": null, "fax": null, "url": "https://www.yha.org.uk", "checkin": null, "checkout": null, "precio": null, "geo": { "lat": 51.35785, "lon": 0.55818, "exactitud": "RANGO_INTERPOLADO" }, "id": 10025, "país": "Reino Unido", "ciudad": "Medway", "estado": null,, "vacante": verdadero, "descripción": "Albergue de verano de 40 camas a unos 5 km de Gillingham, ubicado en una intrincada Oast House reconvertida en un entorno semirural"., "vector_descripción": [0.9293051,...(108 más float32s)...,0.41247833], "pets_ok": verdadero, "desayuno_gratuito": verdadero, "free_internet": falso, "free_parking": verdadero } |
Esta estructura de documento incluye todos los campos necesarios para un hotel, junto con una descripción vectorizada utilizada para encontrar hoteles con descripciones similares. El vector de descripción (línea 25), que es un vector de 110 dimensiones, ocupa unos 1.400 bytes, mientras que el resto del documento tiene un tamaño de unos 1.400 bytes.
En los casos de uso habituales, cuando un usuario ejecuta una consulta no vectorial con SQL++ sin un índice 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.
Imaginemos una situación 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úsqueda, que intente recuperar documentos tendrá que procesar todo el contenido del documento para obtener lo que desea.
Una forma mejor de estructurar este documento sería almacenar el vector como parte de XATTRs. Esto significaría que los servicios que vienen en busca de los datos no vectoriales sólo irán a través del contenido del documento no XATTRs reduciendo así la cantidad de datos transferidos a la mitad.
Los usuarios pueden incluso llevar esto al extremo añadiendo otros campos poco utilizados, como información geográfica, datos de contacto, etc., también en XATTR. Esto reduce aún más la cantidad de datos innecesarios transferidos.
Cómo indexar Couchbase XATTRs
A partir de Couchbase Server 7.6.2, la función servicio de búsqueda ofrece a los usuarios la posibilidad de ingerir datos presentes en XATTRs sólo cuando lo requiera la asignación del índice durante el proceso de creación del mismo. Si los datos de XATTRs no son relevantes y no existe una asignación de XATTRs en la definición del índice, los usuarios pueden esperar una ingesta de datos y una indexación más rápidas, ya que se obtiene una carga útil más ligera del servicio de datos.
Supongamos que un usuario ha creado un índice que indexa el contenido de XATTRs. La definición del índice sería algo parecido a esto, con XATTRs indexados en las líneas 10-27:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 |
{ "nombre": "ejemplo-index", "tipo": "fulltext-index", "params": { "mapeo": { "default_mapping": { "activado": verdadero, "dinámico": verdadero, "propiedades": { "_$xattrs": { "activado": verdadero, "dinámico": verdadero, "propiedades": { "textField": { "activado": verdadero, "dinámico": falso, "campos": [ { "nombre": "textField", "tipo": "texto", "tienda": falso, "índice": verdadero, "include_term_vectors": falso, "incluir_en_todos": falso, "docvalues": falso } ] } } } } }, "tipo_por_defecto": "_por defecto", "default_analyzer": "estándar", "default_datetime_parser": "dateTimeOptional", "default_field": "_todos", "store_dynamic": falso, "index_dynamic": verdadero, "docvalues_dynamic": falso }, "tienda": { "tipo de índice": "chamuscar", "kvStoreName": "" }, "doc_config": { "mode": "tipo_campo", "tipo_campo": "tipo", "docid_prefix_delim": "", "docid_regexp": "" } }, "sourceType": "couchbase", "sourceName": "cubo de muestras", "sourceUUID": "602c579bc2a74e67dc1f051eb769e702", "sourceParams": {}, "planParams": { "maxPartitionsPerPIndex": 1024, "numReplicas": 0, "indexPartitions": 1 }, "uuid": "" } |
Tras la creación del índice mediante una definición de índice como la anterior, la búsqueda obtendrá todo el contenido del documento y el contenido XATTRs del servicio de datos.
En este caso, tras obtener el contenido, el servicio de búsqueda combinará ambos en un único documento. Los datos presentes en los XATTR se asignarán al contenido del documento mediante una asignación especial de campos denominada _$xattrs durante el proceso de indexación.
Para consultar los campos presentes en el contenido de los XATTRs, debe tenerse en cuenta que este contenido se colocará bajo un campo especial denominado _$xattrs y la consulta debe reflejarlo. También existe una restricción inherente al tamaño del nombre del campo XATTRs, que es de 12 caracteres.
Este es el aspecto de la consulta de un documento de ejemplo con XATTRs:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ "explicar": verdadero, "campos": [ "*" ], "destacar": {}, "consulta": { "consulta": "_$xattrs.textField:*" }, "tamaño": 10, "de": 0 } |
Los XATTR no se limitan a almacenar vectores. Siempre que haya campos que se utilicen con poca frecuencia, campos sólo específicos del servicio de búsqueda o campos voluminosos, es aconsejable añadirlos a las XATTR. De esta forma, los servicios que no necesiten estos campos tendrán que obtener menos datos de KV.
Próximos pasos
-
- Más información Conceptos de búsqueda vectorial en nuestros blogs, incluidos tutoriales y conceptos.
- Más información XATTRs mediante SDKs a través de nuestra documentación.
- Prueba gratuita de Couchbase Capella incluye búsqueda vectorial, entre otras muchas funciones. Pruébelo hoy mismo.
Increíble Blog.. Realmente me preguntaba si vectorizar el contenido de mi base de datos existente afectaría negativamente el rendimiento de búsqueda de mi aplicación existente
Buena explicación esquemática.
Gracias, Likith B.