Căutare binară sau btree problemă Actualizare index

Mi - ar folosi dif .

Dacă am nevoie să - l pună în aplicare în cadrul programului meu, mi - ar folosi unul dintre algoritmii pentru a găsi cel mai lung subsir comun a două secvențe, tratand fiecare fișier ca o secvență de linii.

„Atunci când vom obține fișierul următor mâine, vom trece prin linia prin linie, crearea unui nou hash pentru fiecare linie și comparând-o cu hash din ziua precedentă.“

Am luat-o: 1m linii de valori hash de azi, comparativ cu 1 milion de linii de valori de ieri.

Nu linii se introduce sau eliminate? Dacă nu, acest lucru este un simplu set de paralel citește pentru a vedea dacă sunt diferite hash.

Dacă există sau adaugă mutări, va trebui să utilizeze algoritmul dif pentru a determina domeniul de aplicare al schimbării.

Tot ceea ce e bine. Nu este prea dificil de implementat.

În acest context, următoarele nu are sens.

Comparația utilizează o metodă de căutare binară string comparare (> <operanzi) Aceasta returnează un rezultat într-o medie de patru iterații.

Există un fel de a comanda la valorile hash? Sau o structura copac?

O carte de 1 milion de linii este foarte mare: există, probabil, 30 - 50 de linii pe pagină, deci să fie generos și să își asume 100 de linii pe pagină, ceea ce înseamnă 10.000 de pagini din carte.

Liniile de 1 KB sunt, de asemenea, mult mai mare decât este normal; lizibilitate de bază sugerează că nicăieri în apropiere de multe caractere pe linie. Intenționați să hash linii de până la 1 KB, sau bucată fișierul în bucăți de 1 KB? O problemă cu schema dumneavoastră este că orice linii repetate ar avea un hash repetat; nu ai putea identifica atunci când s-a adăugat una dintre aceste linii sau șterse.

Ai fi, probabil, trebuie să notifice prea editorul de linii șterse.

Ca și în cazul Glomek, mi - ar folosi diffla dosar. Dacă vă păstrați fișierul sub control RCS sau CVS, ar avea doar versiunea curentă a fișierului și diff între versiunile anterioare stocate. Cu aceasta, v - ar fi în măsură să furnizeze diff cumulative de peste o săptămână sau o lună prea.

Și eu, probabil, nu ar dezvolta propria mea indexare B-Tree.

soluția pe care o descrieți este oarecum similar cu algoritmul rsync. un punct important este faptul că rsync trebuie să recunoască bucăți existente oriunde în fișierul țintă, în orice decalaj față de original.

în cazul în care fișierele sunt într-adevăr RECORD-structurate, puteți simplifica un pic ca propui. dacă nu, aveți nevoie de o sumă de control de rulare.

De asemenea, nu trebuie să recunoască reorderings? sau numai inserții / ștergeri / înlocuiri?

cazul cel mai generic este algoritmul rsync complet, care merge așa:

• Parametri definiție:

  1. alege o dimensiune a blocului 512, sau 1K, de obicei, funcționează bine.
     • alege o sumă de control „puternic“. ceva de genul din MD4 sau cam asa ceva. 64bits sunt o multime.
     • alege un control de rulare „slab“. unul care vă permite să „scădem“ octetul coada și „adăugați“ un octet cap pentru a obține suma de control a unui bloc 1 octet înainte. de obicei, o sumă de control de 16 biți funcționează OK.

• semnătura fișier vechi:

  1. traversa întregul fișier vechi, la fiecare bloc calculează checksum ambele slabe și puternice. cu 16 și 64 de biți checksum și blocuri 512byte ceea ce înseamnă că 10bytes per bloc, sau 20KB per megabit. aceasta este „semnătura“

• a crea „patch“ cu noul fișier și semnătura de fișier vechi:

  1. încărcați semnătura fișierului vechi, cel mai bun este un tabel hash, cu checksum slabe ca chei, checksum puternice și poziția de bloc sunt valorile.
     • citește primul bloc al noului fișier
     • calcula suma de control slab al blocului încărcat
     • verificați tabelul hash pentru a vedea dacă suma de control slab este acolo.
     • dacă este găsit, se calculează suma de control puternic și compară cu cel găsit în hash
     • în cazul în care ambele checksum se potrivesc, marca ca fiind „luat“ cu referința de bloc din hash, avansa un întreg blocksize și du-te înapoi la pasul 3
     • în cazul în care suma de control puternic nu a returnat, sau în cazul în care suma de control slab nu a fost în hash, „roll“ sumei de control slab, care este, „adăugați“ următorul octet după blocului, și „scădem“ primul octet de la coadă.
     • adaugă octetul „scade“ de la coadă la lista de „noi“ octeți în patch-uri
     • du-te înapoi la pasul 4

• aplică patch-uri la dosar vechi

  1. „patch-uri“ este lista de „noi“ bytes care au lăsat în timpul rulării sumei de control, plus lista de blocuri care se potrivesc pe vechiul fișier „luat-o“.

