Plan-X: XCompact. Komprimeret serialisering af semi-struktureret data. Bachelorprojekt i datalogi. Christian Iversen, Espen Højsgaard, Rune Højsgaard

Plan-X: XCompact Komprimeret serialisering af semi-struktureret data Bachelorprojekt i datalogi Christian Iversen, Espen Højsgaard, Rune Højsgaard Forår 2005 Datalogisk Institut Københavns Universitet Vejleder: Fritz Henglein

Resumé Denne opgave beskriver en metode til komprimeret serialisering af XML-dokumenter, kaldet XCompact. XCompact adskiller sig fra andre XML-specifikke kompresionsmetoder, ved at den kompakte serialisering kan navigeres som en træstruktur. Vores evaluering viser, at XCompact ikke kan konkurrere med eksisterende værktøjer på kompression alene i bedste fald komprimerer XCompact halvt så godt. XCompact s serialiserede format kan bruges som backend til XML Store, hvilket vi har implementeret som CompactStore. Evalueringen viser at CompactStore i nogle tilfælde er hurtigere og i andre tilfælde langsommere end Koala XML Store s LocalXMLStore. Tak til For projektoplæg, råd og vejledning vil vi gerne takke Fritz Henglein. Ydermere vil vi gerne takke Henning Niss, der har været behjælpelig med at forklare XMLStorearkitekturen. Rasmus Jensen skal have tak for en god introduktion til komprimering og for henvisninger til artikler om kompression. 2

INDHOLD Indhold Indhold 3 1 Indledning 7 1.1 Problemformulering............................... 7 1.2 Uddybning og afgrænsning........................... 7 1.3 Relateret arbejde................................ 8 1.4 Konklusion................................... 8 2 Baggrundsmateriale 9 2.1 XML....................................... 9 2.1.1 Indlæsning................................ 10 2.1.2 XOP................................... 10 2.2 Document Value Model og XML Store.................... 11 2.2.1 Værdiorienteret programmering.................... 11 2.2.2 DVM................................... 12 2.2.3 XML Store............................... 12 2.3 Kompression................................... 12 2.3.1 LZ77 og LZ78.............................. 14 2.3.2 Huffman-kodning............................ 14 2.4 XML kompression................................ 17 3 Komprimeret og navigerbar serialisering af XML 19 3.1 Designmål.................................... 19 3.1.1 Begrænsninger............................. 19 3.1.2 Navigation................................ 20 3.1.3 Round-tripping............................. 20 3.2 Struktur og data................................ 21 3.2.1 Attributter............................... 21 3.3 Data....................................... 21 3.3.1 Gruppering............................... 22 3.3.2 Komprimering.............................. 23 3.4 Struktur..................................... 24 3.4.1 En naiv strukturrepræsentation.................... 24 3.4.2 Opdeling i struktur og metadata.................... 25 3.4.3 Samlet liste af knuder......................... 25 3.4.4 Pladseffektiv repræsentation af talliste................ 26 3.4.5 Pladseffektive pegere til data..................... 26 3.4.6 Delte undertræer............................ 26 3.4.7 Huffman-kodning af indeksnumre................... 27 3.4.8 Effektiv kodning af knude-navne.................... 27 Side 3 af 169

INDHOLD 3.5 Det endelige format............................... 28 4 Implementation 30 4.1 Huffman-kodning................................ 30 4.2 XMLStore.................................... 30 4.3 Læsevejledning................................. 31 4.4 Brugervejledning................................ 32 4.4.1 XCompress & XDecompress...................... 32 4.4.2 CompactStore.............................. 33 4.5 Afprøvning................................... 33 5 Empirisk evaluering 34 5.1 Datasæt..................................... 34 5.1.1 Platform................................. 35 5.2 Kompression................................... 35 5.2.1 XCompact................................ 35 5.2.2 Sammenligning med andre kompressorer............... 38 5.3 Navigation.................................... 39 5.3.1 Praktiske problemer og mulige fejlkilder............... 39 5.3.2 Forespørgsler.............................. 40 5.3.3 Sammenligning af CompactStore og LocalXMLStore........ 41 5.4 Anvendelighed.................................. 42 6 Fremtidigt arbejde 43 7 Litteratur 44 A Scripts 47 A.1 Script til XPath-testkørsler........................... 47 A.2 Script til kompressionstestkørsler....................... 48 B Kildekode 50 B.1 org.planx.xcompact.cli............................. 50 B.1.1 CleanXML.java............................. 50 B.1.2 CompactBuilder.java.......................... 52 B.1.3 CompactDumper.java.......................... 53 B.1.4 CropXML.java............................. 54 B.1.5 StatXML.java.............................. 57 B.1.6 StoreBuilder.java............................ 60 B.1.7 StorePath.java.............................. 60 B.1.8 XCompress.java............................. 61 B.1.9 XDecompress.java............................ 62 B.1.10 XMLStoreBuilder.java......................... 62 B.1.11 XMLStoreDumper.java......................... 63 Side 4 af 169

