Binary Search of btree index-update probleem

Ik zou gebruiken diff .

Als ik moest implementeren binnen het eigen eigen programma, zou ik een van de algoritmen voor het vinden van het gebruik langste gemeenschappelijke subreeks van twee sequenties, behandelen ieder bestand een reeks lijnen.

"Toen we de volgende bestand te krijgen morgen, gaan we er doorheen lijn per lijn, het creëren van een nieuwe hash voor elke lijn en te vergelijken met de hash van de vorige dag."

Begrepen: 1m lijnen van de hedendaagse hash waarden vergeleken met 1M lijnen van de waarden van gisteren.

Laat lijnen word geplaatst of verwijderd? Zo niet, dit is een eenvoudige set van parallelle leest om te zien of de hashes zijn verschillend.

Als er toevoegt of verhuizingen, dan moet je de diff algoritme gebruiken om de omvang van de wijziging te bepalen.

Alle dat is prima. Niet al te moeilijk te implementeren.

In dit verband wordt het volgende heeft geen zin.

De vergelijking maakt gebruik van een binaire zoekmethode touw te vergelijken (> <operands) Dit geeft een resultaat in een gemiddelde van vier iteraties.

Is er een soort van bestellen om de hash-waarden? Of een boomstructuur?

Een boek van 1.000.000 lijnen is enorm: er zijn misschien wel 30 - 50 regels per pagina, dus laten we genereus en gaan ervan uit 100 regels per pagina, wat betekent dat 10.000 pagina's in het boek.

Lijnen van 1 KB is ook veel groter dan normaal; basic leesbaarheid suggereert nergens in de buurt dat veel tekens per regel. Bent u van plan om lijnen van maximaal 1 KB, of chunk het bestand in 1 KB brokken hash? Een probleem met de regeling is dat elke herhaalde lijnen een herhaalde hash zou hebben; je kon nooit te identificeren wanneer een van deze lijnen werd toegevoegd of verwijderd.

Je zou, vermoedelijk, moet de uitgever van geschrapte lijnen te melden.

Net als bij Glomek, zou ik diffop het bestand. Als u het bestand onder RCS of CVS controle te houden, zou je gewoon de huidige versie van het bestand en de diffs tussen eerdere versies bewaard hebben. Met deze, zou je in staat zijn om de cumulatieve diffs over een week of maand te verschaffen.

En ik waarschijnlijk niet zou ontwikkelen mijn eigen B-Tree indexering.

de oplossing die u beschrijft is enigszins vergelijkbaar met de rsync algoritme. Een belangrijk punt is dat rsync moet bestaande brokken overal herkennen in het doelbestand, op elk gewenst ten opzichte van origineel.

Als uw bestanden zijn echt registreert gestructureerd, kan je een beetje te vereenvoudigen, zoals u voorstelt. zo niet, een rollende checksum nodig.

ook, moet je reorderings herkennen? of slechts inserties / deleties / vervangingen?

de meest algemene geval is de volledige rsync algoritme, dat gaat als volgt:

• parameters definitie:

  1. kiezen voor een blok grootte 512 of 1k werken meestal ok.
     • kiezen voor een 'sterke' checksum. zoiets van MD4 of zo. 64bits zijn genoeg.
     • kiezen voor een 'zwak' rolling checksum. een die je 'aftrekken' de staart byte en het toevoegen van een kop byte laat de checksum van een blok 1-byte vooruit te krijgen. meestal een 16-bit checksum werkt ok.

• handtekening van de oude bestand:

  1. traverse de hele oude bestand, op elk blok te berekenen zowel zwakke en sterke checksums. met 16 en 64 bit checksums en 512 Bytes blokken die betekent 10bytes per blok of 20KB per megabyte. dit is de 'handtekening'

• creëren 'patch' met een nieuw bestand, en handtekening van de oude bestand:

  1. de ondertekening van het oude bestand te laden, het beste is een hash tafel, met de zwakke checksums als sleutels, de sterke checksums en blok positie zijn de waarden.
     • Lees het eerste blok van het nieuwe bestand
     • berekenen van de controlesom zwakke geladen blok
     • Controleer de hashtabel of de zwakke controlesom daar.
     • indien gevonden, berekent de controlesom en sterke vergelijken met die welke tijdens de hash
     • als beide controlesommen overeenkomen, markeren als 'kreeg het' met blokreferentie de hash, vooraf een geheel blokgrootte en ga terug naar stap 3
     • als de sterke checksum komt niet overeen, of als de zwakke checksum was niet in de hash, 'roll' de zwakke checksum, dat wil zeggen, de volgende byte 'toevoegen' na het blok, en 'aftrekken' de eerste byte van de staart.
     • voeg de byte 'afgetrokken' van de staart aan de lijst van 'nieuwe' bytes in de patch
     • ga terug naar stap 4

• van toepassing patch voor oude bestand

  1. de 'patch' is de lijst met 'nieuwe' bytes dat afgezet, terwijl het rollen van de checksum, plus de lijst van 'got it' blokken die wedstrijd op het oude bestand.

