Las aplicaciones web suelen paginar los datos tal como se presentan a los usuarios. El usuario final recibe una página de resultados y, cuando navega a la siguiente, se recupera y presenta el siguiente lote de resultados. En esta página, se describe cómo agregar paginación a los resultados de búsqueda cuando se realiza una búsqueda en el texto completo en Spanner.
Descripción general
Existen dos formas de implementar consultas paginadas en Spanner: paginación basada en claves (recomendado) y paginación basada en desplazamiento.
La paginación basada en claves es un método para recuperar resultados de la búsqueda en formato más pequeño y manejables, a la vez que garantizas resultados coherentes en todas las solicitudes. Un identificador (la "clave") del último resultado de una página se utiliza como referencia para recuperar el siguiente conjunto de resultados.
En general, Spanner recomienda usar la paginación basada en claves. Mientras que la paginación basada en desplazamiento es más fácil de implementar, tiene dos valores significativos drawbacks:
- Costo de consulta más alto:La paginación basada en desplazamiento recupera y recupera repetidamente descarta los mismos resultados, lo que lleva a un aumento de los costos y una disminución rendimiento.
- Resultados incoherentes: En las consultas paginadas, por lo general, se ve cada página se recuperan en una marca de tiempo de lectura diferente. Por ejemplo, la primera página podría provienen de una consulta a la 1:00 p.m. y la siguiente de una consulta a la 1:10 p.m. Esto significa que los resultados de la búsqueda pueden cambiar entre las consultas, lo que genera resultados inconsistentes en las páginas.
La paginación basada en claves, por otro lado, usa un identificador único (clave) del último resultado de una página para recuperar el siguiente conjunto de resultados. Esto garantiza que tanto una recuperación eficiente y resultados coherentes, incluso si cambian los datos subyacentes.
Para que los resultados de la página sean estables, la aplicación podría emitir todas las consultas
de diferentes páginas en la misma marca de tiempo. Sin embargo, esto podría fallar si
consulta excede la retención de la versión
período
(el valor predeterminado es 1 hora). Por ejemplo, este error ocurre si version_gc
es
Una hora, el usuario final recuperó los primeros resultados a la 1 p.m. y, luego, hizo clic en Siguiente.
a las 3 p.m.
Usa la paginación basada en claves
La paginación basada en claves recuerda el último elemento de la página anterior y lo usa como
un punto de partida para la consulta de la siguiente página. Para lograrlo, la consulta debe mostrar
las columnas especificadas en la cláusula ORDER BY
y limita la cantidad de filas
usando LIMIT
.
Para que la paginación basada en claves funcione, la consulta debe ordenar los resultados de forma el pedido total. La forma más fácil de obtener una es elegir cualquier total orden y, luego, agrega un desempate columnas, si es necesario. En la mayoría de los casos, el orden total es el orden del índice de búsqueda. y la combinación única de columnas es la clave primaria de la tabla base.
Con nuestro esquema de muestra de Albums
, para la primera página, la consulta se ve de la siguiente manera:
SELECT AlbumId, ReleaseTimestamp
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, "green")
ORDER BY ReleaseTimestamp DESC, AlbumId
LIMIT @page_size;
El AlbumId
es el desempate, ya que ReleaseTimestamp
no es una clave. Hay
puede ser dos álbumes diferentes con el mismo valor para ReleaseTimestamp
.
Para reanudar, la aplicación vuelve a ejecutar la misma consulta, pero con una cláusula WHERE
.
que restringe los resultados de la página anterior. La condición adicional
debe tener en cuenta la dirección clave (ascendente o descendente), los desempates,
y el orden de los valores NULL para las columnas anulables.
En nuestro ejemplo, AlbumId
es la única columna clave (en orden ascendente) y no puede ser NULL, por lo que la condición es la siguiente:
SELECT AlbumId, ReleaseTimestamp
FROM Albums
WHERE (ReleaseTimestamp < @last_page_release_timestamp
OR (ReleaseTimestamp = @last_page_release_timestamp
AND AlbumId > @last_page_album_id))
AND SEARCH(AlbumTitle_Tokens, @p)
ORDER BY ReleaseTimestamp DESC, AlbumId ASC
LIMIT @page_size;
Spanner interpreta este tipo de condición como seekable. Esto significa que Spanner no lee el índice de los documentos que estás filtrando y sale de ella. Esta optimización es lo que hace que la paginación basada en claves sea mucho más eficiente que la paginación basada en offsets.
Usa la paginación basada en desplazamientos
La paginación basada en desplazamientos aprovecha las cláusulas LIMIT
y OFFSET
de las consulta en SQL
para simular páginas. El valor LIMIT
indica la cantidad de resultados por página.
El valor OFFSET
se establece en cero para la primera página, en el tamaño de la página para la segunda página y en el doble del tamaño de la página para la tercera página.
Por ejemplo, la siguiente consulta recupera la tercera página, con un tamaño de página de 50:
SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, "green")
ORDER BY ReleaseTimestamp DESC, AlbumId
LIMIT 50 OFFSET 100;
Notas de uso:
- Se recomienda usar la cláusula
ORDER BY
para garantizar un orden coherente. entre páginas. - En las consultas de producción, usa parámetros de consulta en lugar de constantes para especificar
LIMIT
yOFFSET
para que el almacenamiento en caché de las consultas sea más eficiente. Para obtener más información, consulta Parámetros de consulta.
¿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 más información sobre cómo combinar consultas de texto completo y no de texto.
- Obtén más información para buscar en varias columnas.