Optimizing data upload transfer size
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- python
- Ambito
- data, performance
Direzione di ricerca
Inizia con il percorso upload_frame che converte i dati in CSV prima di caricarli in CAS. Verifica se è supportato il trasferimento binario o compresso, quindi misura i caricamenti di tabelle grandi contenenti esclusivamente valori numerici; il lavoro è completo quando è disponibile un approccio documentato o implementato che riduce le dimensioni del trasferimento senza alterare il comportamento del caricamento.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Python
- Stelle
- 159
- Fork
- 66
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di sassoftware/python-swat
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
sassoftware/python-swat#191 · 1 commento ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
sassoftware/python-swat#183 · 1 commento ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
sassoftware/python-swat#180 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 35/100
sassoftware/python-swat#178 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
sassoftware/python-swat#177 · 1 commento ·
Tutte le issue di sassoftware/python-swat
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
SpikeInterface/spikeinterface#4924 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
aws-samples/sample-per-model-bedrock#782 ·
I maintainer di solito rispondono entro 1 giorno
-
bug javascript
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
No-op PreToolUse:Bash hook (bash_hook.py) still registered synchronously; adds latency and can time out at 10 sForse già presa @alexgr-agent l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
alexgreensh/token-optimizer#313 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100