Bináris keresés, illetve B-fán alapuló indexfrissítés kérdés

Szeretném használni diff .

Ha végrehajtásához szükséges belül saját programot, azt használja az algoritmusok megtalálásához leghosszabb közös alszekvencia két szekvencia, kezelésére minden fájlt sorok sorozatából.

„Akkor, amikor megkapjuk a következő fájl holnap megyünk át rajta sorról sorra, ami egy új hash soronként, és összehasonlítjuk a hash az előző nap.”

Megvan: 1m vonalak mai hashértékek képest 1m vonalak tegnapi értékek.

Ne vonalak kap betenni vagy kivenni? Ha nem, akkor ez egy egyszerű párhuzamos olvasás, hogy ha a hash különbözőek.

Ha vannak hozzá vagy eltávolítása, akkor kell használni a diff algoritmus alkalmazási körének meghatározása a változás.

Minden rendben van. Nem túl nehéz megvalósítani.

Ebben az összefüggésben az alábbi nincs értelme.

Az összehasonlítás használ egy bináris keresési eljárás húr össze (> <operandusok) Ez olyan eredményt ad vissza az átlagosan négy iteráció.

Van valamilyen megrendeléstől a hash? Vagy valami fa struktúra?

Egy könyv 1 millió sornyi hatalmas: van talán 30-50 sorok oldalankénti, úgyhogy legyen nagylelkű, és feltételezik, 100 sor oldalanként, ami azt jelenti, 10.000 oldalak a könyv.

Vonalak 1 KB is sokkal nagyobb, mint a normális; alapvető olvashatóság javasolja a közelében sem, hogy hány karakter soronként. Szándékában áll-e a hash vonalak akár 1 KB vagy harapnak a fájlt 1 KB darabokat? Az egyik probléma a rendszer, hogy minden ismétlődő sorokat lenne ismételni hash; soha nem tudnál azonosítani, ha egy ilyen vonal adunk vagy törölni.

Azt feltehetően kell értesíteni a kiadó törölt sorokat is.

Mint Glomek, szeretném használni diffa fájlt. Ha tartod a fájl alatt RCS vagy a CVS-szabályozás, akkor már csak a jelenlegi változata a fájlt, és a diff közötti korábbi verziók tárolják. Ezzel, akkor lesz képes biztosítani halmozott diffs több mint egy hét vagy hónap is.

És én valószínűleg nem alakul ki a saját B-fa indexelést.

A megoldás akkor írja le némileg hasonlít az rsync algoritmus. Egy fontos pont, hogy rsync felismerni a meglévő darabokat bárhol a kívánt fájlt, bármikor eltolt eredeti.

Ha a fájlok valóban rekord strukturált, lehet egyszerűsíteni egy kicsit, mint javasol. ha nem, akkor kell egy gördülő checksum.

is, van, hogy ismerjék reorderings? vagy csak betoldások / törlések / csere?

A legáltalánosabb esetben a teljes rsync algoritmus, amely így hangzik:

• paraméterek meghatározása:

  1. válasszon egy blokk mérete 512, vagy 1k rendszerint ok.
     • válasszon egy „erős” checksum. valami hasonló származó MD4, vagy úgy. 64bits rengeteg.
     • válasszon egy „gyenge” gördülő checksum. az egyik, hogy lehetővé teszi a „kivonás” a farok bájt és a „hozzáadás” egy fej byte hogy az ellenőrző blokk 1 bájtos előre. általában egy 16 bites checksum rendben működik.

• aláírását régi fájl:

  1. elmozdulási az egész régi fájl, mindegyik blokk kiszámítják gyenge és erős ellenőrző összegeket. a 16 és 64 bit ellenőrző összegeket, és 512 bájtos blokkok azt jelenti 10bytes blokkonként, vagy 20KB megabájtonként. ez az „aláírás”

• hozzon létre „patch” új fájlt, és aláírását régi fájl:

  1. betölteni az aláírás a régi fájlt, a legjobb, ha egy hash tábla, a gyenge ellenőrző összegek segítségével, az erős ellenőrző összegeket és a blokk helyzetben azok az értékek.
     • olvassa el az első blokk az új fájl
     • kiszámítja a gyenge checksum betöltött blokk
     • ellenőrizze a hash tábla, hogy ha a gyenge ellenőrző ott van.
     • ha talál, kiszámítja az erős ellenőrző és hasonlítsuk össze az egyik található a hash
     • ha mindkét ellenőrzőösszegek egyezik, védjegyet „megvan” a blokk utalás a hash, előre egy teljes blocksize, és menjen vissza a 3. lépéshez
     • ha az erős ellenőrző nem egyezik, vagy ha a gyenge checksum nem volt a hash, „roll” gyenge ellenőrző, vagyis a „hozzáadás” a következő bájt után a blokk, és a „kivonás” az első bájt a farok.
     • adjuk hozzá a bájt „levonjuk” a farkát, hogy a lista az „új” byte-tapasz
     • menjen vissza a 4. lépéshez

