¿Cuáles son las mejores prácticas para almacenar en caché los resultados paginados cuyo orden / propiedades pueden cambiar?

¿Cuál es la mejor práctica para almacenar en caché los resultados de búsqueda paginados cuyo orden / propiedades se pueden cambiar?

Digamos, en mi solicitud, alguien quiere ver los últimos 20 hilos de discusión (de 10,000). Se enviaría una solicitud a la base de datos, a través de servlet, para obtener los primeros 20 registros de la tabla de hilos de discusión como XML / JSON. Si luego quieren ver los próximos 20, van a la siguiente página de resultados y esto dispara otra solicitud para obtener el siguiente lote (límite y compensación = 20, etc.).

Para reducir la carga del servidor y la espera del cliente, me gustaría almacenar en caché las páginas de resultados anteriores. Sin embargo, tengo dos preguntas:

1. La tabla en la que se muestran los resultados se puede ordenar por más de un atributo (es decir, fecha de creación de subprocesos, autor de subprocesos, última fecha posterior). Esto significa que una declaración como 'primeros 20 resultados' no tiene sentido sin contexto (es decir, por qué estamos ordenando). ¿Cómo comunica el front-end, entonces, al back-end lo que ya ha cargado? Lo primero que pensé fue usar ID para cada resultado, pero enviarlos de vuelta al servidor en solicitudes posteriores (y filtrar los resultados basados ​​en ellos) sería tan lento como enviar todo a ciegas. ¿Cómo puedo hacer esto?
2. ¿Qué sucede si un atributo de un resultado devuelto anteriormente (es decir, la fecha posterior más reciente) ha cambiado? Luego necesitamos una forma de verificar cada resultado para ver si se ha modificado del lado del servidor desde que se paginó. ¿Cómo puedo hacer esto?

Parece que lo que necesita es un contenedor para todos los parámetros que definen una página (por ejemplo, pageNumber, pageSize, sortType, totalCount, etc.) y utilizar este DataRequestobjeto como la clave para su mecanismo de almacenamiento en caché. Desde este punto, tiene una serie de opciones para manejar el caché:

• Implemente algún tipo de mecanismo de tiempo de espera para actualizar la memoria caché (en función de la frecuencia con la que cambian los datos).
• Tenga un agente de escucha que verifique los cambios en la base de datos y actualice la memoria caché según los parámetros anteriores.
• Si los cambios se realizan por el mismo proceso, siempre puede marcar el caché como obsoleto con cada cambio y marcar este indicador cuando se solicita una página.

Los dos primeros pueden involucrar un mecanismo de planificador para disparar en algún intervalo o basado en un evento. El último podría ser el más simple si tiene un único punto de acceso a datos.

Por último, como mencionó @DanPichelman, puede convertirse rápidamente en un algoritmo demasiado complicado que supera los beneficios, así que asegúrese de que la ganancia en el rendimiento justifique la complejidad del algoritmo.

Probablemente lo manejaría así:

1. Trate diferentes ordenamientos como diferentes secuencias todas juntas. No valdrá la pena la contabilidad adicional para rastrear lo que cada cliente tiene (o enviarlo una y otra vez).
2. Cada vez que las páginas del usuario, se muestran inmediatamente desde la memoria caché y al mismo tiempo se envía un GET al servidor que incluye un hash o un último tiempo de acceso. El servidor solo envía una página completa si algo ha cambiado.
3. Recupere del servidor más de una página de IU a la vez. Por ejemplo, si su interfaz de usuario muestra 20 entradas, consulte 60. Necesito probar esta, pero mi expectativa es que el tamaño de retorno más eficiente generalmente será mayor que la cantidad promedio de datos que se muestra en una página. Esto también hace que la interfaz de usuario sea muy receptiva para algunos giros de página.
4. La captación previa se resuelve cuando se está acercando a un límite. Esto ayuda a preservar esos tiempos de carga rápidos de la memoria caché.

Solo una idea: en su llamada al servidor, pase los parámetros habituales más una matriz de hash MD5 que representan las páginas de datos vistas en caché actualmente vistas anteriormente.

La llamada de retorno contendría todos los datos habituales para la nueva página actual, más actualizaciones para las páginas desactualizadas vistas anteriormente. Puede usar el viejo hash como clave.

Primero recomendaría muchas pruebas de rendimiento y sincronización: su código del lado del cliente será mucho más complicado de lo que sería si simplemente accediera al servidor para cada página de datos. Asegúrese de que la complejidad adicional resulte en una mejora significativa.