Dit is een techniek voor belastingsprong een data warehouse. In de situatie waarin u niet de mogelijkheid om gewijzigde gegevens te identificeren binnen een bronsysteem hebt, kun je het afsluiten van een momentopname van de gegevens en vergelijk deze met uw laatste snapshot om de verschillen te identificeren. Deze techniek wordt nog een vermelding in het boek Ralph Kimball over dit onderwerp en wordt gebruikt in een applicatie Ik was betrokken bij het ontwerp van.

U hebt een hash-algoritme met een zeer ruime sleutel als deze aanpak is kwetsbaar voor verjaardag aanvallen . MD5 of een van de familie SHA zou goed zijn. Het kan ook niet deleties op te sporen zonder een post-proces dat door het verschil op zoek naar ontbrekende natuurlijke sleutels gaat. Deze berekening eigenlijk moet zich bewust zijn van de tabel structuur.

Een probleem met de regeling is dat elke herhaalde lijnen een herhaalde hash zou hebben; je kon nooit te identificeren wanneer een van deze lijnen werd toegevoegd of verwijderd

Zeer goed punt, maar geen probleem. Een herhaalde lijn is identiek en alle duplicaten worden verwijderd in de volgende trap van de verwerking. Dus ja je hebt gelijk, maar het is geen probleem.

"Diff" link brengt me naar een pagina met een beschrijving van wat ik veronderstel is een applicatie? Er is geen download link, er is geen code in alle talen ... Wat ben ik hier ontbreekt?

Sommigen van jullie hebben gesproken over byteniveau granulariteit. Dit is niet nodig. alleen lijnniveau granulariteit is nodig omdat als er iets op het spel is veranderd, de gehele lijn (record) moet worden opgewerkt schoonmaakt elke verandering binnen de lijn van invloed op de hele lijn.

Dus we het vergelijken lijnen van ca. 1000 tekens (geen binair), in twee bestanden (vandaag momentopname en gisteren snapshot), die elk ongeveer 1 m lijnen.

Dus met behulp van een veilige hash als SHA256 (MD5 heeft botsingen en is langzaam in vergelijking) Ik kan verwerken ongeveer 30MB / sec op mijn HO laptop. De server van de cursus zal kauwen door middel van het een stuk sneller.

Dus als het bestand arond 1GB, dan is het maken van alle hases duurt ongeveer 33sec, en het lezen van 1Gb bestand met behulp van Windows-pagina geheugen duurt ongeveer 30 sec. niet gruwelijke

Nu hebben we twee arrays van hashs die de lijnen in elk bestand. Als we ze sorteren, kunnen we nu gebruik maken van een binary search, dus we herhalen onze weg door de nieuwe bestanden hashs op zoek naar een wedstrijd in de oude bestanden hashs. Als we niet vinden, wordt die lijn toegevoegd aan het bestand verandert.

Houd in gedachten dat het boek van de lijnen (legacy database) onbekend is in elk aspect. Er is geen garantie van de orde van de lijnen, de locatie van de veranderingen, soorten bewegingen.

De suggesties van het lezen foreward pagina per pagina is goed, maar gaat ervan uit dat de twee bestanden zijn in de smae orde omhoog tot aan de eerste verandering. Dit kan niet worden aangenomen. De lijnen (rijen) kan in elke volgorde. Ook het kiezen van een willekeurige blocksize in strijd met de granulariteit van een lijn. Voor de toepassing van deze taak, lijnen zijn onveranderlijk.

Vanaf dat uitstekend link op invrementa laden: Bestand Vergelijking Capture: Deze methode wordt ook wel bekend als de snapshot differentiële methode. Deze methode werkt door het houden van voor en na foto's van de bestanden die van belang zijn voor het datawarehouse. Records worden vergeleken om veranderingen te vinden, en op te nemen toetsen worden vergeleken met inserts en verwijdert vinden. Deze techniek is het meest geschikt in het geval van legacy-systemen te wijten aan het feit dat de triggers meestal niet bestaan ​​en transactielogboeken zijn ofwel niet-bestaand of in een eigen formaat. Aangezien de meeste legacy databases hebben een mechanisme voor het dumpen van gegevens in bestanden, deze techniek zorgt voor periodieke snapshots en vergelijkt vervolgens de resultaten aan verandering platen te produceren. Zeker, alle problemen van statische capture zijn hier aanwezig. Extra complexiteit wordt geïntroduceerd door de uitdaging van het vergelijken van hele rijen van informatie en door de belangrijkste identificatie en matching. Deze techniek is complex van aard en meestal niet wenselijk, maar in sommige gevallen kan de enige oplossing.

Dit is hier het meest relevant: Als we verder in het rijk van terabyte data warehouses, zal de mogelijkheid om de data warehouse te herbouwen vanuit het niets op basis van één nacht de weg van de dinosaurus te gaan. De logische en efficiënte aanpak van het bijwerken van de data warehouse vereist een zekere vorm van tussentijdse update strategie.

Dus ik denk dat ik op de goede weg dan? Een btree index zou een voordeel niet veroorloven?