Hlavní navigace

Akta X: Přichází doba optimalizací?

Petr Cimprich 25. 4. 2007

Základní sada standardů XML je víceméně kompletní. Bude nyní věnováno více pozornosti jejich efektivitě a praktické použitelnosti, která v mnoha případech pokulhává? Určité náznaky tohoto směru vývoje se poslední dobou objevují stále častěji. A optimalizace jsou často opravdu nutné.

Možná je to jen můj dojem, možná je přání otcem myšlenky, ale zdá se mi, že se poslední dobou tvůrci a uživatelé technologií XML stále více zabývají jejich efektivitou. Specifikace, kterých zatím přibývalo jak hub po dešti, už pokrývají všechny hlavní oblasti. U některých byla dokončena druhá, podstatně sofistikovanější a komplexnější generace. Už není moc kam košatět ani spěchat. To je vhodná doba k tomu začít se zajímat o praktickou použitelnost nových technologií. Už jsou dostatečně zralé pro optimalizace.

A optimalizace jsou často opravdu nutné. Při přímočaré implementaci některé složitější posloupnosti operací trvají neúnosně dlouho a s rostoucí velikostí dokumentů se tyto potíže kriticky zhoršují. Příkladem komplexního zpracování může být třeba ověření digitálního podpisu zprávy SOAP. To při standardní doporučené implementaci obnáší parsování dokumentu XML a vytvoření jeho reprezentace v paměti, vyhodnocení výrazu XPath, serializaci výsledné sady uzlů a její převedení do kanonické podoby, výpočet digestu a porovnání s kontrolní hodnotou. V praxi se snadno může stát, že ověření podpisu zabere 90 % času potřebného ke zpracování zprávy. To je příliš vysoká cena za zvýšení bezpečnosti. Kdo opravdu nutně nepotřebuje zabezpečení na úrovni zpráv, spokojí se asi s nesrovnatelně efektivnějším zabezpečením na úrovni transportu.

Dokonce i poměrně jednoduché zpracování dokumentu XML se dostává do vážných problémů, je-li dokument trochu větší. Stačí pár desítek nebo stovek megabajtů. Většina současných technologií XML totiž vyžaduje načtení celého dokumentu do paměti a náhodný přístup k jeho uzlům. Reprezentace dokumentu v paměti v závislosti na implementaci potřebuje pětkrát až desetkrát víc místa, než je velikost původního dokumentu (viz např. kapitolu DOM Parsers for Java z knihy Processing XML with Java od E. R. Harolda). I když je k dispozici dost paměti, načtení moc dlouho trvá. A kdo je trpělivý a počká si, nakonec zjistí jen to, že s tak obrovským objektem se stejně nedá nijak kloudně pracovat.

Takže co s tím? Tyto nepříjemnosti pálí hodně lidí, proto už existují určitá řešení a na dalších se pracuje. Jednou možností je nenačítat dokumenty do paměti, ale uložit je do XML databáze. Na disku je dost místa, odpadá potřeba parsování a pro přístup lze použít indexy. Na XML databáze už se dnes nikdo nedívá jako na experiment. Za poslední roky dozrály, kromě kvalitních komerčních máme i open-source eXist. Samozřejmostí je podpora standardů XPath 1.0 a 2.0 a XQuery 1.0.

Uložit dokument do databáze se vyplatí jen u opakovaně zpracovávaných dokumentů. V případě ověření podpisu zprávy SOAP nám to nepomůže. Tady by bylo ideální budování reprezentace dokumentu úplně vynechat, ale v tom nám brání vyhodnocení výrazu XPath, které se bez načtení do paměti neobejde. Některá řešení se proto pokoušejí o streamovou implementaci podmnožiny jazyka XPath. Tyto systémy si efektivně poradí s běžnými případy, ale nezaručují, že si poradí se vším. V tom je úskalí mnoha současných optimalizací v XML. Pokušení a potřeba zvýšit efektivitu i za cenu nestandardních řešení jsou příliš velké. Osobně se mi tato cesta moc nezamlouvá. Za čistý způsob bych považoval vytvoření jiného navigačního jazyka, který by byl plně implementovatelný na XML streamu. Pro potřeby podepisování zpráv a mnohé další účely by takový jazyk pohodlně stačil. W3C v poslední době o podobné možnosti uvažuje, konkrétně se tímto tématem začala zabývat pracovní skupina XSL.

