Pagination avec mise en cache progressive

C'est quoi Cache ? La mise en cache est la technique de stockage des copies des données d'application fréquemment utilisées dans une couche de mémoire plus petite et plus rapide pour améliorer les temps de récupération des données, le débit.

Qu'est-ce que la pagination ? La pagination est le processus de séparation des données en ensembles, tout comme les pages d'un livre. Une demande d'API GET pour demander des informations à un serveur via un point de terminaison d'API vers de grandes bases de données pourrait produire des millions, voire des milliards, de résultats. La réponse de l'API nous envoyant des milliers d'entrées à la fois est une perte de ressources. La pagination permet de faire évoluer notre application, de servir plus d'utilisateurs, d'effectuer des requêtes efficaces et de créer une bonne expérience client.

Considérons un scénario : On vous confie une tâche pour développer un service. Cela aura des points de terminaison servant des enregistrements à partir de différentes tables de base de données. Pour l'instant, considérons que vous commencez avec un point de terminaison qui sert à partir de la table products de votre base de données. L'API prend en charge certains paramètres de filtre. Disons PriceRange, Manufacturer, etc. Considérant qu'il y a plus de 5 millions de produits dans votre base de données. Et vos fournisseurs continuent d'ajouter plus de produits à la base de données.

Réflexions initiales : On peut penser à créer une requête de base de données sur la ressource API et le paramètre de filtre et à l'exécuter en mode pushdown dans la base de données, lire tous les enregistrements filtrés, les stocker dans un cache et servir des réponses paginées à partir du cache pour les requêtes ultérieures.

Imaginez si le résultat de la requête renvoyait 2 millions d'enregistrements. Mettez-vous en cache (2 millions — pageSize) d'enregistrements ? De plus, le temps de réponse de la première demande sera énorme. Comme vous chargez les 2 millions d'enregistrements à la fois, quelle que soit la taille de la page. Et quand invalider le cache. Il stocke déjà une grande quantité de données.

Mon approche utilisant la mise en cache progressive

Bob va acheter du pain Naan au restaurant le plus proche. Il observe qu'il y a deux personnes près d'un four. L'un d'eux façonne le sol en pain naan. Un autre sur demande met ces pains façonnés dans le four et sert la commande. Il l'observe la personne sur le four attend quelques secondes en cas de tout autre ordre et se penche en arrière sinon.

Vous avez ce droit? Travaillez à la demande, faites une pause un moment, disposez autrement. C'est exactement comme ça que j'ai résolu ce problème. Maintenant, mappons cela dans notre scénario.

Cache progressif :

Notre clé de cache est GUID. Cela sera utilisé ici comme paramètre de curseur pour notre pagination. La valeur est le lecteur en pause. Nous pouvons implémenter un cache en utilisant le cache LRU. En outre, une minuterie supplémentaire qui s'active toutes les 8 secondes (peut être configurée par l'utilisateur) élimine le lecteur le moins récemment utilisé. Nous ne gardons donc pas les connexions à la base de données ouvertes très longtemps.

public interface ICache
{
  void Add(Guid Key,IReader reader);
  IReader Get(Guid Key);
  void DisposeUnwanted();
}

Première demande

Example request: https://localhost:9261/Products?Price=100&Manufacturer=HP

//Converted Query for our example request.
SELECT * FROM products WHERE Price = 100 AND Manufacturer Like 'HP'

Étape 3 : Mettez le lecteur en pause, générez le GUID et mettez-le en cache.

Étape 4 : Ajoutez le GUID généré comme curseur pour la page suivante dans le corps de votre réponse JSON.

Demandes ultérieures

Example request: https://localhost:9261/Products?Price=100&Manufacturer=HP&Cursor=GUID

Étape 2 : Reprenez le lecteur et lisez l'enregistrement jusqu'à ce que votre limite compte.

Étape 3 & 4 : Identique à la première requête.

Complexité temporelle : O(limite), où la limite est la taille de la page de réponse.

Avantages :

1. Pas de chargement paresseux.
2. Utilisation efficace des ressources.
3. Temps de réponse constant.
4. Pas de requêtes complexes. Ce que vous auriez besoin de comprendre si vous poussiez le paramètre du curseur.

1. Impossible de lire les enregistrements précédents. Mais ce n'est pas possible en utilisant la pagination du curseur par définition.

Oui, la vie est facile, si vous pouvez la coder.

Ce modèle de mise en cache progressive peut s'adapter à d'autres sources de données telles que Fichiers, Documents. (Nous avons besoin d'un processeur d'expression séparé pour la clause where car nous ne pouvons pas pousser vers le bas dans les fichiers). Il s'adapte également efficacement à vos différents schémas de table de base de données sans trop se soucier de sa structure.
Le modèle a parfaitement fonctionné pour moi. J'ai vu des gens coincés dans une situation similaire sur Stack Overflow et utilisant le chargement paresseux ou une implémentation tierce avec une surcharge supplémentaire au lieu d'une solution simple. La démarche partagée est la mienne. Cela peut donc correspondre à votre cas d'utilisation. S'il vous plaît partager vos approches dans les commentaires.

Et si vous avez aimé cet article, appuyez sur le bouton clap ci-dessous . Cela signifie beaucoup pour moi et cela aide les autres à voir l'histoire.

~ Sooraj Kumar
Ingénieur logiciel senior @ Astera Software