INDHOLD B.1.12 XPathBench............................... 64 B.2 org.planx.xcompact.compression........................ 66 B.2.1 DifferenceDecodeIntIterator.java.................... 66 B.2.2 DifferenceDecodeLongIterator.java.................. 67 B.2.3 IntegerListCompression.java...................... 69 B.2.4 Options.java............................... 76 B.2.5 SimpleDecodeIntIterator.java..................... 79 B.2.6 SimpleDecodeLongIterator.java.................... 80 B.2.7 StringListCompression.java...................... 82 B.3 org.planx.xcompact.compression.huffman................... 83 B.3.1 HuffmanCodeBook.java......................... 83 B.3.2 HuffmanCodeCalculator.java...................... 85 B.3.3 HuffmanCodeTable.java........................ 88 B.3.4 HuffmanElement.java.......................... 89 B.3.5 HuffmanException.java......................... 89 B.3.6 HuffmanIterator.java.......................... 89 B.3.7 HuffmanList.java............................ 90 B.3.8 HuffmanReader.java.......................... 90 B.4 org.planx.xcompact.compression.xml..................... 93 B.4.1 AbstractElement.java.......................... 93 B.4.2 CodeBookBuilder.java......................... 94 B.4.3 CompactNode.java........................... 96 B.4.4 DefaultLocator.java........................... 96 B.4.5 DefaultLocatorFormatter.java..................... 97 B.4.6 DefaultLocatorReader.java....................... 102 B.4.7 DefaultXMLCompressor.java...................... 104 B.4.8 DefaultXMLDecompressor.java.................... 112 B.4.9 Element.java.............................. 115 B.4.10 Header.java............................... 118 B.4.11 IncompatibleLocatorException.java.................. 121 B.4.12 Locator.java............................... 122 B.4.13 LocatorFormatter.java......................... 123 B.4.14 LocatorReader.java........................... 124 B.4.15 NodeInfo.java.............................. 124 B.4.16 SAXHandler.java............................ 125 B.4.17 StructureSerializer.java......................... 128 B.4.18 UnsupportedFieldException.java.................... 129 B.4.19 XMLCompressor.java.......................... 129 B.4.20 XMLDecompressor.java........................ 130 B.5 org.planx.xcompact.compression.xml.containers............... 130 B.5.1 Container.java.............................. 130 B.5.2 ContainerManager.java......................... 131 B.5.3 ContainerReader.java.......................... 132 Side 5 af 169

INDHOLD B.5.4 DeflateContainerReader.java...................... 132 B.5.5 DeflateSharedContainer.java...................... 133 B.5.6 DeflateSharedContainerManager.java................. 134 B.5.7 DeflateSingleContainer.java...................... 135 B.5.8 DeflateSingleContainerManager.java.................. 136 B.5.9 DeflateTagContainerManager.java................... 137 B.5.10 HuffmanSharedContainer.java..................... 138 B.5.11 HuffmanSharedContainerManager.java................ 142 B.5.12 HuffmanSharedContainerReader.java................. 143 B.5.13 HuffmanSingleContainerManager.java................. 144 B.5.14 HuffmanTagContainerManager.java.................. 145 B.5.15 RawContainerReader.java....................... 146 B.5.16 RawSharedContainer.java....................... 147 B.5.17 RawSharedContainerManager.java................... 148 B.5.18 RawSingleContainerManager.java................... 149 B.5.19 RawTagContainerManager.java.................... 150 B.6 org.planx.xcompact.io............................. 151 B.6.1 BitInputStream.java.......................... 151 B.6.2 BitOutputStream.java......................... 152 B.6.3 DataInputStreamAdapter.java..................... 154 B.6.4 FileList.java............................... 155 B.6.5 LimitedInputStream.java........................ 155 B.6.6 RandomAccessBitInput.java...................... 156 B.7 org.planx.xcompact.store............................ 157 B.7.1 AbstractIterator.java.......................... 157 B.7.2 CompactReader.java.......................... 158 B.7.3 CompactReference.java......................... 164 B.7.4 CompactStore.java........................... 164 B.7.5 CompactStoreReference.java...................... 166 B.7.6 CorruptedStoreException.java..................... 167 B.7.7 ProxyNode.java............................. 167 B.8 org.planx.xcompact.util............................. 167 B.8.1 GenericArray.java............................ 167 B.8.2 Pair.java................................. 168 B.8.3 ResetIterator.java............................ 168 B.8.4 Unboxer.java.............................. 168 B.8.5 UnboxingIterator.java......................... 169 Side 6 af 169

1 INDLEDNING 1 Indledning XML-dokumenter er selvbeskrivende tekstdokumenter, der indeholder semi-struktureret data. Indholdet af et XML-dokument kan opfattes som en træstruktur med ustruktureret data ved bladene. XML-dokumenter kan læses af både mennesker og maskiner en egenskab der opnås med en meget verbos og delvis redundant syntaks, hvilket medfører at XMLdokumenter optager meget lagerplads i forhold til deres informationsindhold. Sammenligner man eksempelvis med en almindelig databaseløsning, hvor metadata gemmes én gang for hele databasen, gemmes det i XML én gang for hver post (eng. record). Da XML-dokumenter er pladskrævende er det ønskværdigt at komprimere dem. Dette kan gøres med generelle værktøjer til tekstkomprimering som gzip eller bzip2. Alternativt kan værktøjer, der er specialiseret til kompression af XML anvendes, f.eks. XMill af Liefke og Suciu [20]. XMill kan komprimere XML-dokumenter omtrent lige så godt som bzip2. Denne kompression opnås ved at samle ensartet data i containere, og komprimere hver container for sig med gzip eller brugerspecificerede kompressionsværktøjer. Disse kompressorer reducerer pladsforbruget, men bevirker at det komprimerede XMLdokument ikke længere kan læses og tolkes uden en komplet dekompression en operation der kræver tid og hukommelse. Det er derfor ønskværdigt med et værktøj, der kan komprimere og serialisere XML-dokumenter til et format, hvor strukturen kan navigeres uden en forudgående deserialisering og dekompression. XML Store [23] er en værdiorienteret lagerfacilitet til gemme XML-dokumenter. XML S- tore implementerer Document Value Model (DVM) API et, der modellerer XML-dokumenter som et træ, hvor man kan følge kanterne fra en knude til dens børn. Metoden, der beskrives i denne rapport, er målrettet mod at lave en komprimeret serialisering af XML, hvorpå en pladsbesparende implementation af DVM API et kan baseres. Rapporten antager at læseren er bekendt med grundlæggende datalogiske begreber eksempelvis træstrukturer men forudsætter ikke et kendskab til hverken komprimering eller XML. Denne rapport, kildekode og datasæt m.m. kan hentes fra projektets hjemmeside [37]. 1.1 Problemformulering Projektet har til formål at undersøge følgende: Er det mulig at lave en komprimeret serialisering af et XML-dokument, der effektivt kan navigeres efter DVM-modellen og som endvidere har en kompressionsratio svarende til XMill s. 1.2 Uddybning og afgrænsning De basale idéer vi vil basere vores metode på er følgende: 1. identiske undertræer slås sammen, hvorved træet transformeres til en DAG 1 1 Directed Acyclic Graph Side 7 af 169

