Optimizing data upload transfer size
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
- Type d'issue
- Fonctionnalité
- Clarté
- À clarifier
- Activité
- À l'abandon
- Stack technique
- python
- Domaine
- data, performance
Piste de recherche
Commencez par le chemin upload_frame qui convertit les données en CSV avant de les envoyer à CAS. Déterminez si le transfert binaire ou compressé est pris en charge, puis mesurez les envois de grandes tables contenant uniquement des valeurs numériques ; le travail est considéré comme terminé lorsqu’une approche documentée ou implémentée réduit la taille du transfert sans perturber le comportement de l’envoi.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Hi, in my project I usually upload from local very large tables with the following characteristic: all columns are numeric (double).
I saw that with upload_frame data is first converted to csv and then the csv is uploaded on CAS.
I was thinking about the fact that in the "plain" csv every character takes 1 byte, so for instance the number 123456.123456 uses 13 bytes: but if this number is converted to its float binary representation, it would take 8 bytes: this little "gain" of 5 bytes, repeated for every row and every column may lead to a huge gain in file transfer size for bandwidth and time.
Or perhaps the "plain" csv may be gzipped to greatly reduce the file size since inside there are only a few distinct characters (i.e. the numbers).
Any Idea/hint you can give me to optimize the data upload transfer size in a smart way?
Thank you.
- Langage dominant
- Python
- Étoiles
- 159
- Forks
- 66
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de sassoftware/python-swat
-
Difficulté 4/5 3-5 jours Accessibilité débutants 30/100
sassoftware/python-swat#191 · 1 commentaire ·
-
Error uploading parquet filesOuverte
Difficulté 3/5 1-2 jours Accessibilité débutants 35/100
sassoftware/python-swat#183 · 1 commentaire ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
sassoftware/python-swat#180 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 35/100
sassoftware/python-swat#178 ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
sassoftware/python-swat#177 · 1 commentaire ·
Toutes les issues de sassoftware/python-swat
Issues similaires
-
documentation good first issue
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
MarketSquare/robotframework-browser#5479 ·
Les mainteneurs répondent en général sous 1 jour
-
Visual COBOL: missing 11.0 and 12.0, and 9.0 date differs from Rocket Software's lifecycle pageOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
endoflife-date/endoflife.date#11561 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
OCA/l10n-brazil#5602 ·
Les mainteneurs répondent en général sous 1 jour
-
documentation review-2.0.0
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
dkuenzel/meshcore-home-gateway#106 ·
Les mainteneurs répondent en général sous 1 jour