Autor | Zpráva | ||
---|---|---|---|
TSD Profil |
#1 · Zasláno: 4. 5. 2008, 00:03:41
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 |
#2 · Zasláno: 4. 5. 2008, 07:52:44 · Upravil/a: MaxwellDemon
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 |
#3 · Zasláno: 4. 5. 2008, 09:46:50
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 |
#4 · Zasláno: 4. 5. 2008, 09:49:10
Teď mi někdo napíše, že mám použít php funkce GetFilesDiff a UpdateFilesDiff a já se picnu :)
|
||
Mastodont Profil |
#5 · Zasláno: 4. 5. 2008, 10:19:06
IDusera UrovenPolozky datapolozky ... < pár sloupců
To se dá uložit do normální tabulky, ne? |
||
TSD Profil |
#6 · Zasláno: 4. 5. 2008, 10:28:19
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 |
#7 · Zasláno: 4. 5. 2008, 12:04:23
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 |
#8 · Zasláno: 4. 5. 2008, 12:36:19
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. |
||
Časová prodleva: 16 let
|
0