1 INDLEDNING 2. anvend tekstkomprimering på karakterdata 3. DAG en serialiseres som en Huffman-kodet listerepræsentation, baseret på knudernes indvalens Punkt 1. udføres allerede effektivt i XML Store og vi vil derfor ikke undersøge dette aspekt den interesserede læser henvises til [5]. Punkt 2. er et område, hvor flere projekter, bl.a. XMill, har vist at en stor kompression kan opnås, ved at tage karakterdatas placering i træstrukturen i betragtning. Vi vil i denne rapport se på, hvilke modeller andre projekter har anvendt og hvilke der er brugbare, når navigationen skal bevares. Punkt 3. forekommer som et simpelt spørgsmål om at implementere en Huffman-koder. Dette er korrekt med hensyn til selve kodningen af strukturen. Men når det kommer til kodebogen, så er der mange måder at komprimere og serialisere den. Det særlige ved vores kodebog er, at den indeholder graf-knuder med tilknyttet information, nemlig knudens navn. Da mange knuder i et XML-dokument ofte har samme navn, vil det være uhensigtsmæssigt at gemme navnet sammen med hver knude. Hvis dette kan undgås, kan der spares plads. 1.3 Relateret arbejde Der findes meget litteratur om komprimering generelt, men mængden af litteratur om XML-specifik komprimering er meget begrænset. De metoder vi er bekendt med, er XMill [20], XGrind [25], SCM [3] og Multiplexed Hierachical Modelling (MHM) [7], der er baseret på Prediction by Partial Match (PPM). Disse metoder er belbeskrevne og det er det er ideerne fra disse, som vores metode baserer sig på. Vi har i afsnit 2.4 en beskrivelse af de fire metoder. 1.4 Konklusion Vi har i denne opgave designet, implementeret og evalueret en metode XCompact til komprimeret serialisering af XML-dokumenter. Vores kompression er ikke nær så god som XMill s, men 2-3 gange dårligere. I modsætning til XMill er vores serialiserede format derimod navigerbart. Metoden er implementeret som en backend til XML Store kaldet CompactStore. Hastigheden af navigation i CompactStore afviger både positivt og negativt fra LocalXMLStore afhængig af navigationsmønsteret og datasættet ydere evaluering og profilering er nødvendig for at karakterisere og begrunde forskellene. Først ordens Markov-modellen fra XMill har for vores metode givet dårligere resultater, end ved at komprimere alt karakterdata samlet. Dette kan skyldes, den anvendte kompressionsmetode. Side 8 af 169

2 BAGGRUNDSMATERIALE 2 Baggrundsmateriale I det følgende introduceres de koncepter, som vores metode bygger på. Vi giver ikke en tilbundsgående behandling af de pågældende emner, men fokuserer på de aspekter, der er relevante for vores metode. 2.1 XML Siden de første computere kom på markedet, er der blevet opfundet et utal af specialiserede filformater til opbevaring af data i det faste lager. Mange af disse formater er kun blevet brugt til ganske få projekter, hvorved al programmeringsarbejdet til at opnå læse- og skriveadgang har måttet gentages for hvert program. Ud over det åbenlyse problem at udviklingen tager længere tid, er der andre hensyn, der taler imod denne udviklingsmodel eksempelvis at eventuelle fejl, kun skulle rettes én gang, hvis programmerne kunne dele koden, der tilgår datafilerne, Ud fra et ønske om at løse dette problem, har et antal formater med varierende grad af standardisering bag sig opnået stor udbredelse. Et af disse er XML, der kan bruges til at beskrive semi-struktureret data. I XML (extensible Markup Language) søger man at gøre ethvert dokument læsbart for mennesker ved at bruge sigende navne i alle notationer, og mindske mængden af data der ikke kan fortolkes uden hjælpeprogrammer. Denne begrænsning er et ønskværdigt mål mere end en teknisk begrænsning, da det så absolut er muligt at konstruere XMLdokumenter, der er aldeles uigennemskuelige for mennesker. Dette gøres nemmest ved at ignorere mulighederne for at angive strukturen af de data der arbejdes med, som det ses i figur 1. 1 <data > c2e8975aed96f735700b84fa24771221 </ data > Figur 1: Eksempel på ulæselig XML Grundlæggende er en XML-fil en tekstuel repræsentation af et datatræ, og der er således én rodknude, der indeholder hele dokumentet. Hver knude kan have et ubegrænset antal attributter og børn i form af tekstdata og yderligere knuder. Et eksempel på velstruktureret XML ses i figur 2. Knuder har navngivne markeringer, tags, der har formen <tagname>contents</tagname>, med mindre knuderne ingen børn har, i hvilket fald de kan, men ikke skal, have formen <tagname/>. Attributdata har formen name="value", og skrives inden i tagget, som det ses på figuren. Det er ikke tilladt at bruge samme attributnavn flere gange i samme tag. 1 < rootnode > 2 <child name =" value ">Character data </ child > 3 <child name =" other ">More data </ child > 4 </ rootnode > Figur 2: Eksempel på velstruktureret XML Side 9 af 169

