Besoin d'aide ! Je ne peux pas résoudre le problème, je me heurte à des limitations matérielles. - page 7
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
l'idée est claire...
et pourtant cette méthodologie (avec une recherche rapide) n'est pas disponible sur les bases de l'industrie
il doit y avoir une raison
Personne ne parle de la recherche dans les données compressées. Nous parlons de la comparaison de deux séquences compressées.
Supposons un tableau, "aaa", "bbb", "vvvv". Chacun des trois éléments du tableau est compressé indépendamment des autres. Supposons que nous compressions et obtenions le tableau "a", "b", "c".
Nous avons la chaîne recherchée "bbb" que nous devons trouver dans le tableau. Avant la recherche, nous le compressons et obtenons "b". Maintenant, nous cherchons et trouvons.
Soyons clairs, dans votre cas, ce devrait être 3a, 3b et 3c en forme comprimée, car vous omettez le nombre de répétitions.
Si vous pensez qu'un tel algorithme permettra une compression de 70 à 80 %, vous vous trompez. Même sur du texte en langue russe (sans parler des chiffres), cette approche ne fera que gonfler les données.
Par exemple, le mot "Expert" sera recodé sous la forme "1E1k1с1п1е1р1t" et ne sera pas compressé même d'un bit, mais sera gonflé deux fois. Si vous omettez "1", il n'y aura toujours pas de compression.
La date et l'heure 2014.08.18 13:45:45 ne donneront pas de compression à votre façon.
Sans parler des citations... L'efficacité de ce transcodage est donc proche de 0 dans ce cas. Il s'agit de l'algorithme dit RLE utilisé dans le format PCX.
1. Soyons clairs, dans votre cas, ce devrait être 3a, 3b et 3c en forme comprimée, car vous omettez le nombre de répétitions.
Si vous pensez qu'un tel algorithme permettra une compression de 70 à 80 %, vous vous trompez. Même sur du texte en langue russe (sans parler des chiffres), cette approche ne fera que gonfler les données.
Par exemple, le mot "Expert" sera recodé sous la forme "1E1k1с1п1е1р1t" et ne sera pas compressé même d'un bit, mais sera gonflé deux fois. Si vous omettez "1", il n'y aura toujours pas de compression.
La date et l'heure 2014.08.18 13:45:45 ne donneront pas de compression à votre façon.
Sans parler des citations... L'efficacité de ce transcodage est donc proche de 0 dans ce cas. Il s'agit de l'algorithme dit RLE utilisé dans le format PCX.
1. Ce n'est pas un fait. Peut-être que les données sont telles que tout passe trois fois, c'est pourquoi l'algorithme de compression est si simple.
Le reste... Oh merci, vous m'avez ouvert les yeux sur le monde, je ne savais pas que la compression de courtes séquences de données augmentait leur taille.
Parce que la base de données fait déjà un excellent travail de recherche sans avoir à charger toutes les données dans la RAM.
En fait, un bon serveur SQL correctement configuré (si votre matériel a 64g et 128zu par exemple)
occupe pratiquement la totalité des 64g moins les besoins du système d'exploitation ... 128г
et la recherche de 20 gigas de données (données pré-cachées) - se ferait pratiquement en mémoire...
C'est pourquoi il est inutile de le compresser.
--
Tu fais une sorte d'allusion :
Comment chercher, j'ai écrit plus haut.
Tout d'abord, "allusion" et "affirmation" sont des concepts différents.
Deuxièmement, il n'y a pas la moindre allusion à cela dans mes propos, je le répète...Pour un fichier source il y aura un arbre, et pour une portion de données à trouver il y en aura un autre
Et en utilisant un algorithme de compression plus ou moins sérieux (n'importe quel algorithme classique, même celui de Huffman), vous ne serez pas en mesure d'effectuer la recherche. Même pas en théorie.
Parce que la base de données fait déjà un excellent travail de recherche sans avoir à charger toutes les données dans la RAM.
Tout d'abord, un "indice" et une "affirmation" sont des concepts différents.
Deuxièmement, il n'y a pas la moindre allusion à cela dans mes propos, je le répète...Le fichier source aura un arbre, mais la partie des données à trouver aura son propre arbre.
Et en utilisant un algorithme de compression plus ou moins sérieux (n'importe quel algorithme classique, même celui de Huffman), vous ne serez pas en mesure d'effectuer la recherche. Même pas en théorie.
Pourquoi y aurait-il un arbre différent pour une partie des données, si les mêmes données étaient compressées ? Si les données sont différentes, l'arbre doit être différent. Ce qui nous importe, c'est la coïncidence des données compressées lorsque les mêmes données sont compressées.
Dimitri - si c'était possible
il y a longtemps, ils auraient créé une base de données industrielle SQL - avec une recherche (RAPIDE) dans des données bien (80%-90%) compressées...
également avec Insert Update Delete
1. Ce n'est pas un fait. Peut-être les données sont-elles telles que tout passe trois fois, d'où l'algorithme de compression simple.
Le reste... Merci de m'avoir ouvert les yeux sur le monde, je ne savais pas que la compression de courtes séquences de données augmentait leur taille.
Et un autre petit argument, pour garder mes yeux ouverts. Tout codage a un but.
Il existe un codage de décompression, dont le but est de transmettre des données binaires sur des canaux de communication qui ne supportent que le télétype (par exemple, les images par courrier électronique). On utilise généralement le code Base64 basé sur l'algorithme Radix.
Encodage redondant associé à la correction des données, (comme le CD Aduio) le but est de protéger au maximum les données des dommages subis par le support physique.
Le codage de la compression, le but stockage/archivage données.
Dmitry - si c'était possible
ils auraient créé une base de données SQL industrielle depuis longtemps - avec une recherche (RAPIDE) dans des données bien (80%-90%) compressées...
Vous allez faire un deuxième tour ? Commencez à relire à partir de la page 5-6. Lisez le message avec attention.
Ne m'attribuez pas ce que je suggérais. J'ai suggéré de comparer des séquences condensées qui sont comprimées indépendamment les unes des autres. Il ne s'agit pas de rechercher un petit texte compressé séparément dans un énorme fichier compressé séparément à la fois.