Descripción general de la consulta

Nota de la interfaz de PostgreSQL: Los ejemplos de este tema están destinados a bases de datos de dialecto GoogleSQL. Esta función no es compatible con la interfaz de PostgreSQL.

Nota: Esta función está disponible en las ediciones de Spanner Enterprise y Edición Enterprise Plus. Para obtener más información, consulta la descripción general de las ediciones de Spanner.

En esta página, se describen la función SEARCH y el modo de consulta mejorado, que se usarse para realizar búsquedas en el texto completo consultas en tablas de Spanner.

Cómo consultar un índice de búsqueda

Spanner proporciona la función SEARCH para usar en las consultas de índices de búsqueda. Un ejemplo de caso de uso sería aplicación en la que los usuarios ingresan texto en un cuadro de búsqueda y la aplicación envía la entrada del usuario directamente a la función SEARCH. Luego, la función "BÚSQUEDA" usaría un índice de búsqueda para encontrar ese texto.

La función SEARCH requiere dos argumentos:

• Un nombre de índice de búsqueda
• Una búsqueda sin procesar

La función SEARCH solo funciona cuando se define un índice de búsqueda. El SEARCH función se puede combinar con cualquier construcción SQL arbitraria, como filtros, agregaciones o uniones.

La función SEARCH no se puede usar con consultas de transacciones.

En la siguiente consulta, se usa la función SEARCH para mostrar todos los álbumes que tengan friday o monday en el título:

SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'friday OR monday')

Búsquedas sin procesar y el lenguaje rquery

El segundo argumento de la función SEARCH es una búsqueda sin procesar. Spanner usa un lenguaje específico del dominio (DSL) llamado rquery.

El lenguaje rquery sigue las mismas reglas que el analizador de texto sin formato cuando divide la cadena de entrada en términos distintos. Esto incluye la segmentación de idiomas asiáticos.

Para obtener información sobre el uso de rquery, consulta Sintaxis de rquery.

Modo de consulta mejorado

Spanner ofrece dos modos de búsqueda en el texto completo: un modo básico y un modo más avanzado llamado enhance_query. Cuando está habilitado, enhance_query expande la búsqueda para incluir términos y sinónimos relacionados, lo que aumenta la probabilidad de encontrar resultados relevantes.

Para habilitar esta opción, configura el argumento opcional enhance_query=>true en la función SEARCH. Por ejemplo, la búsqueda hotl cal coincide con el álbum. Hotel California

SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'hotl cal', enhance_query=>true)

El modo enhance_query es una opción de tiempo de consulta. No afecta la tokenización. Puedes usar el mismo índice de búsqueda con o sin enhance_query.

Google mejora continuamente los algoritmos de mejora de las consultas. Como resultado, una consulta con enhance_query == true podría generar resultados ligeramente diferentes con el tiempo.

Cuando se habilita el modo enhance_query, es posible que aumente la cantidad de términos que busca la función SEARCH, lo que podría aumentar ligeramente la latencia.

Por ejemplo, la siguiente consulta usa un tiempo de espera de tres segundos y falla si enhance_query no está disponible:

@{require_enhance_query=true, enhance_query_timeout_ms=3000}
SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, 'fast car', enhance_query=>true)

Para obtener más información sobre el uso de la opción enhance_query, consulta la Función BÚSQUEDA.

Requisitos de las consultas de SQL

Existen varias condiciones que una consulta en SQL debe cumplir para usar un índice de búsqueda. Si no se cumplen estas condiciones, la consulta usa un plan de consultas alternativo. o falla si no existe un plan alternativo.

Las consultas deben cumplir con las siguientes condiciones:

• Las funciones SEARCH y SEARCH_SUBSTRING requieren un índice de búsqueda. Spanner no admite estas funciones en consultas a la tabla base ni a los índices secundarios.

• Los índices particionados deben tener todas las columnas de partición vinculadas por una condición de igualdad en la cláusula WHERE de la consulta.

  Por ejemplo, si un índice de búsqueda se define como PARTITION BY x, y, el valor La consulta debe tener un conjunto en la cláusula WHERE de x = <parameter or constant> AND y = <parameter or constant>. Ese índice de búsqueda no es considerada por el optimizador de consultas si dicha condición no se encuentra.

• Todas las columnas TOKENLIST a las que hacen referencia los operadores SEARCH y SEARCH_SUBSTRING deben indexarse en el mismo índice de búsqueda.

  Por ejemplo, considera la siguiente definición de índice y tabla:

  CREATE TABLE Albums (
      AlbumId STRING(MAX) NOT NULL,
      AlbumTitle STRING(MAX),
      AlbumStudio STRING(MAX),
      AlbumTitle_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumTitle)) HIDDEN,
      AlbumStudio_Tokens TOKENLIST AS (TOKENIZE_FULLTEXT(AlbumStudio)) HIDDEN
    ) PRIMARY KEY(AlbumId);
  
    CREATE SEARCH INDEX AlbumsTitleIndex ON Albums(AlbumTitle_Tokens);
    CREATE SEARCH INDEX AlbumsStudioIndex ON Albums(AlbumStudio_Tokens);
  

  La siguiente consulta falla porque no hay ningún índice de búsqueda que indexa AlbumTitle_Tokens y AlbumStudio_Tokens:

  SELECT AlbumId
  FROM Albums
  WHERE SEARCH(AlbumTitle_Tokens, @p1) AND SEARCH(AlbumStudio_Tokens, @p2)
  