2 BAGGRUNDSMATERIALE 2.1.1 Indlæsning Der findes flere metoder til at tilgå XML-filer, hvoraf Simple API for XML [21] og Document Object Model [10] er de to mest udbredte. SAX er en hændelsesbaseret API, der giver en række signaler til brugerprogrammet når man når til en ny knude, støder på tegndata, afslutter en knude, etc. I figur 3 ses et eksempel på SAX-hændelser. 1 start knude : rootnode 2 start knude : child ( attributer : name =" value ") 3 tegndata : " Character data " 4 slut knude : child 5 start knude : child ( attributer : name =" other ") 6 tegndata : " More data " 7 slut knude : child 8 slut knude : rootnode Figur 3: SAX-hændelser til XML i figur 2 Der er flere fordele ved SAX frem for andre API er til læsning af XML. En SAXparser leverer løbende events med data fra dokumentet, mens dokumentet parses. Forbruget af arbejdshukommelse kan derfor holdes lavt, da parseren leverer data direkte videre til applikationen det er så applikationen der er ansvarlig for at tolke eventen og vælge om data skal bevares i hukommelsen. DOM er baseret på en objektorienteret model af dataindholdet i XML-filen. Dokumentet præsenteres som rodknuden i et træ. Det er via denne knude muligt at få dens attributter og et vilkårligt barn. Fordelen ved DOM er, at klient-applikationen ikke skal hverken parse eller tolke strukturen i dokumentet, men kan operere på dokumentet som en træstruktur. Ulempen er, at det er DOM-implementationen, der afgør, hvilket data, der skal holdes i arbejdshukommelsen hvilket for en del DOM-implementationer betyder at hele dokumentet holdes i arbejdshukommelsen. 2.1.2 XOP Binær data kan ikke direkte indlejres i et XML-dokument, men skal først kodes som karakterdata eksempelvis i form af base64 kodning [11, 33]. En sådan kodning får data til at fylde mere og er endvidere tidskrævende. XOP (XML-binary Optimized Packaging) er en metode til at serialisere XML med binær data uden brug af base64-kodning [12]. I stedet for at placere det base64-kodede binære data i dokumentet, indsættes i stedet et xop:include-element, der indeholder en reference til det binære data. Dermed separeres det binære data fra XML-dokumentet. Det transformerede XML-dokument og de binære datablokke kan derefter serialiseres som separate dele i et pakke-format. Side 10 af 169

2 BAGGRUNDSMATERIALE Når dokumentet skal læses, kan en generisk XML-parser bruges på det transformerede dokument. De binære dele kan derefter læses efter behov af applikationen, uden først at skulle konvertere dem fra base64. 2.2 Document Value Model og XML Store XML Store er et applikationskonfigurerbart, distribueret, mobilt persistenslag til opbevaring af semi-strukturerede data (XML-dokumenter i særdelelshed) baseret på en værdiorienteret dokumentmodel og grænseflade. XML Store implementerer DVM (Document Value Model) API et, der er en værdiorienteret DOM-lignende grænseflade. Dette afsnit indeholder en kort gennemgang af værdiorienteret programmering, DVM og XML Store. En komplet gennemgang af DVM og XML Store kan findes i [23]. 2.2.1 Værdiorienteret programmering I værdiorienteret programmering kan værdier ikke opdateres. Man kan binde en værdi til et navn, men man kan ikke opdatere værdien, som man kan i imperative sprog. I SML-syntaks bindes en værdi f. eks. således: 1 - val x = [5]; 2 val x = [5] : int list Figur 4: Binding i ML Hvis listen x opdateres ved at tilføje et element, vil en ny liste blive oprettet og efterlade den gamle uændret. Referencen til værdien bliver igen bundet til x, og denne binding overskygger den gamle, der altså stadig eksisterer: 1 - val x = 42 :: x; 2 val x = [42,5] : int list Figur 5: Opdatering i ML Det er altså muligt at konstruere nye værdier ud fra andre værdier. Bindinger til navne kan altså også ændres, men værdier kan ikke ændres, som det fremgår af følgende eksempel: 1 - val y = 3 :: x; 2 val y = [3, 42, 5] : int list 3 - val x = [0]; 4 val x = [0] : int list 5 y; 6 val it = [3, 42, 5] : int list Figur 6: Værdier er ikke-muterbare Værdiorienterede modeller er attraktive i netværkssammenhænge som for eksempel XML Store. Da en værdi ikke kan ændres destruktivt, er der ikke behov for en transaktionsprotokol til netværket. Der er altså er ingen overensstemmelsesproblemer ved caching, da opdaterede værdier gemmes som nye værdier og værdier ikke bliver slettet. Side 11 af 169

