Índices de pesquisa numérica

Além de indexar texto, o índice de pesquisa oferece uma maneira eficiente de indexar números. Ele é usado principalmente para aumentar as consultas de pesquisa de texto completo com condições em campos numéricos. Nesta página, descrevemos a indexação de números para consultas de igualdade e desigualdade e a indexação de uma matriz de números.

Tokenizar números

Os tokenizadores de números são usados para gerar um conjunto de tokens que são usados para acelerar as pesquisas de comparação numérica.

Use a função TOKENIZE_NUMBER para criar um índice numérico. O TOKENIZE_NUMBER é compatível com INT64, FLOAT32, FLOAT64 ou ARRAY desses tipos.

Para o PostgreSQL, use a função spanner.tokenize_number para criar um índice numérico. spanner.tokenize_number só aceita o tipo bigint.

Indexar números para consultas de igualdade e desigualdade

O Spanner é compatível com a indexação de números para igualdade e desigualdade. As pesquisas de igualdade correspondem a um número. As pesquisas de intervalo e desigualdade correspondem a um número dentro de um intervalo específico. Defina esse valor no parâmetro TOKENIZE_NUMBER comparison_type:

  • Igualdade: comparison_type=>"equality"
  • Desigualdade e igualdade: comparison_type=>"all"

Em ambos os casos, o número original (inteiro ou ponto flutuante) passa por um processo de tokenização, que é conceitualmente semelhante à tokenização de texto completo. Ele produz um conjunto de tokens que a consulta pode usar para localizar documentos que correspondem à condição numérica.

A indexação de igualdade produz apenas um token, que representa o número. Esse modo é recomendado se as consultas tiverem apenas condições na forma de field = @p na cláusula WHERE.

A indexação de desigualdade e igualdade pode acelerar uma variedade maior de condições na cláusula WHERE da consulta. Isso inclui field < @p, field <= @p, field > @p, field >= @p, field BETWEEN @p1 and @p2 e field <> @p, além de condições de igualdade. Para implementar esse tipo de indexação, o Spanner produz tokens no índice da Pesquisa subjacente. O Spanner pode produzir muitos tokens para cada número indexado, dependendo dos parâmetros de ajuste. O número de tokens depende dos parâmetros definidos para TOKENIZE_NUMBER, como algorithm, min, max e granularity. Portanto, é importante avaliar os parâmetros de ajuste com cuidado para garantir um equilíbrio adequado entre o armazenamento em disco e o tempo de pesquisa.

Para consultas de intervalo em tipos de números inteiros, como INT64, especificar algorithm => "prefixtree" pode melhorar significativamente o desempenho em comparação com o algoritmo padrão logtree. Esse algoritmo gera tokens com base em prefixos de números, permitindo uma remoção mais eficiente do espaço de pesquisa para condições de intervalo (por exemplo, <= e >=). Para consultas em que a cláusula WHERE contém predicados de intervalo, o algoritmo prefixtree gera menos tokens de índice para números pequenos em comparação com logtree, o que pode melhorar o desempenho e o custo de armazenamento.

Tokenização de matriz

Além de valores escalares, o TOKENIZE_NUMBER oferece suporte à tokenização de uma matriz de números. Os exemplos nesta seção são para bancos de dados de dialeto do GoogleSQL. O PostgreSQL não oferece suporte à aceleração de matriz numérica com índices da Pesquisa.

Quando TOKENIZE_NUMBER é usado com a coluna ARRAY, é necessário especificar comparison_type=>"equality". As consultas de intervalo não são compatíveis com uma matriz de números.

  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(Ratings_Tokens);
  ```

The following query finds all albums that have a rating of 1 or 2:

 ```sql
  SELECT AlbumId
  FROM Albums
  WHERE ARRAY_INCLUDES_ANY(Ratings, [1, 2])
  ```

The following query finds all albums that were rated as 1 and as 5:

```sql
SELECT AlbumId
FROM Albums
WHERE ARRAY_INCLUDES_ALL(Ratings, [1, 5])
```

### Options for indexing high-precision numbers not supported by `TOKENIZE_NUMBER`

If you need to perform search queries on numeric types not directly supported by
`TOKENIZE_NUMBER` (such as `NUMERIC` or `BIGNUMERIC`),
consider these options:

*   **Schema Modification:** Change the column type to `INT64` for the subset of
    data that fits within the `INT64` range. Handle values exceeding the `INT64`
    range separately, potentially in a different table or using application
    logic.

*   **Conceptual Mapping to Supported Types:** Explore creating generated
    columns to map the `NUMERIC` values to an `INT64` range. This would allow
    `TOKENIZE_NUMBER` to be used on the generated column. Be sure to validate
    the query results against the original `NUMERIC` column in case your mapping
    does not perfectly preserve precision. The specifics of the mapping function
    needed for this approach are highly dependent on your specific data.

## What's next

*   Learn about [tokenization and Spanner
    tokenizers](/spanner/docs/full-text-search/tokenization).
*   Learn about [search indexes](/spanner/docs/full-text-search/search-indexes).
*   Learn about [index
    partitioning](/spanner/docs/full-text-search/partition-search-index).