Binary søk eller Btree indeksen oppdatering problemet

Jeg ville bruke diff .

Hvis jeg trengte å implementere det på mitt eget program, vil jeg bruke en av algoritmer for å finne den lengste felles subsequence av to sekvenser, behandle hver fil som en sekvens av linjer.

"Så når vi får neste fil i morgen, går vi gjennom det linje for linje, og skaper en ny hash for hver linje, og sammenligne den med hasj fra dagen før."

Fikk den: 1m linjer av dagens hash verdier sammenlignet med 1M linjer med gårsdagens verdier.

Har linjer blir satt inn eller fjernet? Hvis ikke, er dette et enkelt sett med parallelle leser for å se om de hasher er forskjellige.

Hvis det er legger til eller flytting, må du bruke diff algoritme for å bestemme omfanget av endringen.

Alt som er fint. Ikke for vanskelig å gjennomføre.

I den forbindelse gjør følgende ingen mening.

Sammenligningen anvender en binær søkemetode for strengen sammenligne (> <operander) Dette gir et resultat på et gjennomsnitt av fire iterasjoner.

Er det en slags bestilling til hash verdier? Eller noen trestruktur?

En bok av 1 million linjer er stort: ​​det er kanskje 30 - 50 linjer per side, så la oss være sjenerøse og anta 100 linjer per side, noe som betyr 10.000 sider i boken.

Linjer av en KB er også mye større enn det som er normalt; grunnleggende lesbarhet tyder ikke på langt nær så mange tegn per linje. Har du tenkt til hasj linjer på inntil 1 KB, eller blings filen i 1 KB biter? Et problem med ordningen er at eventuelle gjentatte linjer ville ha en gjentatt hash; du aldri kunne identifisere når en av disse linjene ble lagt til eller slettet.

Du ville antagelig må varsle utgiver av slettede linjer også.

Som med Glomek, vil jeg bruke diffpå filen. Hvis du holder filen under RCS eller CVS kontroll, ville du ha bare gjeldende versjon av filen og differ mellom tidligere versjoner lagret. Med dette, vil du være i stand til å gi kumulative differ enn en uke eller måned også.

Og jeg sannsynligvis ikke ville utvikle min egen B-tree indeksering.

løsningen du beskriver er noe som ligner på rsync-algoritmen. Et viktig poeng er at rsync må anerkjenne eksisterende biter hvor som helst i målfilen, til enhver forskjøvet fra originalen.

Hvis filene er virkelig rekord strukturert, kan du forenkle litt som du foreslår. hvis ikke, trenger du en rullende sjekksum.

også, har du å gjenkjenne reorderings? eller bare innsetting / slettinger / erstatninger?

den mest generelle tilfellet er det full rsync-algoritmen, som går slik:

• parametere definisjon:

  1. velge en blokkstørrelse 512, eller 1k vanligvis fungere ok.
     • velge en 'sterk' checksum. noe som fra MD4 eller så. 64bits er nok.
     • velge en 'svak' rullende checksum. en som lar deg 'subtrahere' halen byte og 'legge' et hode byte å få sjekksummen av en blokk 1-byte fremover. vanligvis en 16-bit sjekksum fungerer ok.

• underskrift av gamle filen:

  1. travers hele gamle filen, i hver blokk beregne både svake og sterke kontrollsummer. med 16 og 64 bits kontrollsummer, og 512byte blokker som betyr 10bytes per blokk, eller 20 kB per megabyte. Dette er 'signatur'

• lage 'patch' med ny fil, og underskrift av gamle filen:

  1. laste signaturen til den gamle filen, er det beste en hash table, med de svake kontrollsummer som nøkler, de sterke sjekksummer og blokk posisjon er verdiene.
     • Les den første blokken på den nye filen
     • beregne svak kontrollsum lastet blokk
     • sjekk hash tabellen for å se om de svake kontrollsummen er der.
     • hvis det blir funnet, beregne sterk sjekksum og sammenligne med den som finnes i hasj
     • Hvis begge sjekksummer matche, merket som 'fikk det' med blokken referanse i hasj, fremme en hel block og gå tilbake til trinn 3
     • hvis den sterke summen samsvarte ikke med, eller om de svake sjekksummen var ikke i hasj, 'roll' de svake sjekksummen, det vil si 'Legg til' neste byte etter blokken, og 'trekke fra' den første byte fra hale.
     • legge til byte 'trukket fra' fra halen til listen over 'nye' byte i oppdateringen
     • gå tilbake til trinn 4

• gjelder patch til gamle filen

  1. den 'patch' er listen over 'nye' byte som falt av mens rullende sjekksum, pluss liste over 'fikk det' blokker som kampen på den gamle filen.