• alkalmazni patch régi fájl

  1. A „patch” megtalálja az „új” bájtok esett le, amíg a gördülő ellenőrző, valamint a lista „megvan” blokkokat mérkőzés a régi fájlt.

Ez egy olyan technika használható inkrementális betöltése egy adattárház. Abban az esetben, ha nem képesek arra, hogy azonosíthatók legyenek a megváltozott adatok egy forráskódú rendszer, akkor vegye ki a pillanatkép az adatokat, és hasonlítsa össze az utolsó pillanatfelvétel, hogy azonosítsa a különbségeket. Ez a technika még kap egy említést Ralph Kimball könyvet a témában , és amelyet a kérelem részt vettem a design.

Szüksége van egy algoritmus, nagyon széles kulcsfontosságú, mivel ez a megközelítés van téve a születésnapját támadásokat . MD5 vagy az SHA család jó lenne. Ugyancsak nem érzékeli törléseket nélkül utáni folyamat, amely átmegy a különbség keres hiányzó természetes kulcsokat. Ezt a számítást valóban tisztában kell lennie a táblázat szerkezetét.

Az egyik probléma a rendszer, hogy minden ismétlődő sorokat lenne ismételni hash; soha nem tudnál azonosítani, ha egy ilyen vonal adunk vagy törölt

Nagyon jó pont, de nem probléma. A megismételt vonal egy példányban, és minden ismétli hagyni a következő feldolgozási szakaszban. Tehát igen, igazad van, de ez nem okoz problémát.

„Diff” link elvisz egy oldalra egy leírást, amit vállalnak egy olyan alkalmazás? Nincs letöltési linket, nincs kód bármely nyelven ... Mit hagytam itt?

Néhányan közületek már beszéltünk bájtszinten részletesség. Ez nem szükséges. Csak vonalszintű részletesség van szükség, mert ha valami a vonalon már megváltozott, az egész sort (rekordot) kell regenerálni becasue bármilyen változás a vonalon belül kihat az egész vonalon.

Tehát azt összehasonlítjuk vonalak kb 1000 karakter (nem bináris), a két fájl (mai helyzetkép és yesterdays snapshot), amelyek mindegyike kb 1m vonalak.

Tehát egy biztonságos hash mint SHA256 (MD5 van ütközések és lassú képest) tudok feldolgozni kb 30MB / sec én HO laptop. A szerver természetesen elfogy a mely sokkal gyorsabb.

Tehát, ha a fájl Arond 1GB, majd így minden hases kb 33sec, és az olvasás 1Gb fájlt a Windows oldalas memória kb 30 mp. nem szörnyű

Most két tömbök hashs képviselő sorok minden fájlt. Ha rendezni őket, most már bináris keresés használatával, így sokszor ismételjük meg végig az új fájlokat hashs keres egy mérkőzés a régi fájlokat hashs. Ha mi dont találják, hogy sorral egészül ki a változásokat fájlt.

Tartsuk szem előtt, hogy a könyv a vonalak (legacy adatbázis) ismeretlen minden szempontból. Nincs garancia arra, hogy az Elsőfokú sor, helyszín változik, a fajta változás.

A javaslatokat az olvasás foreward oldalanként jó, de feltételezi, hogy a két fájl a smae rendelésre, amíg az első változás. Ezt nem lehet feltételezni. A vonalak (sorok) lehet bármilyen sorrendben. Szintén egy tetszfileges blocksize sérti tagoltságát egy sort. Az E feladat vonalak megváltoztathatatlan.

Ettől kiváló kapcsolatot invrementa betöltés: Fájl Összehasonlítás Capture: Ez a módszer is ismert, mint a pillanatfelvétel eltérés módszer. Ez a módszer működik tartása előtt és után képek fájlok, amelyek foglalkoztatják az adattárház. A rekordokat összehasonlítva azt találtuk, változások, és rekord kulcsok összehasonlítva azt találtuk, beszúrások és törlések. Ez a technika a legalkalmasabb esetében örökölt rendszerek annak a ténynek köszönhető, hogy a kiváltó általában nem léteznek és tranzakciós naplók vagy nem létezik, vagy egy saját formátumban. Mivel a legtöbb régebbi adatbázisok valamilyen mechanizmus dömping adatok fájlokat, ez a technika teremt rendszeres pillanatfelvételek, majd összehasonlítja az eredményeket okoznak változást rekordokat. Természetesen, minden probléma statikus befogó jelen vannak itt. Komplexitás vezetünk a kihívás összehasonlítása egész sora információk és a kulcs azonosító és az illesztés. Ez a technika komplex jellegű, és jellemzően nem kívánatos, de néhány esetben, lehet az egyetlen megoldás.

Ez a legfontosabb idevonatkozó: Ahogy haladunk a birodalmába terabyte adattárházak, a képesség, hogy újjáépítsék az adattárház a semmiből minden éjjel fog menni, ahogy a dinoszauruszok. A logikai és hatékony megközelítés frissítése adattárház jár valamilyen formában az inkrementális frissítési stratégiát.

Szóval azt hiszem, én vagyok a helyes úton, akkor? A B-fán alapuló index nem engedheti meg magának előnyt?