Recherche binaire ou index Btree numéro de mise à jour

J'utiliser diff .

Si je devais le mettre en œuvre dans mon propre programme, je voudrais utiliser l' un des algorithmes pour trouver la plus longue séquence commune de deux séquences, traiter chaque fichier comme une séquence de lignes.

« Alors quand nous le fichier suivant demain, nous passons par ligne par ligne, la création d'un nouveau hachage pour chaque ligne et en le comparant au hachage de la veille. »

Got it: 1m lignes de valeurs de hachage d'aujourd'hui par rapport à 1 m des lignes de valeurs d'hier.

Est-ce que les lignes s'insérés ou supprimés? Dans le cas contraire, cela est un ensemble simple parallèle lit pour voir si les hash sont différents.

S'il y a d'ajouter ou de déménagement, vous devrez utiliser l'algorithme de diff pour déterminer la portée du changement.

Tout ce qui est très bien. Pas trop difficile à mettre en œuvre.

Dans ce contexte, ce qui suit ne fait aucun sens.

La comparaison utilise une méthode de recherche binaire de comparaison de chaînes (> <opérandes) Ceci renvoie un résultat en une moyenne de quatre itérations.

Y at-il une sorte de commande aux valeurs de hachage? Ou une structure d'arbre?

Un livre de 1 million de lignes est énorme: il y a peut-être 30 - 50 lignes par page, donc soyons généreux et assumer 100 lignes par page, ce qui signifie 10.000 pages dans le livre.

Les lignes de 1 Ko sont également beaucoup plus grande que la normale; la lisibilité de base suggère loin que beaucoup de caractères par ligne. Avez-vous l'intention de hachage lignes jusqu'à 1 Ko ou morceau le fichier en 1 morceaux KB? Un problème avec votre système est que toutes les lignes répétées auraient un hachage répété; vous ne pourriez jamais identifier quand l'une de ces lignes a été ajouté ou supprimé.

Vous,, besoin sans doute pour informer l'éditeur de lignes supprimées.

Comme avec Glomek, j'utiliser diffsur le fichier. Si vous gardez le fichier sous contrôle RCS ou CVS, vous auriez la version juste actuelle du fichier et les diffs entre les versions antérieures stockées. Avec cela, vous seriez en mesure de fournir des diffs cumulés sur une semaine ou un mois aussi.

Et je ne serais probablement pas développer mon propre indexation B-Tree.

la solution que vous décrivez est un peu similaire à l'algorithme de rsync. un point important est que rsync doit reconnaître des morceaux existants partout dans le fichier cible, à tout décalage de l'original.

si vos fichiers sont vraiment Électrophones structurés, vous pouvez simplifier un peu comme vous proposez. sinon, vous avez besoin d'une somme de contrôle de roulement.

En outre, vous devez reconnaître réordonnancements? ou seulement des insertions / suppressions / remplacements?

le cas le plus générique est l'algorithme complet rsync, qui va comme ceci:

• définition des paramètres:

  1. choisir une taille de bloc 512, ou 1k fonctionne généralement bien.
     • choisissez une somme de contrôle « fort ». quelque chose comme de MD4 ou ainsi. 64bits sont beaucoup.
     • choisissez une somme de contrôle de roulement « faible ». qui vous permet de « Retirer » l'octet de queue et « ajouter » un octet de tête pour obtenir la somme de contrôle d'un bloc 1 octet avant. habituellement une somme de contrôle 16 bits fonctionne bien.

• signature de l'ancien fichier:

  1. traversent le fichier entier vieux, à chaque bloc calculer à la fois faibles et forts checksum. avec 16 et 64 bits totaux de contrôle et des blocs de 512 octets qui signifie 10bytes par bloc, ou 20KB par mégaoctet. c'est la « signature »

• créer « patch » avec le nouveau fichier et la signature de l'ancien fichier:

  1. charger la signature de l'ancien fichier, le meilleur est une table de hachage, avec les faibles checksums que les clés, les checksums fortes et position du bloc sont les valeurs.
     • lire le premier bloc du nouveau fichier
     • calculer la somme de contrôle du bloc faible charge
     • vérifier la table de hachage pour voir si la somme de contrôle faible est là.
     • si trouvé, calculer la somme de contrôle forte et comparer avec celle trouvée dans le hachage
     • si les deux correspondent checksums, marque comme « got it » avec la référence de bloc dans le hachage, avancer un tout blocksize et revenir à l'étape 3
     • si la somme de contrôle forte ne correspond, ou si la somme de contrôle n'a pas été faible dans le hachage, « roll » la somme de contrôle faible, qui est, « ajouter » l'octet suivant après le bloc, et « Retirer » le premier octet de la queue.
     • ajouter l'octet « retranchées » de la queue à la liste des octets « nouveaux » dans le patch
     • revenez à l'étape 4

• appliquer le correctif à l'ancien fichier

  1. le « patch » est la liste des « nouveaux » octets qui déposais tout en roulant la somme de contrôle, ainsi que la liste des « got it » blocs qui correspondent à l'ancien fichier.