2 BAGGRUNDSMATERIALE 2.2.2 DVM DVM er en træorienteret, værdiorienteret grænseflade, specielt designet til XML Store. DVM minder om DOM, men adskiller sig ved at være værdiorienteret og understøtter dermed, i modsætning til DOM, ikke destruktive opdateringer 2. Knuder er de centrale elementer i DVM. Hele dokumentet repræsenteres ved en enkelt knude, rodknuden, og undertræerne (rodens børn) repræsenteres ligeledes som knuder. En knude har et navn, en mængde attributter samt en sæt børn. Navigation i strukturen foregår ved at følge en reference fra en knude til et af dens børn. En blok ustruktureret data repræsenteres i DVM i form af en knude, der hverken har attributter eller børn, men kun en strengværdi. Ustruktureret data er således en atomisk enhed i DVM. 2.2.3 XML Store XML Store implementerer DVM og håndterer persistens og distribution. Det har en lagdelt arkitektur der består af DVM laget, disklaget, foruden navne-service og referenceservice. Disklaget håndterer indlæsning og skrivning til pladelageret og håndterer også referenceservice, der bruges når der skrives og læses. Referenceservicen er basalt set en hashtabel, der oversætter fra nøgle til data. DVM-laget håndterer navneservices, der bruges til at finde de symbolske navne. XML Store benytter Multiset discrimination (se [5]) til at identificere identiske værdier og erstatter dem med en enkelt, delt instans. F.eks. vil undertræ c kun blive gemt én gang, hvis følende dokumenter gemmes i XML Store: 1 <doc1 > <doc2 > 2 <a>foo </a> <a>bar </a> 3 <c> <c> 4 <b>c1 <b>c1 5 </b> </b> 6 <d>c2 <d>c2 7 </d> </d> 8 </c> </c> 9 </ doc1 > </ doc2 > Figur 7: Dokumenter med fælles undertræ Træstukturen for XML-dokumenterne i figur 7 kan ses i figur 8 2.3 Kompression Der findes et utal af metoder til datakompression. Disse metoder kan grundlæggende inddeles i to grupper: tabsfri og ikke-tabsfri. Omend ikke-tabsfri kompression har mange 2 DVM har faktisk mulighed for opdateringer i form af de såkaldte Mutable nodes. Vi udelader dem i vores fremstilling, da vi ikke vil håndtere dem i vores metode. Side 12 af 169

2 BAGGRUNDSMATERIALE doc2 doc1 a a c bar foo b d (a) doc2 C1 (b) doc1 C2 Figur 8: Delte undertræer anvendelser især kan nævnes komprimering af billeder og lyd vil vi kun fokusere på de tabsfri metoder. Motiverne for datakompression kan være meget forskellige begrundelserne for at anvende datakompression i XML Store, er følgende: pladelageret udnyttes bedre. mindre data skal overføres fra pladelageret til arbejdshukommelsen. mindre data skal overføres mellem peers i et distribueret XML Store. Omkostningen ved at anvende komprimering, er at centralenheden skal foretage flere beregninger, men ikke så mange at den tidsmæssige fordel ved at skulle flytte mindre datamængder opvejes. Man er derfor ofte villig til at acceptere denne omkostning. I dette afsnit vil vi se på en række kompressionsbegreber og -metoder, som vi vil referere til i beskrivelsen af vores metode. Statisk og adaptiv kompression Ved statisk kompression anvendes en statisk model til at kode alt inddata. Ofte vil man udlede modellen ved at analysere det samlede inddata, men man kan også anvende en model, der er fastlagt på forhånd den pågældende model skal blot være kendt ved dekompression. Det er ofte muligt specielt ved statisk ordbogskompression at dekode vilkårlige delmængder af statisk kodet data. I modsætning hertil er adaptiv kompression, hvor modellen ændrer sig løbende mens data kodes. Dekompression af adaptivt kodet data, kræver at der dekomprimeres fra begyndelsen, da dekoderen skal kunne udlede, hvordan modellen har ændret sig. Ordbogskompression Ordbogskompression er en betegnelse for metoder, hvor en række symboler, et ord, kodes med et enkelt symbol. Datastrukturen, der indeholder ordene og de tilsvarende koder, kaldes en ordbog deraf navnet ordbogskompression. Ordbogskompression findes i både statiske og adaptive udgaver. Vi vil i de følgende to afsnit se på tre af de mest udbredte ordbogskompressionsmetoder. Side 13 af 169

2 BAGGRUNDSMATERIALE 2.3.1 LZ77 og LZ78 Lempel og Ziv introducerede i slutningen af 70 erne LZ77 og LZ78 algoritmerne, der har været grundstenen i mange efterfølgende algoritmer (f.eks. LZW) og værktøjer (f. eks. gzip) [41, 42]. Begge algoritmer er ordbogsbaserede og adaptive. De benytter sig af at gemme bagudreferencer til strenge der tidligere er set i det originale dokument (enten som indeks eller som offset). I LZ77 gemmes f.eks. et vindue af det data der senest er læst. Når nye karakterer læses, finder kompressoren den længste fælles understreng (eng. substring) i vinduet, og skriver en bagudreference, hvis understrengen er set før. Betragt f.eks. følgende streng: 1 A B C D B C D E Figur 9: Streng med gentagelser Når det andet B læses, finder algoritmen at understrengen B C D findes i vinduet og erstatter den med en bagudreference af formen (-offset, længde): 1 A B C D ( -3,3) E Figur 10: Streng med bagudreference Desuden har LZ77 den vigtige egenskab, at periodiske sekvenser kan komprimeres meget effektivt. F. eks bliver 1 A B C D B C D B C D B C D E komprimeret til 1 A B C D ( -3,9) E Figur 11: Streng med periodisk sekvens Figur 12: Streng periodisk sekvens erstattet af bagudreference 2.3.2 Huffman-kodning Huffman-kodning er en anden ordbogskompressionsmetode, der findes i såvel en statisk som en adaptiv variant. Vi vil her beskrive den statiske variant. Huffman-kodning er centralt i vores metode, og vi vil derfor gå i dybden med metoden. I modsætning til LZ77/78 metoderne, kodes hvert enkelt symbol i inddata med én kode ved Huffman-kodning. Kompression opnås ved at anvende korte koder for hyppigt forekommende symboler og længere koder til sjældnere symboler. Huffman konstruerede en grådig algoritme til beregning af disse såkaldte Huffman-koder [14]. Metoden opbygger et binært træ, hvor symbolerne udgør bladene. Sjældne symboler placeres dybt i træet og hyppigere symboler placeres tættere ved roden. Huffman-koden for et givet symbol findes herefter ved at følge kanterne fra roden til symbolet og tilføje et 0 eller 1 til koden hver gang en venstre- henholdsvis højrekant følges (eller omvendt). De vigtige egenskaber ved det opbyggede træ er: Side 14 af 169