• Si la columna de orden de clasificación es anulable, tanto el esquema como la consulta deben excluir las filas en las que la columna de orden de clasificación sea NULL. Para obtener más información, consulta Orden de clasificación del índice de búsqueda

• Si el índice de búsqueda tiene el filtro NULL, la consulta debe incluir el mismo Es la expresión de filtrado NULL que se usa en un índice. Consulta Índices de búsqueda con filtro de NULL para obtener más información.

• Los índices de búsqueda no son compatibles con el DML, el DML particionado ni las consultas particionadas.

• Por lo general, los índices de búsqueda se usan en transacciones de solo lectura. Si los requisitos de la aplicación permiten resultados inactivos, recomendamos ejecutar la búsqueda consultas con una duración de inactividad de 10 segundos o más. Para obtener más información, consulta Cómo leer datos inactivos. Esto es muy útil para las consultas de búsqueda grandes que se expanden a varios grupos de Paxos.

  No se recomiendan los índices de búsqueda en transacciones de lectura y escritura. Durante la ejecución, las consultas de búsqueda bloquean una partición de índice completa. Como resultado, una alta tasa de consultas de búsqueda en transacciones de lectura y escritura puede causar conflictos de bloqueo que generan aumentos repentinos de latencia. De forma predeterminada, los índices de búsqueda se seleccionan automáticamente en las transacciones de lectura y escritura. Si una consulta se ve obligada a usar un índice de búsqueda en una transacción de lectura y escritura, falla de forma predeterminada. Este comportamiento se puede anular con la sugerencia a nivel de la sentencia @{ALLOW_SEARCH_INDEXES_IN_TRANSACTION=TRUE} (pero las consultas aún son propensas a conflictos de bloqueo).

Una vez que se cumplen las condiciones de elegibilidad del índice, el optimizador de consultas intenta acelerar las condiciones de consulta que no son de texto (como Rating > 4). Si el índice de búsqueda no incluye la columna TOKENLIST adecuada, la condición no se acelera y sigue siendo una condición residual.

Parámetros de consulta

rquery y otros parámetros, como OFFSET, se especifican como un literal o un parámetro de consulta. Te recomendamos que uses parámetros de consulta para la búsqueda de texto completo en lugar de literales de cadena.

Selección de índices

Spanner suele seleccionar el índice más eficiente para una consulta con el modelado basado en costos. Sin embargo, la sugerencia FORCE_INDEX le indica de forma explícita a Spanner que use un índice de búsqueda específico. Por ejemplo, el A continuación, se muestra cómo forzar a Spanner a usar AlbumsIndex:

SELECT AlbumId
FROM Albums @{FORCE_INDEX=AlbumsIndex}
WHERE SEARCH(AlbumTitle_Tokens, "fifth symphony")

Si el índice de búsqueda especificado no es apto, la consulta falla, incluso si hay otros índices de búsqueda aptos.

Fragmentos en los resultados de la búsqueda

Un fragmento es un texto extraído de una cadena determinada que les brinda a los usuarios una idea de lo que contiene un resultado de la búsqueda y por qué es relevante para su consulta.

Por ejemplo, Gmail usa fragmentos para indicar la parte de un correo electrónico que coincide con la búsqueda:

Hacer que la base de datos genere un fragmento tiene varios beneficios:

1. Conveniencia: No es necesario que implementes la lógica para generar fragmentos. de una búsqueda.
2. Eficiencia: Los fragmentos reducen el tamaño de salida del servidor.

La función SNIPPET crea el fragmento. Muestra la parte relevante del valor de la cadena original junto con las posiciones de los caracteres que se destacarán. El el cliente puede elegir cómo mostrar el fragmento al usuario final (por ejemplo, con texto destacado o en negrita). La función SNIPPET quita todas las etiquetas HTML. de la cadena original.

Por ejemplo, en el siguiente código, se usa SNIPPET para recuperar texto de AlbumTitle:

SELECT AlbumId, SNIPPET(AlbumTitle, "Fast Car")
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, "Fast Car")

¿Qué sigue?

• Obtenga información sobre cómo clasificar los resultados de la búsqueda.
• Obtén información para realizar una búsqueda de substring.
• Obtén información sobre cómo paginar los resultados de la búsqueda.
• Obtén información para combinar consultas de texto completo y no de texto.
• Obtén más información para buscar en varias columnas.