Ceci est une technique utilisée pour le chargement supplémentaire sur un entrepôt de données. Dans le cas où vous n'avez pas la possibilité d'identifier les données modifiées dans un système source, vous pouvez prendre un instantané des données et le comparer avec votre dernier instantané d'identifier les différences. Cette technique obtient même une mention dans le livre de Ralph Kimball sur le sujet et est utilisé dans une application que je participais à la conception.

Vous avez besoin d' un algorithme de hachage avec une clé très large car cette approche est vulnérable aux attaques d'anniversaire . MD5 ou l' une de la famille SHA serait bon. Il ne peut pas détecter également les suppressions sans post-traitement qui passe par la différence à la recherche de clés manquantes naturelles. Ce calcul a réellement besoin d'être au courant de la structure de la table.

Un problème avec votre système est que toutes les lignes répétées auraient un hachage répété; vous ne pourriez jamais identifier quand l'une de ces lignes a été ajouté ou supprimé

Très bon point, mais pas un problème. Une ligne répété est un doublon et tous les doublons sont supprimés dans l'étape suivante du traitement. Alors oui, vous avez raison, mais ce n'est pas un problème.

lien « diff » me amène à une page avec une description de ce que je suppose est une application? Il n'y a pas de lien de téléchargement, il n'y a pas de code dans toutes les langues ... Qu'est-ce que je manque ici?

Certains d'entre vous ont parlé de granularité de niveau octet. Ce n'est pas nécessaire. seule granularité de niveau de ligne est nécessaire parce que si quoi que ce soit sur la ligne a été modifiée, la ligne entière (enregistrement) doit être retraitée becasue tout changement au sein de la ligne affecte toute la ligne.

Donc, nous comparons les lignes d'environ 1000 caractères (pas binaires), dans deux fichiers (aujourd'hui instantané et instantané) Yesterdays qui sont chaque ligne de 1 m d'env.

Donc, en utilisant un hachage sécurisé comme SHA256 (MD5 a des collisions et est lent par comparaison) Je peux traiter environ 30 Mo / s sur mon ordinateur portable HO. Le serveur bien sûr de mâcher à travers elle beaucoup plus rapide.

Donc, si le fichier est arond 1 Go, puis faire tous les hases prend environ 33sec, et la lecture de fichiers 1Go en utilisant des fenêtres mémoire de page prend environ 30 secondes. pas terrible

Maintenant, nous avons deux tableaux de hashs représentant les lignes de chaque fichier. Si nous les trions, nous pouvons maintenant utiliser une recherche binaire, donc nous réitérons notre chemin à travers les nouveaux fichiers hashs à la recherche d'un match dans les anciens fichiers hashs. Si nous ne le trouver, cette ligne est ajoutée au fichier des modifications.

Gardez à l'esprit que le livre de lignes (base de données héritée) est inconnue dans tous les aspects. Il n'y a aucune garantie de l'ordre des lignes, la localisation des changements, le type de changements.

Les suggestions de lecture Page foreward par la page est bonne, mais suppose que les deux fichiers sont dans l'ordre smae jusqu'à jusqu'à ce que le premier changement. Cela ne peut pas supposer. Les lignes (rangées) pourraient être dans un ordre quelconque. choisir également un blocksize arbitraire constitue une violation de la granularité d'une ligne. Pour les besoins de cette tâche, les lignes sont immuables.

De cet excellent lien sur le chargement de invrementa: Fichier Comparaison Capture: Cette méthode est également connu comme la méthode différentielle de l'instantané. Cette méthode fonctionne en gardant avant et après les images de fichiers qui préoccupent l'entrepôt de données. Les enregistrements sont comparés à trouver des changements, et les clés d'enregistrement sont comparés pour trouver des insertions et des suppressions. Cette technique est la plus appropriée dans le cas des systèmes existants en raison du fait que les déclencheurs généralement n'existent pas et les journaux de transactions sont soit inexistants, soit dans un format propriétaire. Comme la plupart des bases de données existantes ont un mécanisme pour les données du dumping dans les fichiers, cette technique crée des instantanés périodiques et compare ensuite les résultats pour produire les documents de changement. Certes, tous les problèmes de capture statique sont présents ici. la complexité ajoutée est introduite par le défi consistant à comparer des lignes entières d'information et par l'identification et la clé correspondant. Cette technique est complexe dans la nature et généralement pas souhaitable, mais, dans certains cas, peut être la seule solution.

Ceci est le plus pertinent ici: Alors que nous poursuivons dans le domaine des entrepôts de données téraoctet, la capacité de reconstruire l'entrepôt de données à partir de zéro sur une base quotidienne sera le chemin du dinosaure. L'approche logique et efficace pour mettre à jour l'entrepôt de données implique une certaine forme de stratégie de mise à jour incrémentale.

Donc, je suppose que je suis sur la bonne voie alors? Un indice de btree n'offrirait un avantage?