Ho bisogno di aiuto! Non riesco a risolvere il problema, sto incontrando delle limitazioni hardware - pagina 7
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
l'idea è chiara...
eppure questa metodologia (con una rapida ricerca) non è disponibile su basi industriali
ci deve essere una ragione
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 lo cerchiamo e lo troviamo.
Siamo chiari, nel tuo caso dovrebbe essere 3a, 3b e 3c in forma compressa, perché stai omettendo il numero di ripetizioni.
Se pensate che un tale algoritmo darà il 70-80% di compressione, vi sbagliate. Anche sul testo in lingua russa (per non parlare dei numeri), questo approccio non farà che gonfiare i dati.
Per esempio, la parola "Esperto" sarà ricodificata come "1E1k1с1п1е1р1t" e non sarà compressa nemmeno un bit, ma sarà gonfiata due volte. Se si omette "1", non ci sarà ancora compressione.
La data e l'ora 2014.08.18 13:45:45 non darà la compressione sulla tua strada.
Per non parlare delle citazioni... Quindi l'efficienza di tale transcodifica è vicina allo 0 in questo caso. Questo è il cosiddetto algoritmo RLE usato nel formato PCX.
1. Siamo chiari, nel tuo caso dovrebbe essere 3a, 3b e 3c in forma compressa, perché stai omettendo il numero di ripetizioni.
Se pensate che un tale algoritmo darà il 70-80% di compressione, vi sbagliate. Anche sul testo in lingua russa (per non parlare dei numeri), questo approccio non farà che gonfiare i dati.
Per esempio, la parola "Esperto" sarà ricodificata come "1E1k1с1п1е1р1t" e non sarà compressa nemmeno un bit, ma sarà gonfiata due volte. Se si omette "1", non ci sarà comunque alcuna compressione.
La data e l'ora 2014.08.18 13:45:45 non darà la compressione sulla tua strada.
Per non parlare delle citazioni... Quindi l'efficienza di tale transcodifica è vicina allo 0 in questo caso. Questo è il cosiddetto algoritmo RLE usato nel formato PCX.
1. Non è un fatto. Forse i dati sono tali che tutto va tre volte, ecco perché è un algoritmo di compressione così semplice.
Il resto... Oh grazie, mi hai aperto gli occhi sul mondo, non sapevo che comprimere brevi sequenze di dati aumentasse la loro dimensione.
Perché il database sta già facendo un ottimo lavoro di ricerca senza caricare tutti i dati nella RAM.
Infatti, un buon server SQL impostato correttamente (se il vostro hardware ha 64g e 128zu per esempio)
occupa praticamente tutti i 64g meno le necessità del sistema operativo... 128г
e la ricerca di 20 giga di dati (dati pre-cached) - avverrebbe praticamente in memoria...
Ecco perché non ha senso comprimerlo
--
Stai facendo una specie di allusione:
Come cercare, l'ho scritto prima.
Prima di tutto, "accennare" e "affermare" sono concetti diversi.
In secondo luogo, non c'è nemmeno un accenno di questo nelle mie parole, lo dirò di nuovoPer un file sorgente ci sarà un albero, e per una porzione di dati da trovare ce ne sarà un altro
E usando un algoritmo di compressione più o meno serio (qualsiasi classico, anche quello di Huffman) non potrai fare la ricerca. Nemmeno in teoria.
Perché il database sta già facendo un ottimo lavoro di ricerca senza caricare tutti i dati nella RAM.
Prima di tutto, un "suggerimento" e una "affermazione" sono concetti diversi.
In secondo luogo, non c'è nemmeno un accenno di questo nelle mie parole, lo dirò di nuovoIl file di origine avrà un albero, ma la porzione di dati da trovare avrà un proprio albero.
E usando un algoritmo di compressione più o meno serio (qualsiasi classico, anche quello di Huffman) non potrai fare la ricerca. Nemmeno in teoria.
Perché dovrebbe esserci un albero diverso per una porzione di dati, se gli stessi dati sono stati compressi? Se i dati sono diversi, allora che abbia un albero diverso. Ciò che conta per noi è la coincidenza dei dati compressi quando gli stessi dati sono compressi.
Dimitri - se fosse possibile
molto tempo fa avrebbero creato un database industriale SQL - con ricerca (VELOCE) in dati ben compressi (80%-90%)...
anche con Insert Update Delete
1. Questo non è un fatto. Forse i dati sono tali che tutto va tre volte, da cui il semplice algoritmo di compressione.
Il resto... Grazie per avermi aperto gli occhi sul mondo, solo che non sapevo che comprimere brevi sequenze di dati aumenta la loro dimensione.
E un altro piccolo argomento, per tenere gli occhi aperti. Qualsiasi codifica ha uno scopo.
C'è una codifica di decompressione, lo scopo è quello di trasmettere dati binari su canali di comunicazione che supportano solo la telescrivente (ad esempio immagini via e-mail), di solito si usa Base64 basato sull'algoritmo Radix.
Codifica ridondante associata alla correzione dei dati, (come CD Aduio) lo scopo è di proteggere i dati il più possibile dai danni al supporto fisico.
Codifica di compressione, lo scopo stoccaggio/archiviazione dati.
Dmitry - se fosse possibile
avrebbero creato un database SQL industriale molto tempo fa - con ricerca (VELOCE) in dati ben compressi (80%-90%)...
Andare a fare un secondo giro? Inizia a rileggere da pagina 5-6. Leggete il post con particolare attenzione.
Non attribuite a me quello che stavo suggerendo. Ho suggerito di confrontare sequenze condensate che sono compresse indipendentemente l'una dall'altra. Non per cercare un piccolo testo compresso separatamente in un enorme file compresso separatamente alla volta.