Dette er en teknikk som brukes for inkrementell lasting på et datavarehus. I en situasjon der du ikke har evnen til å identifisere endrede data innenfor et kildesystem, kan du ta ut et øyeblikksbilde av dataene og sammenligne den med din siste snapshot å identifisere forskjeller. Denne teknikken selv får en omtale i Ralph Kimball bok om emnet , og brukes i et program jeg var involvert i utformingen av.

Du trenger en nummeralgoritme med et svært bredt tast som denne tilnærmingen er sårbar for bursdags angrep . MD5 eller noen av SHA familien ville være bra. Det kan heller ikke påvise slettinger uten en post-prosess som går gjennom forskjellen på jakt etter manglende hvite tangentene. Denne beregningen faktisk trenger å være klar over tabellstrukturen.

Et problem med ordningen er at eventuelle gjentatte linjer ville ha en gjentatt hash; du aldri kunne identifisere når en av disse linjene ble lagt til eller slettet

Veldig godt poeng, men ikke et problem. En gjentatt linje er en duplikat, og alle duplikater blir slettet i det neste trinn av behandlingen. Så ja du har rett, men det er ikke et problem.

"Diff" linken tar meg til en side med en beskrivelse av hva jeg antar er en applikasjon? Det er ingen nedlasting link, er det ingen kode på alle språk ... Hva er det jeg mangler her?

Noen av dere har snakket om byte nivå granularitet. Dette er ikke nødvendig. bare linjenivå granularitet er nødvendig fordi hvis noe på linjen er endret, må hele linjen (rekord) behandles på nytt fordi noen endring innenfor linjen påvirker hele linjen.

Så vi sammenligner linjer med ca 1000 tegn (ingen binære), i to filer (dagens snapshot og yesterdays snapshot) som hver er ca 1m linjer.

Så bruker en sikker hash som SHA256 (MD5 har kollisjoner og er treg ved sammenligning) Jeg kan behandle om 30MB / sek på min HO laptop. Serveren selvfølgelig vil tygge gjennom det mye raskere.

Så hvis filen er rundt et langbord 1GB, tar ca 33sec så gjør alle hases, og lese 1Gb filen ved hjelp av Windows siders minne tar ca 30 sekunder. ikke forferdelige

Nå har vi to rekker av hashs representerer linjene i hver fil. Hvis vi sortere dem, kan vi nå bruke en binær søk, så vi gjenta vår vei gjennom de nye filene hashs jakt etter en kamp i de gamle filene hashs. Hvis vi ikke finner det, er at linjen legges til endringer filen.

Husk at boka linjer (legacy database) er ukjent i alle aspekter. Det er ingen garanti for bestilling av linjer, plassering av endringer, type endringer.

Forslagene med lesing foreward side ved side er bra, men forutsetter at de to filene er i smae orden opp inntil den første endringen. Dette kan ikke bli antatt. De linjer (rader) kan være i hvilken som helst rekkefølge. Også velge en vilkårlig block bryter detaljene for en linje. Ved anvendelsen av denne oppgaven, linjene er uforanderlig.

Fra den gode linken på invrementa lasting: filsammenligningen Capture: Denne metoden er også kjent som snapshot differensial metoden. Denne metoden fungerer ved å holde før og etter bilder av filer som er av interesse for datavarehuset. Records er sammenlignet for å finne endringer, og rekord tastene er i forhold til å finne inserts og sletter. Denne teknikken er mest hensiktsmessig i tilfelle av eksisterende systemer på grunn av det faktum som utløser vanligvis ikke eksisterer og transaksjonslogger er enten ikke-eksisterende eller i et proprietært format. Siden de fleste eldre databaser har noen mekanisme for dumping data i filer, skaper denne teknikken periodiske øyeblikksbilder og sammenligner resultatene til å produsere endre poster. Riktignok alle problemene med statiske fangst er tilstede her. Lagt kompleksitet er innført av utfordringen med å sammenligne hele rader med informasjon og med nøkkel identifikasjon og matching. Denne teknikken er kompleks art og vanligvis ikke ønskelig, men i noen tilfeller kan være den eneste løsningen.

Dette er mest relevant her: Når vi går inn i riket av terabyte datavarehus, vil evnen til å gjenoppbygge datavarehus fra bunnen av på en nattlig basis gå veien for dinosaur. Den logiske og effektiv tilnærming til å oppdatere datavarehuset innebærer noen form for inkrementell oppdatering strategi.

Så jeg antar jeg er på rett spor da? En btree indeksen ville ikke råd til en fordel?