Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Información general de la búsqueda vectorial
ElastiCache for Valkey proporciona capacidades para indexar, buscar y actualizar miles de millones de incrustaciones vectoriales de alta dimensión. La búsqueda vectorial le permite crear, mantener y usar índices secundarios para una búsqueda eficiente y escalable. Cada operación de búsqueda vectorial se aplica a un único índice. Las operaciones de índice se aplican únicamente al índice especificado. Se puede realizar cualquier número de operaciones con cualquier índice en cualquier momento, a excepción de las operaciones de creación y eliminación de índices. En el clúster es posible que se realicen simultáneamente varias operaciones con varios índices.
En este documento, los términos clave, fila y registro son idénticos y se usan indistintamente. Del mismo modo, los términos columna, campo, ruta y miembro también se usan indistintamente.
El comando FT.CREATE se puede utilizar para crear un índice para un subconjunto de claves con los tipos de índice especificados. FT.SEARCH realiza consultas en los índices creados y FT.DROPINDEX elimina un índice existente y todos los datos asociados. No existen comandos especiales para añadir, eliminar o modificar los datos indexados. Los comandos HASH o JSON existentes que modifican una clave que está en un índice también lo actualizan automáticamente.
Temas
Los índices y el espacio de claves de Valkey OSS
Los índices se construyen y mantienen en un subconjunto del espacio de claves de Valkey OSS. Durante la creación del índice se proporciona una lista de prefijos clave que definen el espacio de claves de cada índice. La lista de prefijos es opcional y, si se omite, todo el espacio de claves formará parte de ese índice. Los índices múltiples pueden elegir subconjuntos disociados o superpuestos del espacio de claves sin limitación alguna.
Los índices también están tipificados en el sentido de que solo incluyen las claves de tipo coincidente. Actualmente, solo se admiten los índices de los tipos JSON y HASH. Un índice HASH solo indexa las claves HASH incluidas en su lista de prefijos y, de manera semejante, un índice JSON solo indexa las claves JSON incluidas en su lista de prefijos. Las claves incluidas en la lista de prefijos del espacio de claves de un índice que no poseen el tipo designado se ignoran y no afectan a las operaciones de búsqueda.
Cuando un comando modifica una clave que se encuentra dentro del espacio de claves de un índice, dicho índice se actualiza. Valkey extrae automáticamente los campos declarados para cada índice y actualiza el índice con el nuevo valor. El proceso de actualización consta de tres pasos. En el primer paso, se modifica la clave HASH o JSON y se bloquea el cliente solicitante. El segundo paso se realiza en segundo plano y actualiza cada uno de los índices que contienen la clave modificada. En el tercer paso, se desbloquea el cliente. Por lo tanto, en el caso de las operaciones de consulta realizadas en la misma conexión que una mutación, ese cambio es visible inmediatamente en los resultados de la búsqueda.
La creación de un índice es un proceso de varios pasos. El primer paso es ejecutar el comando FT.CREATE que define el índice. Al ejecutarse correctamente el comando create, se inicia automáticamente el segundo paso: la reposición. El proceso de reposición se ejecuta en un subproceso en segundo plano y analiza el espacio de claves en busca de claves que estén dentro de la lista de prefijos del nuevo índice. Cada clave que se encuentra se agrega al índice. Finalmente, se analiza todo el espacio de claves y se completa el proceso de creación del índice. Tenga en cuenta que mientras el proceso de relleno está en marcha, se permiten las mutaciones de las claves indexadas, no hay restricciones y el proceso de relleno del índice no finalizará hasta que todas las claves estén indexadas correctamente. No se permiten las operaciones de consulta realizadas mientras se está rellenando un índice y se las finaliza con un error. El comando FT.INFO devuelve el estado del proceso de relleno en el campo “backfill_status”.
El campo de índice escribe
Cada índice tiene un tipo específico que se declara cuando se crea el índice junto con la ubicación dentro de un campo (columna) que se va a indexar. En claves HASH, la ubicación es el nombre del campo dentro del HASH. En claves JSON, la ubicación es una descripción de la ruta JSON. Al modificar una clave, los datos asociados a los campos declarados se extraen, se convierten al tipo declarado y se almacenan en el índice. Si faltan los datos o no se pueden convertir correctamente al tipo declarado, ese campo se omite del índice. Hay cuatro tipos de campo, según se explica a continuación:
-
Los campos vectoriales contienen un vector de números, también conocido como incrustación de vectores. Los campos vectoriales se pueden usar para filtrar vectores en función de métricas de distancia específicas que miden la similitud. En índices
HASH, el campo debe contener todo el vector codificado en formato binario (IEEE 754 del tipo little-endian). En clavesJSON, la ruta debe hacer referencia a una matriz del tamaño correcto llena de números. Tenga en cuenta que cuando se utiliza una matriz JSON como campo vectorial, la representación interna de la matriz dentro de la clave JSON se convierte al formato exigido por el algoritmo seleccionado, lo que reduce el consumo y la precisión de memoria. Las operaciones de lectura posteriores con los comandos JSON darán como resultado el valor de precisión reducido. -
Los campos numéricos contienen un solo número. Los campos numéricos se pueden utilizar con el operador de búsqueda por rangos. En
HASH, se espera que el campo contenga el texto ASCII de un número escrito en el formato estándar para números de punto fijo o flotante. En camposJSON, se deben seguir las reglas numéricas de los números JSON. Independientemente de la representación que contenga la clave, este campo se convierte en un número de punto flotante de 64 bits para almacenarlo en el índice. Como los números subyacentes se almacenan en punto flotante con sus limitaciones de precisión, se aplican las reglas habituales sobre las comparaciones numéricas de números de punto flotante. -
Los campos de etiquetas contienen cero o más valores de etiqueta codificados como una sola cadena UTF-8. Los campos de etiquetas se pueden usar para filtrar las consultas y determinar la equivalencia de los valores de las etiquetas mediante una comparación que distinga entre mayúsculas y minúsculas o que no distinga entre mayúsculas y minúsculas. La cadena se analiza en valores de etiqueta mediante un carácter separador (el valor predeterminado es una coma, pero se puede anular) y se eliminan los espacios en blanco iniciales y finales. Se puede incluir cualquier número de valores de etiqueta en un único campo de etiqueta.
Algoritmos de índice vectorial
Valkey admite dos algoritmos de índice vectorial:
-
FLAT: el algoritmo Flat es un procesamiento lineal de fuerza bruta de cada vector del índice, que da como resultado respuestas exactas dentro de los límites de la precisión de los cálculos de distancia. Debido al procesamiento lineal del índice, los tiempos de ejecución de este algoritmo pueden ser muy altos para índices grandes. Los índices planos admiten velocidades de ingesta más altas.
-
Pequeño mundo navegable jerárquico (HNSW): el algoritmo HNSW es una alternativa que proporciona una aproximación de las coincidencias vectoriales más cercanas a cambio de tiempos de ejecución considerablemente más bajos. El algoritmo está controlado por tres parámetros,
MEF_CONSTRUCTIONyEF_RUNTIME. Los dos primeros parámetros se especifican en el momento de la creación del índice y no se pueden cambiar. El parámetroEF_RUNTIMEtiene un valor predeterminado que se especifica al crear el índice, pero se puede anular posteriormente en cualquier operación de consulta individual. Estos tres parámetros interactúan para equilibrar el consumo de memoria y de CPU durante las operaciones de incorporación y consulta, así como para controlar la calidad de la aproximación de una búsqueda KNN exacta (conocida como relación de recuperación).
En HNSW, el parámetro M controla el número máximo de vecinos a los que se puede conectar cada nodo, lo que da forma a la densidad del índice. Una M más alta, de 32 o superior, produce un gráfico más conectado, lo que mejora la velocidad de recuperación y consulta, ya que existen más rutas para llegar a los vecinos pertinentes. Sin embargo, aumenta el tamaño del índice y del uso de memoria y ralentiza la indexación. Una M más baja, como 8 o inferior, produce un faster-to-build índice más pequeño con un menor uso de memoria, pero la recuperación disminuye y las consultas pueden tardar más debido al menor número de conexiones.
El parámetro EF_construction indica cuántas conexiones candidatas se evalúan al crear el índice. Un EF_construction más alto, de 400 o superior, significa que el indexador considera más rutas antes de seleccionar los vecinos, lo que se traduce en un gráfico que mejora la eficiencia tanto de la recuperación como de las consultas en el futuro, pero a costa de una indexación más lenta y un mayor uso de CPU y memoria durante la construcción. Un EF_construction bajo, de entre 64 y 120, acelera la indexación y reduce el uso de recursos, pero el gráfico resultante puede reducir la recuperación y la lentitud de las consultas, incluso si EF_runtime tiene un valor alto.
Por último, EF_runtime regula la amplitud de la búsqueda durante la consulta, controlando el número de vecinos candidatos que se explora en tiempo de ejecución. Si se establece en un valor alto, aumenta la recuperación y la precisión, pero a costa de la latencia de las consultas y del uso de la CPU. Un EF_runtime bajo hace que las consultas sean más rápidas y ligeras, pero con una menor capacidad de recuperación. A diferencia de M o EF_construction, este parámetro no afecta al tamaño del índice ni al tiempo de creación, por lo que se convierte en el parámetro para ajustar las compensaciones entre recuperación y latencia una vez creado un índice.
Ambos algoritmos de búsqueda vectorial (FLAT y HNSW) admiten un parámetro INITIAL_CAP opcional. Si se especifica, este parámetro asigna previamente memoria a los índices, lo que da como resultado una reducción de la sobrecarga de administración de la memoria y aumenta las tasas de incorporación vectorial. Los índices planos admiten mejores velocidades de ingesta que HNSW.
Es posible que los algoritmos de búsqueda vectorial, como el HNSW, no gestionen de manera eficiente la eliminación o la sobrescritura de los vectores previamente insertados. El uso de estas operaciones puede provocar un consumo excesivo de memoria indexada y and/or degradar la calidad de la recuperación. La reindexación es un método para restaurar la recuperación del uso óptimo de la memoria. and/or
Seguridad de búsqueda vectorial
Los mecanismos de seguridad de ACL (listas de control de acceso) de Valkey@search, y muchas de las categorías existentes (@fast, @read, @write, etc.) se actualizan para incluir los nuevos comandos. Los comandos de búsqueda no modifican los datos clave, lo que significa que se conserva la maquinaria ACL existente para el acceso de escritura. La presencia de un índice no modifica las reglas de acceso para las operaciones HASH y JSON; se sigue aplicando el control de acceso normal en la clave a estos comandos.
El acceso de los comandos de búsqueda con un índice también se controla mediante la ACL. Las comprobaciones de acceso se realizan a nivel de índice completo, no al nivel de la clave. Esto significa que el acceso a un índice se garantiza a un usuario solo si ese usuario tiene permiso para acceder a todas las claves posibles de la lista de prefijos del espacio de claves de ese índice. En otras palabras, el contenido real de un índice no controla el acceso. Más bien, es el contenido teórico de un índice, tal como se define en la lista de prefijos, el que se utiliza para el control de seguridad. Es posible que se produzcan situaciones en las que un usuario tenga acceso de lectura y and/or escritura a una clave, pero no pueda acceder a un índice que contiene esa clave. Tenga en cuenta que solo se requiere acceso de lectura al espacio de claves para crear o usar un índice; no se tiene en cuenta la presencia o ausencia del acceso de escritura.