2 BAGGRUNDSMATERIALE 1. at det resulterer i præfikskoder: ingen kode er et præfiks af en anden. Dette gør dekodning simpel, da man blot kan læse bits fra starten og utvetydigt kan afgøre hvornår en kode er læst. 2. at kodelængderne er optimale i følgende betydning: kodelængderne er optimale, i den forstand, at ingen anden direkte afbildning af inddatasymboler til unikke, binære strenge, kan producere et mindre uddata for et inddatasæt, hvor fordelingen af symbolerne er den samme som den, der blev brugt til konstruktion af træet [14] I det følgende vil vi bruge optimal i denne betydning. Kanoniske Huffman-koder Hvilket symbol, der kodes med hvilken kode er ikke væsentligt for kompressionsratioen, der alene bestemmes af kodelængderne. Vi kan således ombytte blade og knuder der har samme afstand til rodknuden, uden at kodernes præfiksegenskaber og længder ændres. Vi udnytter denne frihed til at konstruere kanoniske koder, der opfylder følgende to regler: 1. en kode H a, der er kortere end anden kode H b, skal have en mindre numerisk værdi: H a < H b. 2. for to symboler, a og b, hvis koder, H a og H b, har samme længde, skal der gælde at det symbol der kommer først i den alfabetiske ordning (her a), skal have en kode med en mindre numerisk værdi: H a < H b. Den alfabetiske ordning kan vælges vilkårligt, så længe dekompressoren kender denne ordning. Disse regler fastlægger entydigt koderne og dermed det binære træ for et givet alfabet og en given fordeling [9]. Det er muligt at fastlægge andre regler, der ligeledes entydigt fastlægger koderne, men de valgte regler har nogle egenskaber, som vi senere vil benytte. Der er i RFC 1951 [9, pp 7] angivet en algoritme, der givet at kodelængderne er kendt i lineær tid og plads i antallet af symboler, kan tildele koder ud fra ovenstående kanon 3 : Vi lader S n betegne sættet af symboler, der skal kodes med længden n. Symbolerne i hvert sæt nummereres fortløbende fra nul i alfabetisk rækkefølge. Vi lader kodelængden være første indeks og det fortløbende nummer være andet indeks det tredje symbol med længden fem betegnes således s 5,2. 3 Algoritmen er i RFC 1951 givet i form af pseudo-kode. Vi har valgt at bruge ovenstående fortolkning for at kunne indføre en kompakt notation. Side 15 af 169

2 BAGGRUNDSMATERIALE Det første symbol i hvert sæt tildeles koden H n,0, hvor den numeriske værdi af H n,0 er givet ved rekursionen H 0,0 = 0 og H n+1,0 = ( H n,0 + S n ) 2. De efterfølgende symboler i hvert sæt S n tildeles koder med fortløbende numeriske værdier: H n,i = H n,i 1 + 1 for 0 < i < S n. De optimale kodelængder kan findes ved hjælp af Moffat og Katajainens algoritme, der beregner kodelængderne i lineær tid i antallet af symboler n og in-place med et konstant ekstra hukommelsesforbug [18]. Algoritmen forudsætter dog at symbolerne er sorteret efter frekvens. Da sortering mindst har en tidskompleksitet på O(n lg n), vil sorteringen asymptotisk dominere de to andre (lineære) trin og kompleksiteten for konstruktionen af de optimale koder er derfor O(n log n). Hukommelsesforbruget for konstruktionen af koderne er O(n). Genskabelse af kodebogen Ved statisk Huffman-kodning kodes alle symboler i en given besked med den samme kodebog. For at dekode beskeden, skal kodebogen være kendt og den skal derfor enten transmitteres sammen med beskeden eller være kendt på forhånd af modtageren. Sidstnævnte er en fordel, hvis alfabetet er kendt på forhånd og beskederne der udveksles har en kendt fordeling, da man sparer omkostningen ved at transmittere en kodebog med hver besked. Til vores brug er alfabetet dog ikke kendt på forhånd hvorfor vi er nødt til at konstruere og gemme en kodebog til hver besked. Vi vil i det følgende afsnit gennemgå en metode til dette. En af egenskaberne ved kanoniske Huffman-koder er, at det er ikke er nødvendigt at genskabe hver enkelt kode, for at kunne læse en kodet besked. Når man kender symbolerne, deres alfabetiske ordning samt længden af deres koder, kan sættene S n og koderne H n,0 konstrueres ved at bruge ovenstående definitioner. I det følgende vises det at dette er nok til at læse en kodet besked. Hvis hvert sæt S n repræsenteres ved en nul-indekseret tabel, vil positionen for et symbol s n,i S n i tabellen være i. Da symbolerne i S n har fået tildelt koder med numerisk fortløbende værdier, startende med H n,0, gælder endvidere i = H n,i H n,0. Hvis vi således har givet en kode H n,j, kan det tilsvarende symbol findes ved at bruge differensen H n,j H n,0 som indeks i S n. Men hvordan afgøres det hvad længden af det næste symbol er? Vi bemærker følgende egenskab: en kode H a, der er længere end en anden kode H b, vil have en numerisk værdi, der er mere end dobbelt så stor: H a > H b 2. Dette ses af den rekursion, der definerer den numerisk mindste kode for hver længde samt udtrykket for den numeriske værdi af koden for det sidste symbol i S n, H n, Sn 1 = H n,0 + S n 1: H n+1,0 = ( H n,0 + S n ) 2 H n+1,0 > ( H n,0 + S n 1) 2 = H n, Sn 1 2 Vi kan bruge denne egenskab til at finde længden af den næste kode som følger: Side 16 af 169

