Durée de vie de la connexion SQL

Question

Je travaille sur une API pour interroger un serveur de base de données (Oracle dans mon cas) pour récupérer une quantité massive de données. (C'est en fait une couche au-dessus de JDBC.)

L'API que j'ai créée essaye de limiter autant que possible le chargement de chaque information demandée en mémoire. Je veux dire que je préfère parcourir le jeu de résultats et traiter la ligne retournée un par un au lieu de charger toutes les lignes en mémoire et les traiter plus tard.

Mais je me demande si cela est la meilleure pratique car il a des problèmes:

• Le jeu de résultats est maintenu pendant le traitement entier, si le traitement est aussi longue que la récupération des données, cela signifie que Mon jeu de résultats sera ouvert deux fois plus longtemps
• Faire une autre requête à l'intérieur de ma boucle de traitement signifie ouvrir un autre jeu de résultats alors que j'en utilise déjà un, ce n'est pas une bonne idée de commencer à ouvrir trop de jeux de résultats simultanément.

De l'autre côté, il a quelques avantages:

• Je n'ai jamais plus d'une ligne de données en mémoire pour un jeu de résultats, étant donné que mes requêtes ont tendance à revenir autour de 100k lignes, il peut en vaut la peine.
• Comme mon framework est fortement basé sur des concepts de programmation fonctionnelle, je ne compte jamais sur plusieurs lignes en mémoire en même temps.
• Le démarrage du traitement sur les premières lignes renvoyées alors que le moteur de base de données renvoie encore d'autres lignes améliore considérablement les performances.

En réponse à Gandalf, ajouter quelques informations supplémentaires:

• je devrai toujours traiter l'ensemble des résultats mis
• Je ne suis pas en train de faire une agrégation de lignes

Je m'intègre à une application de gestion de données de base et récupère des données afin de les valider ou de les exporter en utilisant différents formats (à l'ERP, à la plateforme web, etc.)

Answer 1

Il n'y a pas de réponse universelle. J'ai personnellement mis en œuvre les deux solutions des dizaines de fois.

Cela dépend de ce qui compte le plus pour vous: la mémoire ou le trafic réseau.

Si vous disposez d'une connexion réseau rapide (LAN) et d'un ordinateur client médiocre, extrayez les données ligne par ligne du serveur.

Si vous travaillez sur le Internet, la récupération par lots vous aidera.

Vous pouvez définir le nombre de prélectures ou les propriétés de la couche de base de données et trouver une moyenne dorée.

Règle de base est: chercher tout ce que vous pouvez garder sans vous en apercevoir

si vous avez besoin une analyse plus détaillée, il y a six facteurs impliqués:

• génération Ligne responce temps/taux (prochainement Oracle génère la première ligne/dernière rangée)
• Délai de réponse de la ligne/taux de livraison (à quelle fréquence pouvez-vous obtenir f IRST ligne/dernière rangée)
• temps de réponse de traitement de ligne/taux (comment pouvez-vous montrer bientôt la première ligne/dernière rangée)

L'un d'eux sera le goulot d'étranglement. En général, rate et responce time sont des antagonistes.

Avec préchargement, vous pouvez contrôler le débit de temps et rangée réponse de livraison ligne : le nombre plus élevé de prélecture va augmenter le taux, mais diminuer le temps de réponse, le nombre inférieur de prélecture fera le contraire.

Choisissez lequel est le plus important pour vous.

Vous pouvez également effectuer les opérations suivantes: créer des unités d'exécution séparées pour la récupération et le traitement.

Sélectionnez juste le nombre de lignes pour garder l'utilisateur amusé en mode de prélecture faible (avec un temps de réponse élevé), puis passez en mode de prélecture haute.

Il va chercher les lignes en arrière-plan et vous pouvez les traiter en arrière-plan aussi, tandis que l'utilisateur parcourt les premières lignes.