Discussion :

[xla99]

Bonjour,

Je dois faire des requêtes sur des données tabulaires avec des tables de plusieurs centaines de milliers d’enregistrements et je voudrais importer toute cette information en mémoire pour accélérer le traitement.

J’ai donc une table SQL que je veux importer dans une BD SQLite avec SQLAlchemy mais toutes les méthodes que j’ai trouvées pour copier une table SQL vers SQLite utilisent des curseurs et cela prend 4 minutes pour importer l’information.

Existerait-il un moyen plus rapide pour copier ma table source en mémoire sans avoir à la parcourir au complet avec un curseur ?

Merci.

[wiztricks]

Salut,

"Existerait-il un moyen plus rapide ?"
On peut toujours faire plus rapide.

Déjà vous pourriez travailler plus près du driver SQL. SQLAlchemy le permet.
Mais avant de vous lancer la dedans, vous pourriez "tester" avec des requêtes SQL et le module sqlite3

Une table pouvant se "dumper" sous la forme d'un fichier CSV, vous pourriez tester le chargement des informations à partir d'un fichier .txt.

Quelque part le fichier .CSV donnera une indication sur le temps que vous pouvez espérer sans trop d'efforts: si vous voulez mieux il va falloir "bosser" plus ou trouver une solution matérielle.

Avant d'explorer ces pistes, il faut se poser des questions basiques: charger beaucoup d'informations en mémoire consommera de la mémoire physique. Si elle est insuffisante, çà va faire des accès disque et être "long".

Bon courage
- W

[tyrtamos]

Bonjour,

Je n'en connais pas assez sur le contexte et je ne connais pas SQLAlchemy, mais mon expérience de ce genre de problème, c'est que pour diminuer la durée de ce genre de copie:

- il faut éviter de faire des "COMMIT" tout le temps. SQLITE fonctionne par défaut avec les transactions, mais dans la mesure où les données ont déjà été validées par rapport aux contraintes par leur présence dans la 1ère table, un seul COMMIT à la fin devrait suffire. On pourrait aussi désactiver (ou plutôt ne pas activer) les contrôles d'intégrité avec l'instruction PRAGMA (sous les mêmes conditions que précédemment!).

- les écritures en mémoire sont beaucoup plus rapide, et les mémoires des PC modernes deviennent confortables (souvent plus de 6Go). Il faudrait donc avoir au moins la base destination en RAM, et la recopier sur disque à la fin. Avec Python, il y a 2 moyens auxquels on pense mais qui ne marchent pas, c'est cStringIO de Python (car il faut un nom de fichier pour ouvrir la base) et l'ouverture d'une base SQLITE3 avec ":memory:" (car il est impossible de récupérer le fichier à la fin pour le copier sur disque). Reste le RAMDISK! On en trouve facilement sur le web, et même des gratuits.

Si les 2 bases de données étaient des bases SQLITE3, on pourrait passer de l'une à l'autre avec les scripts SQL fabriqués par iterdump: voilà une fonctionnalité étonnante que j'utilise souvent: la base de données complète est convertie en script SQL, y compris les instructions de création de tables, les contraintes, les requêtes INSERT, les TRIGGER s'il y en a, etc... Avec un "BEGIN TRANSACTION;" au début et un seul "COMMIT;" à la fin! C'est drôlement pratique. En modifiant directement le script, on peut même provoquer des modifications de structure de la base que la syntaxe de SQLITE3 ne permet pas! J'ai un tuto ici: http://python.jpvweb.com/mesrecettes...rde_script_sql. Je ne sais pas si ça existe dans les autres drivers de SGBDR Python.

[wiztricks]

Salut tyrtamos

(car il est impossible de récupérer le fichier à la fin pour le copier sur disque)

Yes we can: Loading and Saving In-Memory Databases

Pour le reste la prose du PO n'est pas très claire.
J'en ai compris qu'il chargeait une table dans une base de donnée Sqlite3 en mémoire et gérée par SQLAlchemy.
Les IO disques étant 100 a 1000 fois moins rapides que les accès mémoire, c'est plutôt côté "lecture" que çà devrait pêcher. Sinon c'est qu'il n'y a pas assez de mémoire physique.
Après il faut se poser des questions côté conception mais pas la peine de se prendre la tête avant un retour du PO pour qu'il clarifie un peu ce qu'il veut.

- W

[tyrtamos]

Bonjour wiztricks,

Yes we can: Loading and Saving In-Memory Databases

Merci pour la remarque et pour le lien. J'avais déjà lu cette partie, mais j'avais abandonné parce que ces fonctions font partie de la bibliothèque écrite en C et ne sont pas rendu disponibles pour Python par son module sqlite3 (c'est bien dommage!).

En cherchant un peu, j'ai trouvé plusieurs solutions possibles:

- installer le module sqlitebck (https://pypi.python.org/pypi/sqlitebck/1.2.1). Il est écrit en C (et sera donc compilé pendant l'installation). Un exemple d'utilisation montre qu'on peut effectivement recopier sur disque une base de données crée en mémoire (":memory:")

- essayer d'utiliser les fonctions de la bibliothèque sqlite3 (sous Windows: C:\Python27\DLLs\sqlite3.dll) avec le module ctypes comme le propose le code ici: https://gist.github.com/achimnol/3021995. Mais je ne sais pas si ça marche quand on veut sauvegarder une base de données située en mémoire.

- essayer d'utiliser APSW ("Another Python SQLite Wrapper") qui est un module Python concurrent de sqlite3 et qui semble disposer d'une fonction backup. Mais je ne sais pas si ça marche quand on veut sauvegarder une base de données située en mémoire.

A mon avis, si on est pressé et dans le cadre d'une opération "one shot", la solution RAMDISK est plus simple. Mais pour des opérations répétitives à intégrer dans un programme, l'une des 3 solutions précédentes peut être intéressante.