À propos du comportement de yield_per de SqlAlchemy
Méthode SqlAlchemy yield_per
Est-ce find_in_batches dans Rails? C'est une méthode intéressante qui traite une grande quantité de données de manière séquentielle sans stocker tous les résultats en mémoire.
Si vous pensez que c'est une méthode qui gère bien les limites et les décalages, c'est une méthode qui traite le résultat sélectionné comme un flux sans une telle chose.
En regardant le journal SQL, j'ai pensé qu'il y aurait d'autres personnes que moi qui craignaient que SQL ne sorte pas comme prévu, je vais donc en prendre note.
Comment utiliser le mémo au cas où
yield_per.sample.py
sess = Session(engine)
for obj in sess.query(Customer).filter_by(ownd_uid = n).yield_per(10):
hogehoge(obj)
Si vous l'écrivez comme ceci, même s'il y a beaucoup d'enregistrements sélectionnés sous la condition de filtre, il sera traité en sélectionnant 10 enregistrements à la fois, de sorte que tous les résultats sélectionnés seront traités séquentiellement sans être stockés dans la mémoire.
C'est le meilleur.
Oh? Utilisez-vous N connexions?
Si vous essayez de show processlist sur MySQL, il semble que chaque connexion appelée par yield_per ait une connexion. Est-ce le cas si vous demandez?
La première boucle qui prend 945 secondes est la boucle supérieure, mais je me demande si elle peut être interrompue par connect_timeout .... (J'ai l'impression que ça va s'épuiser)
Si vous n'utilisez pas une telle quantité de données, vous ne pourrez peut-être pas les voir, donc si vous obtenez une erreur, notez comment l'utiliser.
Résultat: aucune erreur de connexion.
Cela a pris 1 à 2 heures, mais cela s'est terminé sans aucun problème.
Peut-être que si vous gardez une longue connexion, vous ne pourrez pas interroger la liste des processus d'affichage? !!
Par tous les moyens, veuillez étudier le comportement du type de traitement effectué du côté MySQL!
Recommended Posts