Vlko napísal ...

OT: Reakcia na clanok "Optimalizace uložení dat v Open XML" - doplnenie

Pri dnešnom tradičnom rannom prechádzani bookmarkov mi zrak padol na článok Optimalizace uložení dat v Open XML a musím sa priznať, že ma tento článok úprimne povedané vytočil.

Je jasné, že článok má PR razenie a je napísaný štýlom, ktorý ja osobne neznášam (cielené výber dôkazov, zvýhodňujúci iba jeden produkt). Je tam prezentavaná vo vynikajúcom svetle implementácia, ktorá odporuje podstate myšlienky.

Podstata XML

Podľa môjho názoru bol formát XML zavedený aby dokázal popísať určitý formát dát tak, aby tento formát bol umožnený prečítať nielen stroju ale najmä človeku a to z jednoduchého dôvodu:

Dáta musia byť čitateľné aj keď aplikácia, ktorá ich spracuváva už neexistuje.

Polemika 

A to je podľa mňa to najdôležitejšie a tuto základnu premysu autor článku nepochopil. Čo jasne vidieť z jeho záverov. Viď bod 1a

1.       Formát optimalizovaný pro ukládání velkého množství dat.

a.       Často se opakující elementy mají jedno písmenné názvy. Čte je počítač, ne člověk.

 

Bohužiaľ práve XML formát je určený na to, aby vedel čítať aj človek. Mam na to jednoduché vysvetlenie:

Zoberme si dobu o 30 rokov. Software bude uplne niekde inde a my sa budeme potrebovat dostat k datam, ktore robil nas dedko v exceli a vyexportoval to v Open XML. Budeme vediet z jednopismenovych popiskov dostat strukturu dokumentu?

Autor ale pokračuje

c.       ODF používá stejnou strukturu tabulek pro Calc i pro Writer, i když potřeby tabulek jsou jiné v textovém editoru a tabulkovém kalkulátoru.

 Ano to je pravda, ale len pre autora. Ja osobne používam tabuľky vo word dokumentu a rád by som použival word štruktúrovane texty v excel tabuľke.

A hneď nasleduje:

2.       Jednodušší XML. Paměťová struktura, pro uložení XML souboru bude jednodušší. Cesta k hodnotě buňky:

 Opäť musím autora sklamať, ale jediná nevýhoda, ktorá z väčšej veľkosti popiskov xml nodov a atribútov vyplýva to, že daný xml súbor bude pomalšie rozparsrovaný, nič ale nehovorí, koľko v skutočnosti takto rozparsovaný xml dokument zaberie v pamäti. Táto neznalosť je jednoznačne vidieť už v predchádzajúcom texte:

Podstatně důležitější pro zpracování je dekomprimovaná velikost. To je to, co nám bude zabírat operační paměť.

 A nebude a nebude a nebude:), jedine ak si z nejakého neznámeho dôvodu budeme držať v pamäti aj pôvodnú nerozparsovanú hodnotu dokumentu.

A ďalší subjektívny názor:

3.       Texty uloženy v jiném souboru než číselná data.

a.       U velkého množství scénářů, mě texty nezajímají, stačí číselné hodnoty.

 Aj ja mám oveľa vätšie množstvo scenárov, kde ma texty zaujímajú a pri parsrovaní dokumentu pomocou xmlreadera budem musieť doťahovať tieto texty z iného súboru, čo teoretický spomaľuje výkonnosť. Ale to je len jedna implementácia.

b.      Texty jsou sdílené pro všechny listy a zbytečně se neopakují.

 Aké texty? To je tam zoznam všetkých použitých slov? A miesto textu ukladáme len zoznam identifikátorov použitých slov v texte? Silne pochybujem. K tomu pri vlastnom implementovaní formátu pravdepodobne budem musiet použiť hashovanie každého textu, tak aby sa mi tam neobjavoval viackrát.

Záver

Članok dokazuje ale opačnú vec a to pre mňa ako programátora a možného implementátora OpenXML formátu do mojej aplikácie:

Implementácia bude veeeeeľmi zložitá.

Miesto  veeeeeľmi máme na slovensku výraz začinajúci na k, ale ten z morálneho hľadiska nepoužijem.

Pridám ešte pár myšlienok pre polemiku:

1. Ak chcem použivať XML formát vyberám si ho preto, aby som našiel čo najblišiu implementáciu blízku k binárnemu formátu, alebo taký formát, ktorý ma najvätšie predpoklady pre zachovanie obsahu dát?
2. Mám len ja pocit, že OpenXML je 1 k 1 implementácia binárneho formátu? Spojena s balastom prenášaným od počiatkov existencie office balíka. Vid specifikácia dátumov, ktora nie je shodná so žiadnou ISO normou.
3. Ako sa takýto článok dostal na portál, ktorý ma v názve Czech/Slovak Developer & Platform Group a je určený pre vývojarov a pravdu povediac sa nedajú opiť rožkom?
4. Stálo mi za to reagovať?
   

A možete ma ukameňovať.

APPENDIX

Spravil som si taky maly testovaci programček, ktorý načíta ods, alebo xlsx subor a spočíta čas a kolko pamäti zaberie takýto dokument v pamäti.

Ako dáta som použil cenník pc komponent z webu s cca 10 k položiek, ktoré som zdvojnásobil a pridal stĺpec s dátumami, ktoré boli random nagenerované, k stiahnutiu tu.

Zdrojovy kód možete stiahnuť tu.

Príklad sa spúšťa príkazom test.bat a je k stiahnutiu tu. 

Nuž a tu je moja metodika:

• rozzipovanie xml dát, najde v ňom pre odf: content.xml a pre openxml: sheet1.xml a sharedStrings.xml.
• načítanie xml dát do XMLDocument-u
• výpis koľko tieto dáta zaberajú v pamäti (používam jednoduche GC.GetTotalMemory(true))

A tu sú výsledky:

 Načítaný OpenDocument teda zaberá v pamäti (stav pamäte su tie hodnoty za Start a End a za with difference je napisana rozdielova hodnota pamati) o 4.6 % viac miesta, samozrejme tým, že je jeho formát ukecanejší, jeho parsrovanie trvá dlhšie.

Zajtra ešte pridám appendix 2, kde ukážem ako v každom formáte vyzerá jeden riadok tabuľky.