Slika 3. Velike datoteke XML. Kliknite sličico za ogled slike v polni velikosti.
Osem let od svoje ustanovitve se je XML že začel uporabljati kot odprt, polstrukturiran format podatkov za shranjevanje podatkov in izmenjavo podatkov po spletu. Zaradi svoje enostavnosti in človeške berljivosti je XML med razvijalci aplikacij videl svojo priljubljenost in postal nepogrešljiv del poslovne arhitekture.
Čeprav je težko našteti, na kakšen način se XML uporablja, je vseeno gotovo eno: XML je treba razčleniti, preden je še kaj mogoče storiti. Pravzaprav je izbira pravega razčlenjevalnika pogosto ena prvih odločitev, ki se jih morajo razvijalci podjetij lotiti v svojih projektih. In vedno znova se ta odločitev nanaša na dva priljubljena modela obdelave XML: objektni model dokumenta (DOM) in enostavni API za XML (SAX).
Na prvi pogled se zdijo močne in šibke točke DOM in SAX komplementarne: DOM gradi grafe objektov v pomnilniku; SAX temelji na dogodkih in v pomnilnik ne shrani ničesar. Če je velikost dokumenta majhna in je vzorec dostopa do podatkov zapleten, je DOM prava pot; v nasprotnem primeru uporabite SAX.
Resnica pa nikoli ni tako poenostavljena. Razvijalci pogosteje ne želijo uporabljati SAX-a zaradi njegove zapletenosti, vendar še vedno, ker ni na voljo nobene druge izvedljive izbire. V nasprotnem primeru, če je velikost datoteke XML le nekoliko večja od nekaj sto kilobajtov, DOM-ov režijski pomnilnik in vlečenje zmogljivosti postaneta močna ovira za razvijalce aplikacij, ki jim preprečuje, da bi izpolnili minimalne cilje glede učinkovitosti svojih projektov.
Toda ali je SAX res toliko boljši? Oglašena uspešnost razčlenjevanja SAX - običajno nekajkrat hitrejša od DOM - je pravzaprav pogosto zavajajoča. Izkazalo se je, da nerodna narava razčlenjevanja SAX ne zahteva le dodatnih naporov pri izvedbi, temveč tudi kaznuje učinkovitost, ko struktura dokumenta postane le nekoliko zapletena. Če se razvijalci odločijo, da dokumenta večkrat ne bodo optično prebrali, bodo morali dokument medpomniti ali zgraditi objektne modele po meri.
Kakor koli že, zmogljivost trpi, kot ponazarja Apache Axis. Na svoji strani s pogostimi vprašanji Axis trdi, da interno uporablja SAX za ustvarjanje zmogljivejše izvedbe, vendar še vedno gradi svoj objektni model, ki je precej DOM-ov, kar ima za posledico zanemarljive izboljšave v primerjavi s predhodnikom (Apache SOAP). Poleg tega SAX ne deluje dobro s XPathom in na splošno ne more voditi obdelave XSLT (Extensible Stylesheet Language Transformation). Torej SAX razčlenjevanje prekriva resnične težave pri obdelavi XML.
V iskanju enostavnejše alternative za SAX se je vedno več razvijalcev obrnilo na StAX (Streaming API za XML). V primerjavi s SAX razčlenjevalniki StAX vlečejo žetone iz datotek XML, namesto da bi uporabljali povratne klice. Čeprav opazno izboljšajo uporabnost, ključna vprašanja še vedno obstajajo - StAX-ov samo razčlenjeni slog razčlenjevanja še vedno zahteva dolgočasno izvajanje in skupaj s tem tudi skrite stroške delovanja.
Bottom line: Da bi bil kateri koli model obdelave XML splošno uporaben, mora predstavljati hierarhično strukturo XML in nič manj. Razlog je v tem, da je XML zasnovan za premikanje zapletenih podatkov po spletu, posredovanje strukturnih informacij pa je sestavni del tega, kar počne XML.
VTD-XML spremeni igro
Recimo, da bi morali XML obdelavo začeti od začetka, da bi premagali zgoraj omenjene težave z DOM in SAX. Verjetno bi moral imeti novi model naslednje lastnosti:
- Možnost naključnega dostopa: Model obdelave bi moral razvijalcu omogočiti krmarjenje po nekakšni hierarhični strukturi bodisi ročno ali, bolje, s pomočjo XPath.
- Visokozmogljivo: Zmogljivost bi morala biti bistveno boljša od DOM in SAX. Uspešnost mora biti "poštena", kar pomeni, da mora meritev vključevati čas, porabljen za izgradnjo hierarhične strukture.
- Majhna poraba pomnilnika: Če želite model obdelave uporabiti za širok spekter scenarijev in velikosti datotek, mora predstavljati celotno strukturo XML z minimalno količino pomnilnika.
VTD-XML, zasnovan za izpolnitev teh ciljev, je odprtokodni model obdelave XML naslednje generacije, ki prinaša temeljne in vsestranske izboljšave v primerjavi z DOM in SAX. Ena ključnih optimizacij VTD-XML je neeraktivna tokenizacija. VTD-XML interno ohrani v pomnilniku nepoškodovano in nekodirano sporočilo XML in predstavlja žetone, ki temeljijo izključno na specifikaciji binarnega kodiranja, imenovani Virtualno Token Deskriptor. Zapis VTD je 64-bitno celo število, ki kodira dolžino žetona, začetni odmik, vrsto in globino gnezdenja žetona v XML.
Tukaj je nekaj zgodovine VTD-XML, če vas zanima: Osnovni koncept je bil zasnovan kot način za prenos XML obdelave na namensko strojno opremo v obliki FPGA ali ASIC, da se omogoči omrežna stikala in usmerjevalniki za obdelavo XML vsebine pri zelo visokih hitrostih. Kasneje se je projektna skupina VTD-XML odločila, da bo odprtokodno odprla VTD-XML, in začetna izdaja - različice 0.5, ki je bila implementirana v Javi - je bila izvedena maja 2004. Od izdaje je VTD-XML že več krogov izboljšav precej. V različici 0.8 je bila izdana C različica VTD-XML skupaj z različico Java. Vgrajena podpora za XPath je bila uvedena v različici 1.0 in izdana oktobra 2005. Zadnja izdaja, različica 1.5, vsebuje prepisan mehanizem za razčlenjevanje, ki je bolj modularen in zmogljivejši.
V tej izdaji je predstavljena tudi funkcija, imenovana ponovna uporaba vmesnega pomnilnika. Osnovna ideja je, da kadar mora aplikacija XML, ki sedi za omrežno povezavo, večkrat obdelati številne dohodne dokumente XML, lahko aplikacija dejansko ponovno uporabi pomnilniške pomnilnike, dodeljene med prvim zagonom obdelave. Z drugimi besedami, enkrat določite odbojnike in jih uporabite veliko, večkrat. Ta značilnost, značilna za VTD-XML, omogoča popolno odpravo ustvarjanja predmetov in stroškov odvoza smeti (50-80 odstotkov režijskih stroškov v DOM in SAX) iz obdelave XML. Spletno mesto projekta vsebuje najnovejše prenose programske opreme in poglobljen tehnični opis VTD-XML.
Hiter primer
Da bi dobili občutek programskega sloga VTD-XML, ta članek najprej primerja kodo z uporabo VTD-XML in DOM za razčlenitev in krmarjenje po preprosti datoteki XML z imenom test.xml, katere besedilna vsebina je prikazana spodaj:
Kosilnica 1 148,95 Različica VTD-XML je videti tako:
uvoz com.ximpleware. *; uvoz com.ximpleware.parser. *; uvoz java.io. *;
javni razred use_vtd {public static void main (String [] args) {try {Datoteka f = nova datoteka ("test.xml"); FileInputStream fis = novo FileInputStream (f); bajt [] ba = nov bajt [(int) f.length ()]; fis.read (ba); VTDGen vg = nov VTDGen (); vg.setDoc (ba); vg.parse (napačno); VTDNav vn = vg.getNav (); if (vn.matchElement ("orderOrder")) {System.out.println ("orderDate ==>" + vn.toString (vn.getAttrVal ("orderDate"))); if (vn.toElement (VTDNav.FIRST_CHILD, "item")) {if (vn.toElement (VTDNav.FIRST_CHILD)) {do {System.out.print (vn.toString (vn.getCurrentIndex ())); System.out.print ("==>");
System.out.println (vn.toString (vn.getText ())); } while (vn.toElement (VTDNav.NEXT_SIBLING)); }}}} catch (izjema e) {System.out.println ("prišlo je do izjeme ==>" + e); }}}
Različica DOM iste aplikacije je prikazana spodaj:
uvoz java.io. *; uvoz org.w3c.dom. *; uvoz org.w3c. *; uvozi javax.xml.parsers. *; uvoz javax.xml.parsers.DocumentBuilder; uvoz javax.xml.parsers.DocumentBuilderFactory; uvoz javax.xml.parsers.FactoryConfigurationError; uvoz javax.xml.parsers.ParserConfigurationException; uvoz org.w3c.dom. *; uvoz org.xml.sax.SAXException;
javni razred use_dom {public static void main (String [] args) {try {DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance (); Razčlenjevalnik dokumentovBuilder = factory.newDocumentBuilder (); Dokument d = razčlenjevalnik.parse ("test.xml"); Koren elementa = d.getDocumentElement (); if (root.getNodeName (). compareTo ("purchaseOrder") == 0) {System.out.println ("orderDate ==>" + root.getAttribute ("orderDate"));
Vozlišče n = root.getFirstChild (); if (n! = null) {do {if (n.getNodeType () == Node.ELEMENT_NODE && n.getNodeName (). compareTo ("item") == 0) {Node n2 = n.getFirstChild (); if (n2! = null) {do {if (n2.getNodeType () == Node.ELEMENT_NODE) {System.out.println (n2.getNodeName () + "==>" + n2.getFirstChild (). getNodeValue ( )); }} while ((n2 = n2.getNextSibling ())! = null); }}} while ((n = n.getNextSibling ())! = null); }}} catch (izjema e) {System.out.println ("prišlo je do izjeme ==>" + e); }}}
Kot je prikazano v zgornjih primerih kode, VTD-XML krmili po hierarhiji XML s pomočjo API-ja, ki temelji na kazalcu. V nasprotju s tem API DOM krmili po hierarhiji tako, da zahteva sklice na objekt. Obiščite spletno mesto projekta VTD-XML, kjer boste našli več tehničnih materialov in primerov kode, ki podrobno razlagajo VTD-XML.
Primerjalna analiza VTD-XML
Nato primerjajmo delovanje in uporabo pomnilnika VTD-XML z nekaterimi priljubljenimi razčlenjevalniki XML. Treba je opozoriti, da je večina člankov, ki vsebujejo primerjalne številke, na primer "XML Documents on the Run" avtorja Dennisa Sosnoskega (JavaWorld, April 2002), so izpred nekaj let. Od takrat boljša in hitrejša strojna oprema sledi Moorejevemu zakonu in postaja cenejša kot kdaj koli prej. Hkrati razčlenjevanje XML in navidezni stroj Java ne stojita na več ključnih področjih.
Preskusna nastavitev
Testna platforma je prenosnik Sony VAIO, opremljen s procesorjem Pentium M 1,7 GHz (2 MB vgrajenega predpomnilnika L2) in 512 MB DDR2 RAM-a. Sprednja vodila je na frekvenci 400 MHz. Operacijski sistem je Windows XP Professional Edition s servisnim paketom 2. JVM je različice 1.5.0_06.
Primerjalno merilo preizkuša najnovejše različice naslednjih razčlenjevalnikov XML:
- Xerces DOM 2.7.1, z odloženo razširitvijo vozlišča in brez nje
- Xerces SAX 2.7.1
- Piccolo SAX 1.04
- XPP3 1.1.3.4.O
- VTD-XML 1.5, z in brez ponovne uporabe medpomnilnika
Za test sem izbral veliko zbirko dokumentov XML različnih velikosti in strukturne zapletenosti. Odvisno od velikosti datoteke so testni dokumenti razvrščeni v tri kategorije. Majhne datoteke so manjše od 10 KB. Datoteke srednje velikosti so med 10 KB in 1 MB. Datoteke, večje od 1 MB, se štejejo za velike.
Strežnik JVM je bil uporabljen za vse meritve zmogljivosti za doseganje najvišje zmogljivosti. V teh preizkusih so primerjalni programi večkrat prvič pregledali rutino razčlenjevanja ali krmarjenja, tako da je JVM izvedel dinamično, pravočasno optimizacijo bajtne kode, preden je povprečne rezultate naslednjih ponovitev kot povprečne rezultate. Da bi zmanjšali časovne razlike zaradi vhoda / izhoda diska, primerjalni programi pred preskusnimi preizkusi preberejo vse datoteke XML v vmesne pomnilnike.
Opomba: Zainteresirani bralci lahko primerjalni program prenesejo iz virov.
Razčlenitev primerjav pretovora
V tem razdelku je predstavljena zmogljivost razčlenjevanja XML tako v zakasnitvi kot v pretočnosti. Upoštevajte, da čeprav sta VTD-XML in DOM neposredno primerljiva, ni pravično primerjati VTD-XML s SAX ali Pull, ker v spominu ne gradijo nobene hierarhične strukture. Tako zmogljivost za SAX in Pull služi le kot dodatna referenčna točka.
Pretočnost
Primerjave latenc
Tabela 1. Majhne datoteke
|
Tabela 2. Srednje datoteke XML