Už několik let W3C zvažuje jinou možnost optimalizace XML – zavedení efektivnější alternativní serilizace. Po prvních vlaštovkách MTOM a XOP omezených na optimalizaci přenosu zpráv SOAP se hledá obecné řešení. Pracovní skupina XBC nejdříve vyhodnocovala argumenty pro a proti binární serializaci, aby její pokračovatelka EXI dnes mohla vybírat nejvhodnější z existujících nestandardních formátů. Binární serializace, korektně nazývaná formát pro efektivní výměnu XML, by pomohla ve dvou ohledech. Prvním je rychlejší přenos díky menší velikosti serializovaného souboru. Druhým je rychlejší načtení. Výsledný formát by měl být kompromisem těchto dvou hledisek.

Po mnoha měřeních pracovní skupina EXI došla k závěru, že nejvhodnějším základem pro formát EXI bude stávající formát zvaný Efficient XML. Na květen je plánováno vydání první pracovní verze specifikace formátu EXI. Současně budou zveřejněny všechny výsledky experimentů, které vedly k rozhodnutí o použití právě tohoto formátu.

Prostor pro optimalizace zde samozřejmě je i v rámci už existujících standardů. Velkou výzvou jsou například implementace XSLT 2.0 a zéjména XQuery 1.0. Indexace, optimalizace dotazů, streamové zpracování, využití znalosti schématu – to všechno jsou oblasti, kde ještě dlouho bude co zlepšovat. Rezervy se určitě najdou u implementací většiny relativně nových standardů XML. První generace softwaru se pochopitelně zaměřila na správnost a úplnost implementace. Teď je ta správná doba pro rychlejší procesory, validátory, databáze a další nástroje.

Našli jste v článku chybu?

26. 4. 2007 19:56

AraxoN (neregistrovaný)
Žeby práve ASN.1 bol prototypom nejakého zrýchlenia, či zprehľadnenia, to by som netvrdil. Nemá zakomponované názvy elementov a typy sa bijú s tagmi o to isté miesto. Vyhľadávanie v ASN.1 je dosť tragické a ak nemám poňatie o tom, čo tam má byť zakódované, tak si ani neškrtnem.

25. 4. 2007 17:15

MoB (neregistrovaný)
Ono XSD je taky jenom XML.
Lupa.cz: Proč firmy málo chrání data? Chovají se logicky

Proč firmy málo chrání data? Chovají se logicky

120na80.cz: Pánové, pečujte o svoje přirození a prostatu

Pánové, pečujte o svoje přirození a prostatu

Podnikatel.cz: EET: Totálně nezvládli metodologii projektu

EET: Totálně nezvládli metodologii projektu

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

DigiZone.cz: ČRo rozšiřuje DAB do Berouna

ČRo rozšiřuje DAB do Berouna

Lupa.cz: Insolvenční řízení kvůli cookies? Vítejte v ČR

Insolvenční řízení kvůli cookies? Vítejte v ČR

Podnikatel.cz: Víme první výsledky doby odezvy #EET

Víme první výsledky doby odezvy #EET

Měšec.cz: Jak vymáhat výživné zadarmo?

Jak vymáhat výživné zadarmo?

DigiZone.cz: NG natáčí v Praze seriál o Einsteinovi

NG natáčí v Praze seriál o Einsteinovi

Podnikatel.cz: Na poslední chvíli šokuje vyjímkami v EET

Na poslední chvíli šokuje vyjímkami v EET

120na80.cz: Rakovina oka. Jak ji poznáte?

Rakovina oka. Jak ji poznáte?

DigiZone.cz: Recenze Westworld: zavraždit a...

Recenze Westworld: zavraždit a...

DigiZone.cz: ČT má dalšího zástupce v EBU

ČT má dalšího zástupce v EBU

Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?

Vitalia.cz: Chtějí si léčit kvasinky. Lék je jen v Německu

Chtějí si léčit kvasinky. Lék je jen v Německu

Měšec.cz: Finančním poradcům hrozí vracení provizí

Finančním poradcům hrozí vracení provizí

Root.cz: Vypadl Google a rozbilo se toho hodně

Vypadl Google a rozbilo se toho hodně

Vitalia.cz: Tesco: Chudá rodina si koupí levné polské kuře

Tesco: Chudá rodina si koupí levné polské kuře

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Podnikatel.cz: Babiše přesvědčila 89letá podnikatelka?!

Babiše přesvědčila 89letá podnikatelka?!