2 BAGGRUNDSMATERIALE 1. betegn de næste n bits, der endnu ikke er tolket, med H n. Initialiser i til den største kodelængde, n max. 2. hvis H i H i,0, så er kodelængden i of vi er færdige. 3. dekrementer i og gentag punkt 2. På grund af kodernes præfiksegenskab, kan sammenligningen i punkt 2, ændres til H n max H i,0 2 nmax i. Vi kan dermed undgå at skulle udregne H i ved hver iteration og værdierne H i,0 2 nmax i skal kun udregnes én gang for hver kodebog. 2.4 XML kompression De XML specifikke kompressorer vi er bekendt med er: XMill [20], XGrind [25], SCM [3] og Multiplexed Hierachical Modelling (MHM) [7], der er baseret på Prediction by Partial Match (PPM) de er alle resultater af forskningsprojekter og er beskrevet i videnskabelige artikler. Af kommercielle produkter er vi bekendt med XML-Xpress (XXP) [38] og dbxml. I dette afsnit introduceres kort de forskellige ikke-kommercielle projekter. XMill projektet er centralt for ideen til denne opgave og får derfor en mere fyldestgørende præsentation. XMill er en XML-specifik kompressor, designet af Liefke og Suciu. XMill kan kan komprimere store XML-dokumenter til under 20 % af deres originale størrelse. Den høje kompressionsratio opnås ved at adskille struktur fra data og behandle dem hver for sig. I strukturen erstattes alle XML-tags med heltal, hvorefter de komprimeres med gzip, der meget effektivt kan komprimere sådanne strukturer. Relateret data grupperes i containere (baseret på deres tag-navn) og så komprimeres hver container for sig, med en kompressor (evt. flere) der kan være specialiseret til den pågældende container. Brugen af specialiserede kompressorer i XMill er ikke automatiseret, men skal angives af brugeren. I de tilfælde hvor brugeren ikke angiver, hvorledes de enkelte containere skal komprimeres, anvender XMill zlib biblioteket, der kombinerer Ziv-Lempel kompression (LZ77) med en variant af Huffmankodning [9]. XMill projektet fokuserer på maksimal kompression af XML-dokumenter, for at minimere båndbredde behovet ved transmission og pladsforbruget på pladelagereret ved arkivering. XMill projektets løsning understøtter ikke navigation af den komprimerede struktur og dermed heller ikke forespørgsler direkte på det komprimerede dokument - for at udføre disse operationer er det nødvendigt at dekomprimere hele dokumentet. XGrind en XML-specifik kompressor, designet af Tolani og Haritsa. XGrind opnår ikke en kompressionsratio, der er er lige så god som XMill, men understøtter i modsætning til XMill visse forespørgsler direkte over det komprimerede dokument. XGrind bevarer strukturen fra det originale dokument, hvilket giver mulighed for at benytte almindelige XML teknologier til at afvikle forespørgsler på det komprimerede dokument. Dette betyder bl.a. at man kan indeksere filen. Tags og attributter kodes effektivt, og Side 17 af 169

2 BAGGRUNDSMATERIALE data komprimeres med en ikke-adaptiv Huffman kodning, der muliggør opslag. Strukturen udnyttes ikke som i XMill, til at kode forskellige datatyper sammen. SCM er en XML-specifik kompressor, designet af Adiego, Navarro og Fuente. SCM udnytter på samme måde som XMill strukturen til kode data under identiske tags sammen. I modsætning til XMill introducerer SCM dog en heuristik, der kan kombinere ordbøger for tags der har sammenfaldende fordeling, hvilket reducerer det samlede pladsforbrug væsentligt. SCM bevarer som XGrind strukturen fra det originale dokument. Kompression af både struktur og data sker med ordbaseret Huffman-kodning, hvor tags (incl <, > og />), betragtes som ord. Tags bruges til at afgøre hvilken ordbog der skal benyttes når der komprimeres og dekomprimeres. Da SCM benytter ordbaseret Huffman-kodning, understøttes visse forespørgsler direkte over det komprimerede dokument. SCM opnår en kompression der er bedre en XMill og - for store dokumenter - tilnærmelsesvis så god som MHM [3]. Multiplexed Hierachical Modelling (MHM) er en XML-specifik kompressor designet af Cheney. MHM er en statistisk kompressor, der benytter konteksten, givet af stien fra rodknuden til den aktuelle knude, til at bestemme sandsynligheden for den efterfølgende karakter. MHM er en adaptiv metode, hvorfor det ikke er muligt at foretage opslag i det komprimerede dokument. MHM opnår den bedste komprimering, af de XML-specifikke kompressorer vi har fundet (givet at XMill ikke af brugeren tweakes til det aktuelle dokument). Side 18 af 169

