Import de masse¶
Contexte¶
Dans le cadre de la migration du public, de nouveaux gros clients ont besoin de pouvoir importer l'historique de leurs données. Cela concerne des millions de documents et des To de binaires.
Nous évaluons la cible à 14 millions de documents pour 7To de données.
Le gros point de blocage est le temps d'upload des binaires de nos API actuelles limitée par le réseau. Une des solutions envisagées est que les clients nous fournissent leurs binaires et que nous lancions un script effectué par notre équipe afin d'importer de façon la plus optimisée l'ensemble des données.
Afin de savoir si cette solution nous permet de vraiment gagner du temps, on crée un script d'import très simplifié pour évaluer ce temps. (https://github.com/Efalia/mgx/pull/2703)
Cet ADR détaille la durée d'exécution de chaque étape de l'import.
Description¶
Les points suivants vont être évalués par le script :
- le calcul de l'empreinte du fichier
- l'insertion dans la base de donnée
- le stockage des fichiers
- l'indexation des documents
Le script crée une armoire avec un gabarit de document et une métadonnée de type texte puis insert n documents dans ce dernier.
Le calcul de l'empreinte du fichier¶
2 solutions ont été évaluées.
Utilisé par notre implémentation de nos API.
| 100Mo | 1Mo | 500Ko | |
|---|---|---|---|
| 100 documents | 54s | ||
| 500 documents | 4m 7s | 3s | |
| 10k documents | 1m 8s | 37s |
Note
On ne relève pas le temps sur 100 documents avec un fichier de 1Mo car c'est trop rapide pour être significatif.
| 100Mo | 1Mo | 500Ko | |
|---|---|---|---|
| 100 documents | 45s | ||
| 500 documents | 3m 31s | 5s | |
| 10k documents | 1m 59s | 1m 21s |
L'insertion dans la base de donnée¶
| 100 documents | 0s | | 500 documents | 2s | | 10k documents | 47s |
Le stockage des fichiers¶
| 100Mo | 1Mo | 500Ko | |
|---|---|---|---|
| 100 documents | 1m 7s | ||
| 500 documents | 5m 36s | 9s | |
| 10k documents | 3m 10s | 1m 57s |
Note
Nous avons testé l'utilisation de la fonction rename de PHP plutôt que Innmind car Filesystem nécessite de lire et d'écrire chaque fichier sur le disque alors que le rename ne fait que changer une adresse mémoire.
Cepandant, le rename n'a pas d'impact car il s'agit de déplacer un fichier qui est présent sur un disque réseau.
Le simple changement d'adresse n'est donc pas possible et la commande fait la même chose que notre code actuel avec la même rapidité.
Cette approche a donc été abandonnée.
L'indexation des documents¶
| 100 documents | 31s | | 10k documents | 10m 24s |
Note
Ces temps sont issus d'appels d'unitaires pour chaque document.
Script complet (sans l'indexation)¶
| 1Mo | 500Ko | |
|---|---|---|
| 10k documents | 5m 16s | 4m 1s |
| 100k documents | 42m 30s |
Conclusion¶
Avec des fichiers de 1Mo en moyenne, on peut extrapoler 1 million de documents en 500 minutes soit environ 8h30. Pour 14 millions, on aurait environ 5 jours.
Ensuite pour l'indexation on peut extrapoler 1 million de documents en 1040 minutes soit environ 17 heures. Pour 14 millions, on aurait environ 10 jours.
Note
Il s'agit de valeurs issues d'un script synchrone. Il devrait être possible de réduire ce temps en parallélisant.