Índices numéricos

Además de indexar texto, el El índice de búsqueda proporciona una manera eficiente de números de índice. Se usa principalmente para aumentar búsqueda en el texto completo con condiciones en campos numéricos. En esta página, se describe cómo agregar una búsqueda numérica índices a tablas y cómo asignar tokens a los arrays.

Descripción general

Spanner admite números de indexación para las siguientes operaciones de consulta:

  • Igualdad (comparison_type=>"equality")
  • Inequality (comparison_type=>"all")

En ambos casos, el número original (ya sea de número entero o punto flotante) experimenta un proceso de asignación de token, que es conceptualmente similar al de texto completo la asignación de token. Produce un conjunto de tokens que la consulta luego puede usar para localizar documentos que coincidan con la condición de número.

La indexación de igualdad solo produce un token, que representa el número. Se recomienda este modo si las consultas solo tienen condiciones en forma de field = @p en la cláusula WHERE.

La indexación de desigualdad e igualdad puede acelerar una gama más amplia de condiciones la cláusula WHERE de la consulta. Esto incluye field < @p, field <= @p, field > @p, field >= @p, field BETWEEN @p1 and @p2 y field <> @p in además de las condiciones de igualdad. Para implementar este tipo de indexación, Spanner produce tokens en el índice de búsqueda subyacente. Spanner puede producir muchos tokens para cada número indexado, según los parámetros de ajuste. La cantidad de tokens depende de los parámetros configurados para TOKENIZE_NUMBER, como algorithm, min, max y granularity Por lo tanto, es importante evaluar los parámetros de ajuste con cuidado para garantizar un equilibrio adecuado entre almacenamiento en disco y tiempo de búsqueda.

Algoritmos para rangos de números de índice

El argumento TOKENIZE_NUMBER algorithm tiene tres opciones para indexar rangos de números: logtree, prefixtree y floatingpoint. Cada El algoritmo es mejor para indexar ciertas distribuciones de datos y rangos de consulta:

  • logtree es mejor para indexar columnas distribuidas de manera uniforme que contengan en números enteros. Es el algoritmo predeterminado.
  • prefixtree es mejor cuando se indexan datos distribuidos de forma exponencial y cuando el predicado de consulta es del tipo "@param > number" o "@param >= number" (rangos sin un límite superior). En comparación con logtree, este algoritmo genera menos tokens de índice para números pequeños. Para consultas en las que la cláusula WHERE contiene el predicado que antes como se describió, prefixtree genera menos tokens de consulta, lo que puede mejorar rendimiento.
  • floatingpoint es mejor para indexar valores FLOAT64 en los que los datos indexados y las consultas suelen contener fracciones. Dado que los otros algoritmos solo indexan números enteros, las consultas que cubren rangos fraccionarios tienen probabilidades de recuperar más valores no coincidentes. Estos valores que no coinciden deben filtrarse después de la recuperación, lo que afecta negativamente el rendimiento. En comparación con logtree y prefixtree, este algoritmo genera una mayor cantidad de tokens de índice y podría generar más tokens de consulta.

El parámetro base controla el ancho de cada bucket de árbol en el logtree. prefixtree. Ambos algoritmos generan tokens que representan los nodos de un Árbol de base en el que el ancho de un nodo es basedistance_from_leaf Los algoritmos difieren en que prefixtreeomite algunos de los nodos del árbol en favor de tokens mayores que aceleran las consultas mayores que. Cuanto más grande sea la base seleccionada, menos tokens de índice se generarán. Sin embargo, los valores más grandes de base aumentan la cantidad máxima de búsquedas. y se requieren tokens.

Los números que se encuentran fuera del rango [min, max] se indexan en dos buckets: uno para todos los números inferiores a min y el otro para todos los números superiores a max. Esto puede causar una sobrerecuperación significativa (recuperación de demasiadas números) cuando el rango solicitado por la consulta también incluye números fuera de el rango. Por este motivo, configura min y max con los valores más reducidos posibles que abarquen todos los números de entrada. Al igual que todas las configuraciones de tokenización, cambiar los valores de min y max requiere una nueva compilación del índice numérico, por lo que debes dejar espacio para el crecimiento si no se conoce el dominio final de una columna. El problema de recuperación excesiva no es un problema de precisión, ya que todas las coincidencias posibles son verificarse con números que no estén agrupados en buckets al final del proceso de búsqueda; es solo un posible problema de eficiencia.

El argumento granularity controla la tasa de reducción de muestreo que se aplica a de entrada antes de que se indexen en los algoritmos de árbol. Antes de cada número se asigna un token, se ordena en buckets con un ancho igual a granularity. Todas los números del mismo bucket granularity obtienen los mismos tokens. Esto significa que podría producirse una recuperación excesiva si el valor de nivel de detalle se establece en cualquier valor que no sea 1. También significa que, si los valores numéricos cambian en una cantidad pequeña, no es necesario volver a indexar la mayoría de sus tokens. Usa un granularity mayor que 1 también reduce la cantidad de tokens que el algoritmo necesita generar, pero el efecto es menos significativo que el efecto de aumentar base Por lo tanto, recomendamos que el “nivel de detalle” está establecido en 1.

Asignación de token de array

Además de los valores escalares, TOKENIZE_NUMBER admite la tokenización de un array de números.

Cuando se usa TOKENIZE_NUMBER con la columna ARRAY, debes especifica comparison_type=>"equality". Las consultas por rango no son compatibles con un array de números.

Por ejemplo, considera el siguiente esquema:

CREATE TABLE Albums (
  AlbumId STRING(MAX) NOT NULL,
  Ratings ARRAY<INT64>,
  Ratings_Tokens TOKENLIST
    AS (TOKENIZE_NUMBER(Ratings, comparison_type=>"equality")) HIDDEN
) PRIMARY KEY(AlbumId);

CREATE SEARCH INDEX AlbumsIndex ON Albums(Grades_Tokens);

La siguiente consulta busca todos los álbumes que tienen una calificación de 1 o 2:

SELECT AlbumId
FROM Albums
WHERE ARRAY_CONTAINS_ANY(Ratings, [1, 2])

La siguiente consulta busca todos los álbumes que fueron calificados con 1 y 5:

SELECT AlbumId
FROM Albums
WHERE ARRAY_CONTAINS_ALL(Ratings, [1, 5])

¿Qué sigue?