Ho bisogno di aiuto! Non riesco a risolvere il problema, sto incontrando delle limitazioni hardware - pagina 6
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
>>> Non so cosa sto cercando ...
>>> Devi passare attraverso tutte le sequenzeripetutamente e fare alcuni calcoli.
Beh - sì - ricerca - ma cerca attraverso 20 giga...
In linea di principio, la ricerca si basa sul fatto che c'è qualche ricerca e confronto
Mi baso su quello che ha scritto l'autore.Forse i dati non possono essere rimpiccioliti - compressi - indicizzati
è logico mettere i dati in SQL
passare la logica di business al server + dati
l'Expert Advisor invierà solo dati brevi al server per l'enumerazione e il calcolo
e ricevere una risposta pronta.
Oh e sono colpito da molte cose qui intorno.
Mi sembra che anche un bambino dovrebbe essere in grado di capirlo. Se un testo è compresso con un algoritmo, sarà esattamente lo stesso oggi e domani.
a proposito - 3 terabyte sono stati copiati da server a server per ore - rete di 1gb
se compresso in ZIP, 3 terabyte sono stati compressi per più di un giorno
Quando hai comprato la grande utility LiteSpeed che prima comprime nella memoria del server e poi fa il backup
3 terabyte di tempo di compressione sono stati ridotti a poche ore
Anche lo spacchettamento (per cambiare o cancellare qualcosa) richiede diverse ore.
Risolvere l'algoritmo di ricerca dei dati compressi è forte!
forse in futuro qualcuno inventerà degli algoritmi per cercare l'inserimento e la cancellazione in database già compressi
... ma non ci sono ancora tali algoritmi in scala industriale
Ci sono database industriali di ORACL MS SQL nessuno al mondo memorizza i dati in forma compressa - se vengono lavorati intensamente
1. A proposito, 3 terabyte sono stati copiati da server a server per diverse ore - 1gb di rete
se compresso in ZIP, 3 terabyte sono stati compressi per più di un giorno
Ho comprato una bella utility chiamata LiteSpeed che prima comprime la memoria del server e poi fa il backup
3 terabyte di tempo di compressione sono stati ridotti a poche ore
Anche lo spacchettamento (per cambiare o ripristinare, cancellare) richiede qualche ora.
2. Risolvere l'algoritmo di ricerca nei dati compressi è forte!
3. forse in futuro qualcuno inventerà degli algoritmi per cercare l'inserimento e la cancellazione in database già compressi
4. ... ma non ci sono ancora tali algoritmi in scala industriale
Ci sono database industriali ORACL MS SQL nessuno al mondo memorizza dati in forma compressa - se si lavora con loro intensamente
1. Per il compito in questione, la compressione dei dati viene eseguita solo una volta e può richiedere una settimana per comprimere i dati.
2) Cosa c'è di così bello?
3) Perché dovremmo inventare qualcosa? La domanda è: ne avete bisogno o no?
4. E se non lo fosse?
1. Per il compito in questione, la compressione dei dati è fatta una volta, si può fare per una settimana.
2. Cosa c'è di così bello?
3. Cosa c'è da inventare? La domanda è: è necessario o no?
4. E se non lo fosse?
1) p1 solo dopo aver risolto p4
2) bene - non so forse la domanda(FAST) ricerca in grandi insiemi di dati è già stato pensato attraverso abbastanza professionisti qualificati e più di una volta - e finora nessun algoritmo
3) Dio sa - la ricerca nei dati compressi può essere inventata, ma non è risolta e molto probabilmente perché non è necessaria...
4) forse - i migliori cervelli del mondo inventeranno un algoritmo(FAST) di ricerca nei dati compressi
cercare (LENTAMENTE) in dati compressi è possibile - con una metodologia (decomprimere e poi cercare) non è una questione...
Nessuno parla di ricerca nei dati compressi. Stiamo parlando di confrontare due sequenze compresse.
Supponiamo un array, "aaa", "bbb", "vvvv". Ognuno dei tre elementi dell'array è compresso da solo indipendentemente dal resto. Supponiamo di comprimere e ottenere l'array "a", "b", "c".
Abbiamo la stringa ricercata "bbb" che dobbiamo trovare nell'array. Prima della ricerca, lo comprimiamo e otteniamo "b". Ora cerca e trova.
Nessuno parla di ricerca nei dati compressi. Stiamo parlando di confrontare due sequenze compresse.
Supponiamo un array, "aaa", "bbb", "vvvv". Ognuno dei tre elementi della matrice è compresso indipendentemente dal resto. Supponiamo di comprimere e ottenere l'array "a", "b", "c".
Abbiamo la stringa desiderata "bbb" che dobbiamo trovare nell'array. Prima della ricerca, lo comprimiamo e otteniamo "b". Ora lo cerchiamo e lo troviamo.
l'idea è chiara...
eppure questa metodologia (con una rapida ricerca) è assente nei database industriali
ci deve essere una ragione
Oh e sono colpito da molte cose qui intorno.
Mi sembra che anche un bambino dovrebbe essere in grado di capirlo. Se si comprime un testo con un algoritmo, sarà esattamente lo stesso in forma compressa oggi e anche domani.
Stai dicendo che usando lo stesso algoritmo di compressione e comprimendo due testi diversi puoi ottenere due sequenze di dati completamente identiche?
Cosa le fa pensare che stia dicendo questo?
l'idea è chiara...
eppure questa metodologia (con una rapida ricerca) non è disponibile su basi industriali
ci deve essere una ragione.
Naturalmente ci sono delle ragioni :)
La compressione dei dati riguarda l'eliminazione della ridondanza. E più efficiente è la compressione, minore è la ridondanza. E la ricerca proposta sopra non funzionerà, perché nel testo compresso, qualsiasi parte dipenderà dall'intero testo.
Naturalmente, ci sono delle ragioni :)
La compressione dei dati riguarda l'eliminazione della ridondanza. E più efficiente è la compressione, meno ridondanza c'è. E non si può cercare con il metodo di cui sopra, perché in un testo compresso qualsiasi parte dipenderà dall'intero testo.
Cosa le fa pensare che stia dicendo questo?
Stai facendo una specie di allusione:
Bene, vi darà 4-8 volte la compressione come per il testo. Considerate il fatto che gli algoritmi di compressione creano i propri alberi di transcodifica per ogni file.
In altre parole, il file sorgente avrà un albero, ma la porzione di dati che volete trovare avrà un albero diverso..
Mi sto solo chiedendo come proponi di cercare? anche teoricamente ))))
Come cercare, l'ho scritto prima.