3 KOMPRIMERET OG NAVIGERBAR SERIALISERING AF XML 3 Komprimeret og navigerbar serialisering af XML De tidligere omtalte XML-kompressorer, er designet ud fra forskellige målsætninger: XMill er designet med henblik på arkivering og deres vigtigste mål har været at komprimere inddata mest muligt omend de også har et stort fokus på hastigheden af applikationen [20]. XGrind er designet med henblik på effektive forespørgsler (eng. queries) [25]. Vores motivation er en anden, nemlig at designe en komprimeret serialisering af XML, der kan bruges af XMLStore. XMLStore giver adgang til data via ovennævnte DVMgrænseflade, der præsenterer data til klienten som en træstruktur. Dvs. at det serialiserede format skal facilitere navigation i strukturen og helst uden at det forudsætter at hele dokumentet læses. Vi vil i det følgende afsnit konkretisere målsætningerne for metoden og formatet. 3.1 Designmål Vores designmål for det serialiserede format kan kort opsummeres i følgende to delmål: formatet skal være så kompakt som muligt formatet skal kunne navigeres uden forudgående deserialisering Disse målsætninger er desværre ikke altid forenelige. Et eksempel er bzip2, hvor en god kompressionsratio opnås ved at sortere data inden komprimering [24, 6]. Dette medfører dog, at man ikke kan læse en delmængde af data uden at dekomprimere hele den komprimerede blok og invertere sorteringen. Omkostningerne ved sådanne kompromiser kan være svære om ikke umulige at k- vantificere under udviklingen af en metode. Vi vil derfor ikke forsøge at udlede eksakte omkostninger i tid/plads, men derimod overordnet klarlægge naturen af sådanne kompromiser. 3.1.1 Begrænsninger Der er række relevante designparametre, som vi har måtte se bort fra for at begrænse omfanget af opgaven: Hukommelsesforbrug Vi vil i designet af metoden, ikke undersøge metoder til at sætte en øvre grænse for hukommelsesforbruget f.eks. ved opdeling og behandling af inddata i mindre blokke. Vi forudsætter således, at der er tilstrækkelig arbejdshukommelse til rådighed, til at hele inddata-dokumentet kan behandles samlet med vores metode. Opdateringer En anden begrænsning er, at vi ikke vil undersøge hvordan det serialiserede format kan opdateres og ikke forsøge at facilitere opdateringer i designet af metoden. Dette er en begrænsning ift. understøttelsen af DVM, hvori der er mulighed for at lade nogle knuder være opdaterbare de såkaldte mutable nodes. Side 19 af 169

3 KOMPRIMERET OG NAVIGERBAR SERIALISERING AF XML DTD og XMLSchema Et XML-dokument, der er i overensstemmelse med en DTD [11] eller et XML Schema [31], kan opfattes som en instans af den klasse af dokumenter som DTD en eller XML Schema et definerer. Der er en række muligheder for at udnytte dette til at komprimere dokumentet for eksempel udnytter XGrind DTD-information om attributter: hvis en attribut kun har et begrænset antal mulige værdier, nummereres disse og numrene bruges i det komprimerede format i stedet for de faktiske værdier [25]. Hvordan man kompakt kan beskrive en instans af en DTD eller et XML Schema er et interessant emne, men også et emne, der ligger langt ud over denne opgaves rammer. Vi vil således ikke udnytte DTD er og XML Schema er i vores metode. 3.1.2 Navigation Et af vores designmål er at kunne navigere uden forudgående deserialisering. Navigation er bredt begreb og vi er derfor nødt til at præcisere, i hvilken betydning vi anvender begrebet i denne opgave. DVM-modellen er en træmodel, hvor man, givet en knude, kan følge en vilkårlig kant til et af dens børn. I et serialiseret format kan alle børnene ikke komme lige efter forælderen og der skal derfor være en metode til at finde det pågældende barn. En mulighed er at placere børnene efter hinanden adskilt af markører og så scanne til det pågældende barn. Denne scanning kræver at de børn, der ikke skal bruges, alligevel skal indlæses, hvilket vil kræve forholdsvis langsomme diskoperationer. En anden mulighed er at efterligne træmodellen, ved at gemme kanterne som adresser i det serialiserede format. Dermed kan der søges direkte til det relevante barn. Pladelageret vil stadig skulle søge, men mellemliggende data skal ikke overføres og tolkes, så markører kan detekteres. 3.1.3 Round-tripping Begrebet round-tripping bruges i XML-litteratur til at beskrive den information, der bevares når et XML-dokument konverteres til et andet format og tilbage igen. Der findes flere round-tripping-niveauer: på højeste niveau bevares hele XML-dokumentet uden ændringer; på lavere niveauer mistes information, som f.eks. rækkefølgen af et elements børn eller kommentarer. Round-tripping-niveauet for vores metode skal mindst være det samme som det XLM- Store tilbyder. Endvidere vil det ikke have mening at have et højere round-tripping niveau, da den ekstra information ikke vil være tilgængelig via XMLStore. XMLStore round-tripping bevarer ikke følgende information 4 : [32] rækkefølgen af attributter kommentarer 4 XMLStore s round-tripping niveau, er undersøgt ved at studere kildekoden til Koala XMLStore 0.5.4 Side 20 af 169