Efektivita MySQL při uložení velkého XML

[Thugmek]

Dobrý den, víte někdo jak MySQL vyhledává v databázi? Dělám takovou hříčku, něco jako Travian (pravděpodobně to nikdy nikdo nebude hrát) a potřebuju tabulku hráčských vesnic, kde bude vlastník, poloha a pak velkej XML soubor obsahující všechny informace o vesnici (suroviny, budovy, jednotky...). Jak moc bude ten XML soubor databázi zpomalovat když budu například vykreslovat mapu (načte se všechno kromě toho XML)?

[Reklama]

[Jan Forman]

Pokud bude dlouhý, měl by být uložený mimo takže při selektu bez XML by to mělo být jedno.
Do nějaké velikosti domnívám se do 64kB se vkládá rovnou mezi data v tabulce.

V případě nouze si myslím, že i v produkci není problém to odhodit do jiné tabulky.

Dobrý den, víte někdo jak MySQL vyhledává v databázi? Dělám takovou hříčku, něco jako Travian (pravděpodobně to nikdy nikdo nebude hrát) a potřebuju tabulku hráčských vesnic, kde bude vlastník, poloha a pak velkej XML soubor obsahující všechny informace o vesnici (suroviny, budovy, jednotky...). Jak moc bude ten XML soubor databázi zpomalovat když budu například vykreslovat mapu (načte se všechno kromě toho XML)?

[O.]

Neni lepsi mit ty XML soubory na disku a v DB sloupecku mit jen cestu k souboru?   

[Štefan]

Pokud už musíš mít ty data v XML, dal bych ho do separátní tabulky, vzhledem k tomu, že ho nepotřebuješ číst pořád.
Ale vážně bych se zamyslel nad tím, jestli by nebylo lepší ty data normalizovat a mít je jako regulérní tabulku..

[Trupik]

Pokud už musíš mít ty data v XML, dal bych ho do separátní tabulky, vzhledem k tomu, že ho nepotřebuješ číst pořád.
Ale vážně bych se zamyslel nad tím, jestli by nebylo lepší ty data normalizovat a mít je jako regulérní tabulku..

Ak experimentuje, tak možno nemá dopredu vymyslenú pevnú štruktúru dát pre "vesnici". Alebo si netrúfa so svojou znalosťou SQL nasypať tam všetko. Podľa mňa je oboje v poriadku.
Čo by som zvážil, je vykašľať sa na XML (ak nechce robiť XSLT transformácie) a držať to ako JSON. Je kompaktnejší a parsuje sa rýchlejšie. Na webe je tiež možné ho poslať AJAXom do prehliadača, kde sa absolútne jednoducho stane objektom Javascriptu a dá sa s ním ďalej pracovať.

[Reklama]

[3ugeene]

a proč to musí být xml soubor?

[3ugeene]

pardon, mezitim přišly odpovědi....


JSON je lepší, ale proč nemít ta data v separátní(ch) tabul(ce|kách)?

[dustin]

Kolik těch XMLek bude? Když to dáš jako typ text/mediumtext, v rozumných počtech řádků to mysql zvládne úplně v pohodě. Samozřejmě předpokládám správné indexy a že v tom nebudeš hledat přes like.

Na všechny tvé tabulky engine innodb s nastavením innodb_file_per_table.

[Kit]

XML je obvykle lépe na disku v podobě souboru. Kombinace XML s databází nebývá příliš výhodná.

[Kamil Podlešák]

XML je obvykle lépe na disku v podobě souboru. Kombinace XML s databází nebývá příliš výhodná.

Naopak, kombinace XML (nebo JSON) s databází je velmi výhodná, pokud daný db engine dokáže s XML/JSON pracovat. Můžeš si nad nimi dělat ad hoc dotazy a dokonce i indexy. Bohužel nevím jak je na tom zrovna MySQL, už přes deset let používám jen DB2 a Postgresql.
Disclaimer: Samozřejmě, neporovnávám XML/JSON s korektní normální formou, ta je vždy pro hledání lepší.

Kombinace souborů na disku s databází je naopak velmi nevýhodná, a to hned z několika důvodů:

• Buď může existovat jen jeden klient (který má u sebe ty soubory), nebo musí všichni klienti sdílet nějaký filesystém. Ne že by to nešlo, s takovým NFS si člověk užije spousty zábavy když vypadne spojení...
• Práce se soubory není součástí transakce. Je ošetřit všechny kombinace rollbacku a chyb FS, jinak se bude stávat že chybí soubor odkazovaný z db, nebo naopak na fs nějaký přebývá. O současné změně obsahu souboru ani nemluvě.
• Pokud už někdy chceš hledat uvnitř (v podstatě nutné při ručním řešení problémů), tak musíš ručně spojovat nějaký grep/xmlstarlet/jq a SQL dotaz.

Samozřejmě, pokud se jedná o významné objemy dat, tak se nedá nic dělat a všechny výše uvedené problémy řešit. A samozřejmě, někdo má rád výzvy :-)

[dustin]

V původním dotazu není o vyhledávání v tom XML nic, IMO to chce jen ukládat a pak vytahovat.

[Kamil Podlešák]

V původním dotazu není o vyhledávání v tom XML nic, IMO to chce jen ukládat a pak vytahovat.

Jo, to si možná myslí teď, ale podle toho co do nich chce ukládat (cituji: suroviny, budoviny, jednotky) je mi jasné že hned druhý den bude potřebovat najít kolik má prázdných vesnic apod.

[Kit]

V původním dotazu není o vyhledávání v tom XML nic, IMO to chce jen ukládat a pak vytahovat.

Jo, to si možná myslí teď, ale podle toho co do nich chce ukládat (cituji: suroviny, budoviny, jednotky) je mi jasné že hned druhý den bude potřebovat najít kolik má prázdných vesnic apod.

suroviny, budoviny, jednotky... Zřejmě do toho bude chtít během hry i zapisovat změny, což je další argument proti použití XML. Tohle vypadá spíš na klasické použití normalizované databáze SQL, tedy bez XML.

Pokud by to měla být NoSQL databáze, tak asi Redis, protože nabízí i kolekce, které by zde mohly najít uplatnění. Při troše šikovnosti by ani nemusely chybět transakce.

[3ugeene]

zatim je to v poho, protoze po nas nechce vymyslet kompletni reseni

[Tomas2]

MySQL má datový typ blob, jeho obsah je uložený mimo zbytek řádku jako soubor a jeho přítomnost nemá vliv na zbytek práce s řádkem.

Obecně ale takovéhle ulehčení není vhodné, narazíš s tím, když budeš chtít třeba dělat statistiku nebo celkový přehled několika údajů, bude to náročné. Velice problematické to je v případě, kdy časem budeš měnit/rozšiřovat strukturu těhle dat, doménová logika pak bude obsahovat zbytečně hodně ifů nebo musíš jednorázově transformovat všechny tyhle xml.

Raději to uloži do databáze ve formě key, value.