Autor Zpráva
TSD
Profil
Mám nápad, který by mohl přitáhnout opravdu hodně klientů, pokud to všecho není nesmysl, tak i stovky tisíc a víc.
Detaily si samozřejmě nechám pro sebe, ale nevím, jak organizovat data. Od každého klienta budu muset skladovat xml soubor o pár stovkách položek, jehož velikost se bude pohybovat v řádu desítek kB.

První co mě napadlo, tak že budu mít tabulku klientů a druhou tabulku xml položek, která by vypadala asi takto:

IDusera UrovenPolozky datapolozky ... < pár sloupců

detaily ještě vymyšlený nemám, ale šlo by o skladování stromečkových dat, tak bych chtěl použít ten princip, kde bych neřešil položku a jejího rodiče, ale hloubku zanoření ve stromu - princip ze stromečkových diskusí.

Nicméně stovky tisíc userů krát stovky položek = desítky miliónů řádků. Z toho mně běhá mráz po zádech. Je toto vůbec reálné skladovat v mysql a obhospodařovat pomocí php, nebo je na to potřeba nějaký vyšší kalibr?

A kde tohle hostovat?


Druhá možnost je skladovat celé to xml přímo v tabulce userů jako jeden varchar, ale to mi nepřipadá o moc lepší.
MaxwellDemon
Profil
sice mi neni úplně jasný, proč chceš kombinovat databázi a xml a nenarveš to do databáze celý ... xml je fajn věc, ale z hlediska performance celkem zářez

doporučuju použít mojí oblíbenou postgresql, která je taky freeware, má pohodlný admin rozhraní a bez jakýchkoli problémů zvládá veliký objemy dat (vyzkoušeno osobní praxí) ... managovat takovýhle objemy dat nějak rozumně, aby to netrvalo věčnost, na to bude chtít se mrknout na stored procedures a nechat většinu operací (včetně stavby toho stromu) vykonávat přimo na databázi ... php ti pak fasuje už jenom předchroustaný "zobrazovací" data ... pak to neni problém

a když se zeptáš po hosterech, tak někteří postgresql nabízej i tady u nás k hostingu

jinak - gratuluju k nápadu ... přeju hodně štěstí ;-)
TSD
Profil
Jak narvat celý?

Ono de facto půjde o vzájemnou aktualizaci dvou xml, to můžu myslím klidně prozradit :)
Tzn. zachovat pořadí, ale v jednotlivých větvích přidat nové položky, které jsou v uploadnutém souboru navíc a naopak, vygenerovat sestavu "nově přidané položky", kterou si pak aplikace na straně klienta stáhne a zpracuje.

Takže já nevím, jestli to skladovat jako nějakou předpřipravenou strukturu, která sice bude složitá, ale kterou po uploadu aktuálních dat budu moct procházet a porovnávat pár dotazy, nebo to prostě ukládat jako jeden dlouhý string a v momentu, kdy to bude potřeba porovnat s uploadnutým souborem, to vytáhnu jedním SELECTem a pak to budu nějak pracně lámat v php.

Nevím, asi to bude chtít uležet, ale v tuto chvíli se mi zdá, že bude lepší vykašlat se na strukturu a ukládat celé xml jako jeden string a všechno to procházení pak řešit v php. Tím bych se zbavil těch miliónových tabulek a zůstal trochu při zemi.
TSD
Profil
Teď mi někdo napíše, že mám použít php funkce GetFilesDiff a UpdateFilesDiff a já se picnu :)
Mastodont
Profil
IDusera UrovenPolozky datapolozky ... < pár sloupců

To se dá uložit do normální tabulky, ne?
TSD
Profil
Mastodont
To se dá uložit do normální tabulky, ne?

Jasně, to jsem psal hned v úvodu. Jen je problém, že v té tabulce by toho pak asi bylo opravdu hodně.
Joker
Profil
TSD
XML slouží k ukládání dat a databáze taky. Nebylo by výhodnější tu XML strukturu převést na databázové tabulky a případně potom generovat to rozdílové XML podle databáze?

Jinak co se týká samotného počtu záznamů, tak normální databázový systém by s desítkami milionů záznamů v tabulce neměl mít problém.
Samozřejmě pokud by se dělal kartézský součin (JOIN bez podmínky) dvou či dokonce více takových tabulek, to už by problém byl.

Nebo spíš takhle: nejde o počet řádků, ale spíš co s nimi děláte. Pokud budete mít tabulku třeba s 50 miliony řádků, ze které budete dělat nějaké SELECTy a třeba jednou za den UPDATE, bude na to MySQL docela vhodná databáze. Když budete mít i relativně malé tabulky, ale budete potřebovat transakce, složitější integritní omezení a podobně, tak na to MySQL moc vhodná nebude.
TSD
Profil
Joker
Struktura xml bude u každého jiná, takže převod na databázové tabulky (aniž bych přesně rozuměl, jak by to mělo vypadat) asi nepůjde.

Kartézský součin ne :) Půjde o jednu tabulku uživatelů a druhou tabulku, kde chci ukládat jejich xml, a to bych si představoval asi jako řadu záznamů, kde bych stromečkovou strukturu nahradil nějakým sloupcem Level, jakousi představu o tom mám.

Maximální zátěž by se dala odhadnout na několik málo (<5) přihlášení/ usera za den, přičemž každé přihlášení by obnášelo několik málo (cca 5) selectů a updatů, asi vždy nad jednou tabulkou (osoby nebo data), nejnáročnější operace by obnášely pár set řádků v tabulce.

To vše by platilo při té variantě dvou tabulek - osoby, data. Pokud z toho počtu řádků nemusím mít strach, tak tu variantu, že bych xml ukládal jako jeden string přímo v tabulce osob, můžu opustit.


Možná to všechno je nesmysl :) Ale nepůjde o malou databázi. Buď nebude nic, nebo tam ty milióny řádků budou.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: