Besoin d'aide ! Je ne peux pas résoudre le problème, je me heurte à des limitations matérielles. - page 6

 
YuraZ:

>>> Je ne sais pas ce que je cherche ...

>>> Il faut passer en revue toutes les séquencesà plusieurs reprises et faire des calculs.

Eh bien - oui - recherche - mais il cherche dans 20 gigs...

En principe, la recherche est basée sur le fait qu'il y a une certaine recherche et comparaison

Je m'en tiens à ce que l'auteur a écrit.

Peut-être que les données ne peuvent pas être réduites, compressées et indexées.


il est logique de mettre les données en SQL

transmettre la logique métier au serveur + données

le conseiller expert n'envoie que des données courtes au serveur pour l'énumération et le calcul.

et recevoir une réponse immédiate.

Chercher avec la force brute, c'est le Moyen Âge.
 
Integer:

Oh et je suis frappé par beaucoup de choses ici.

Il me semble que même un enfant devrait être capable de le comprendre. Si un texte est compressé à l'aide d'un algorithme, il sera exactement le même aujourd'hui et demain.

Au fait, 3 téraoctets ont été copiés d'un serveur à l'autre pendant des heures - un réseau de 1 Go.

lorsqu'il a été compressé en ZIP, 3 téraoctets ont été compressés pendant plus d'un jour

Lorsque vous avez acheté l'excellent utilitaire LiteSpeed qui compresse d'abord dans la mémoire du serveur, puis sauvegarde...

le temps de compression de 3 téraoctets a été réduit à quelques heures

Le déballage (pour modifier ou supprimer quelque chose) prend également plusieurs heures.


Résoudre l'algorithme de recherche de données compressées, c'est cool !

peut-être qu'à l'avenir, quelqu'un trouvera des algorithmes pour rechercher les insertions et les suppressions dans des bases de données déjà compressées.

... mais il n'existe pas encore de tels algorithmes à l'échelle industrielle.


Il existe des bases de données industrielles ORACL MS SQL ; personne au monde ne stocke de données sous forme comprimée - si elles font l'objet d'un travail intensif.

 
YuraZ:

1. au fait, 3 téraoctets ont été copiés de serveur en serveur pendant plusieurs heures - 1gb de réseau

lorsqu'il a été compressé en ZIP, 3 téraoctets ont été compressés pendant plus d'un jour

J'ai acheté un utilitaire sympa appelé LiteSpeed qui compresse d'abord la mémoire du serveur, puis fait des sauvegardes.

le temps de compression de 3 téraoctets a été réduit à quelques heures

Le déballage (modifier ou restaurer, supprimer) prend également quelques heures.


2. Résoudre l'algorithme de recherche dans les données compressées, c'est cool !

3. Peut-être qu'à l'avenir, quelqu'un trouvera des algorithmes pour rechercher les insertions et les suppressions dans des bases de données déjà compressées.

4. ... mais il n'existe pas encore de tels algorithmes à l'échelle industrielle.


Il existe des bases de données industrielles ORACL MS SQL ; personne au monde ne stocke les données sous forme comprimée - si vous travaillez intensivement avec elles.

1. Pour la tâche en question, la compression des données n'est effectuée qu'une seule fois et peut prendre une semaine.

2) Qu'est-ce qu'il y a de si cool ?

3) Pourquoi devrions-nous inventer quelque chose ? La question est de savoir si vous en avez besoin ou non.

4. Et si ce n'est pas le cas ?

 
Integer:

1. Pour la tâche en question, la compression des données est faite une fois, vous pouvez la faire pendant une semaine.

2. Qu'est-ce qu'il a de si cool ?

3. Qu'y a-t-il à inventer ? La question est de savoir si cela est nécessaire ou non.

4. Et si ce n'est pas le cas ?

1) p1 seulement après avoir résolu p4

2) eh bien - je ne sais pas peut-être que la question de la recherche(RAPIDE) dans les grands ensembles de données a déjà été étudiée par suffisamment de professionnels qualifiés et plus d'une fois - et jusqu'à présent aucun algorithme.

3) Dieu sait - la recherche dans les données compressées a peut-être été inventée, mais elle n'est pas résolue et très probablement parce qu'elle n'est tout simplement pas nécessaire...

4) peut-être - les meilleurs cerveaux du monde inventeront un algorithme(FAST) de recherche dans les données compressées.

rechercher (LENTEMENT) dans des données compressées est possible - avec une méthodologie (décompresser puis rechercher) ce n'est pas une question...

 

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, cherchez et trouvez.

 
Integer:

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 désirée "bbb" que nous devons trouver dans le tableau. Avant la recherche, nous le compressons et obtenons "b". Maintenant, nous cherchons et trouvons.

l'idée est claire...

et pourtant cette méthodologie (avec une recherche rapide) est absente des bases de données industrielles

il doit y avoir une raison

 
Integer:

Oh et je suis frappé par beaucoup de choses ici.

Il me semble que même un enfant devrait être capable de le comprendre. Si vous comprimez un texte à l'aide d'un algorithme, il sera exactement le même sous forme comprimée aujourd'hui et demain aussi.

Voulez-vous dire qu'en utilisant le même algorithme de compression et en compressant deux textes différents, vous pouvez obtenir deux séquences de données totalement identiques ?

Qu'est-ce qui te fait croire que je dis ça ?

 
YuraZ:

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.

Bien sûr, il y a des raisons :)

La compression des données consiste à éliminer les redondances. Et plus la compression est efficace, moins il y a de redondances. Et la méthode de recherche proposée ci-dessus ne fonctionnera pas, car dans le texte compressé, toute partie dépendra du texte entier.

 
Contender:

Naturellement, il y a des raisons :)

La compression des données consiste à éliminer les redondances. Et plus la compression est efficace, moins il y a de redondance. Et vous ne pouvez pas effectuer de recherche en utilisant la méthode ci-dessus, car dans un texte compressé, toute partie dépend du texte entier.

:-) c'est de cela qu'il s'agit ...
 
elugovoy:

Qu'est-ce qui te fait croire que je dis ça ?

Tu fais une sorte d'allusion :

Eh bien, il vous donnera 4 à 8 fois la compression pour un fichier texte. Il faut tenir compte du fait que les algorithmes de compression créent leurs propres arbres de transcodage pour chaque fichier.

En d'autres termes, le fichier source aura un arbre, mais la partie des données que vous voulez trouver aura un arbre différent..

Je me demande juste comment vous proposez de faire des recherches ? même théoriquement ))))

Comment chercher, j'ai écrit plus haut.