Este es un problema sin una solución perfectamente satisfactoria porque está tratando de combinar requisitos esencialmente incompatibles:
-
Envíe solo la cantidad requerida de datos al cliente a pedido, es decir, no puede descargar todo el conjunto de datos y luego paginarlo del lado del cliente.
-
Minimice la cantidad de estado por cliente del que el servidor debe realizar un seguimiento, para la escalabilidad con una gran cantidad de clientes.
-
Mantener un estado diferente para cada cliente
Este es un tipo de situación de "elegir dos". Tienes que comprometerte; acepte que no puede mantener el estado de paginación de cada cliente exactamente correcto, acepte que tiene que descargar un gran conjunto de datos al cliente o acepte que tiene que usar una gran cantidad de recursos del servidor para mantener el estado del cliente.
Hay variaciones dentro de ellos que mezclan los distintos compromisos, pero a eso se reduce todo.
Por ejemplo, algunas personas enviarán al cliente algunas datos adicionales, suficientes para satisfacer la mayoría de los requisitos del cliente. Si el cliente excede eso, entonces se rompe la paginación.
Algunos sistemas almacenan en caché el estado del cliente durante un período corto (con tablas no registradas de corta duración, archivos temporales o lo que sea), pero caducan rápidamente, por lo que si el cliente no solicita constantemente datos nuevos, la paginación se rompe.
Etc.
Véase también:
- ¿Cómo proporcionar a un cliente API 1 000 000 de resultados de la base de datos?
- Uso de "cursores" para la paginación en PostgreSQL
- Itera sobre una gran base de datos postgres externa, manipula filas, escribe la salida en la base de datos postgres de Rails
- optimización de rendimiento de compensación/límite
- Si el recuento (*) de PostgreSQL siempre es lento, ¿cómo paginar consultas complejas?
- Cómo devolver una fila de muestra de la base de datos una por una
Probablemente implementaría una solución híbrida de alguna forma, como:
-
Usando un cursor, lea y envíe inmediatamente la primera parte de los datos al cliente.
-
Inmediatamente obtenga suficientes datos adicionales del cursor para satisfacer el 99% de los requisitos de los clientes. Guárdelo en un caché rápido e inseguro como memcached, Redis, BigMemory, EHCache, lo que sea bajo una clave que me permitirá recuperarlo para solicitudes posteriores del mismo cliente. Luego cierre el cursor para liberar los recursos de la base de datos.
-
Haga caducar la memoria caché en base al uso menos reciente, por lo que si el cliente no sigue leyendo lo suficientemente rápido, tendrá que obtener un nuevo conjunto de datos de la base de datos y la paginación cambiará.
-
Si el cliente quiere más resultados que la gran mayoría de sus pares, la paginación cambiará en algún momento a medida que cambie a leer directamente desde la base de datos en lugar de la caché o genere un nuevo conjunto de datos en caché más grande.
De esa manera, la mayoría de los clientes no notarán problemas de paginación y no tendrá que enviar grandes cantidades de datos a la mayoría de los clientes, pero no derretirá su servidor de base de datos. Sin embargo, necesitas un gran caché boofy para salirte con la tuya. Su práctica depende de si sus clientes pueden hacer frente a la interrupción de la paginación:si simplemente no es aceptable interrumpir la paginación, entonces está obligado a hacerlo en el lado de la base de datos con cursores, tablas temporales, hacer frente a todo el conjunto de resultados en la primera solicitud, etc. También depende del tamaño del conjunto de datos y de la cantidad de datos que normalmente requiere cada cliente.