Aceasta este o tehnică utilizată pentru încărcare incrementală pe un depozit de date. În situația în care nu au capacitatea de a identifica datele modificate în cadrul unui sistem de sursă, puteți lua un instantaneu al datelor și se compară cu ultima instantaneu pentru a identifica diferențele. Această tehnică devine chiar o mențiune în cartea lui Ralph Kimball pe această temă și este utilizat într - o aplicație am fost implicat în proiectarea.

Ai nevoie de un algoritm de hashing , cu o cheie foarte largă , deoarece aceasta abordare este vulnerabilă la atacuri ziua de nastere . MD5 sau oricare din familia SHA ar fi bine. De asemenea , nu poate detecta ștergeri fără un post-proces care trece prin diferența în căutarea pentru lipsă chei naturale. Acest calcul de fapt , trebuie să fie conștient de structura pe masă.

O problemă cu schema dumneavoastră este că orice linii repetate ar avea un hash repetat; nu ai putea identifica atunci când s-a adăugat una dintre aceste linii sau șterse

Punct foarte bun, dar nu este o problemă. O linie repetată este un duplicat și toate duplicatele sunt șterse în următoarea etapă de prelucrare. Deci, da, ai dreptate, dar nu este o problemă.

„Dif“ link-ul mă duce la o pagină cu o descriere a ceea ce presupun este o aplicație? Nu există nici o legătură de descărcare, nu există nici un cod în orice limbă ... Ce sunt eu lipsesc aici?

Unii dintre voi ați vorbit despre nivel de octet granularitate. Acest lucru nu este necesar. este necesară numai granularitate nivel de linie pentru că dacă ceva pe linie a fost modificată, întreaga linie (înregistrare) trebuie să fie reprocesate becasue orice modificare în cadrul liniei afectează întreaga linie.

Deci comparăm liniile de aproximativ 1000 de caractere (fără binare), în două fișiere (direct instantaneu și instantaneu yesterdays), care sunt fiecare linii de 1m aprox.

Deci, folosind un hash securizat ca SHA256 (MD5 are coliziuni și este lent prin comparație) pot procesa aproximativ 30 MB / sec pe laptop-ul meu HO. Serverul desigur, va mesteca prin ea mult mai repede.

Deci, dacă fișierul este AROND de 1 GB, atunci ceea ce face toate hases durează aproximativ 33sec, și citirea fișierului 1Gb folosind ferestre de memorie pagină durează aproximativ 30 sec. Nu este oribil

Acum avem două matrici de hashs reprezentând liniile din fiecare fișier. Dacă le vom sorta, putem folosi acum o căutare binară, așa că ne-am iteram drumul nostru prin noile fișiere hashs în căutarea unui meci în fișierele vechi hashs. Dacă noi nu se pare, se adaugă această linie la fișierul modificări.

Rețineți că cartea linii (baze de date vechi) nu este cunoscută în fiecare aspect. Nu există nici o garanție de ordine liniilor, localizarea modificărilor, tipul de modificări.

Sugestiile de citire pagina CUVÂNT de pagină este bună, dar presupune că cele două fișiere sunt în ordinea smae pana ii prima schimbare. Acest lucru nu poate fi asumată. Liniile (rândurile) pot fi în orice ordine. De asemenea, alegerea unui blocksize arbitrar încalcă granularitatea unei linii. În sensul acestei sarcini, liniile sunt imuabile.

De la care se leagă excelent la încărcare invrementa: Fișier de comparare Captură: Această metodă este, de asemenea, cunoscut sub numele de metoda diferențială instantaneu. Această metodă funcționează prin păstrarea înainte și după imagini de fișiere care sunt de interes pentru depozitul de date. Înregistrările sunt comparate pentru a găsi modificările și cheile de înregistrare sunt comparate pentru a găsi inserări și ștergeri. Aceasta tehnica este cea mai potrivită în cazul sistemelor existente, datorită faptului că declanșează de obicei, nu există și registrele de tranzacții sunt fie inexistente sau într-un format proprietar. Deoarece cele mai multe baze de date moștenite au un mecanism de dumping de date în fișiere, această tehnică creează instantanee periodice și apoi se compară rezultatele pentru a produce înregistrări de schimbare. Desigur, toate problemele de captare statice sunt prezente aici. complexitate suplimentară este introdusă prin provocarea de a compara rânduri întregi de informații și prin identificarea și potrivirea cheie. Această tehnică este de natură complexă și de obicei nu este de dorit, dar, în unele cazuri, poate fi singura soluție.

Acest lucru este cel mai relevant aici: Așa cum am proceda în domeniul depozitelor de date terabyte, capacitatea de a reconstrui depozitul de date de la zero pe o bază de noapte va merge pe calea dinozaur. Abordarea logică și eficientă de a actualiza depozitul de date implică o anumită formă de strategie de actualizare incrementală.

Deci, cred ca sunt pe drumul cel bun, atunci? Un indice de btree nu ar da un avantaj?