| Autor | Zpráva | ||
|---|---|---|---|
| Medvídek Profil |
#1 · Zasláno: 11. 5. 2012, 12:31:59
Potřeboval bych nějakou jednoduchou NoSQL databázi (co sem tak zběžně koukal, našel sem nějakou MongoDB). Jedná se mi o to, že nyní vypisuji z DB (MSSQL) nějaké události. Pro většinu případů je to celekm svižné, ale mam tu i extrémy, kde za jeden den můžu dostat až 25 000 záznamů. Při zobrazení celého měsíce (či vlastního výběru) se tedy dostávám na 31xdotaz kde je výsledkem 31x25 000 záznamů, což vdyžcky skončí na execution time. Proto řešim, že bych předělal démona, kterej mi data cpe do MSSQL, aby mi ho cpal i do NoSQL a já si ty záznamy tahal odsud.
Struktura je asi takováto: Pro každý den je v MSSQL vytvořena tabulka s názvem dnem (event_5_5_2012). V ní už jsou jednotlive eventy, kde mě zajímá pouze identifikátor zařízení, timestamp a kód události) Vždy se bude jednat pouze o tento výběr: SELECT * FROM event_5_5_2012 WHERE id_hw = F306 Jaká NoSQL db je pro toto nejvhodnější, co se rychlosti a výkonu týče? |
||
|
Časová prodleva: 7 dní
|
|||
| AM_ Profil |
#2 · Zasláno: 18. 5. 2012, 13:47:44
Mno tak především je tragicky špatný návrh mít na každý den vlastní tabulku a záznamy tahat 31 dotazy, to se nedivím, že neběhá svižně. Také si nejsem jistý, jestli opravdu zobrazuješ na stránce 775 000 záznamů najednou? není to trochu nepřehledné a neřešilo by to nějaké stránkování?
SQL databáze bývají dobře optimalizované právě na dotazy nad velkými tabulkami, takže pokud to všechno srazíš do jedné tabulky a budeš tahat jen ty záznamy, které opravdu potřebuješ. |
||
| Medvídek Profil |
AM:
Špatný návrh to není, je to aplikace, která vlastně nebyla řešena na dotazy typu poslední měsíc. Samozřejmě ta aplikace je závislá na struktuře db, já z toho potřebuju pouze 2% tabulek, se kterými pracuje ta aplikace Takže strukturu db odkud to tahám měnit nemužu. Ono pokud máte v db 8000 zařízení a v krajní situaci každé poslalo denně 25 000 záznamů, tak to máme za měsíc 6200000000 záznamů, proto tvůrci zvolil řešení pro každý den. Stránkování mi nepomuže, pokud bych to potřeboval pouze pro hození na sklo, tak si to udělám ajaxem po jednom dnu a sem vysmátej. Ale mně jde hlavně o export, kdy data exportuju do XLS a PDF, kde už toto možné není. |
||
| Kajman Profil |
Medvídek:
Zkoušel jste změřit, co trvá při tom exportu nejdéle? Na sloupci id_hw je index? Limit pro execution time můžete posunout? |
||
| Medvídek Profil |
#5 · Zasláno: 18. 5. 2012, 15:11:28
Kajman:
Execution time posunout můžu (jedu na vlastnim serveru), ale i pokud ho posunu na 4 minuty, stejně vyprší. (Problém bude asi i tím, že každá záznam ještě prolejvám funkcí, která mi ho přetextuje). Spíše mě zajímalo, jestli si NoSQL DB, která poběží na stejnym stroji pomůžu, nebo řešim neřešitelné. Jinak klíč na sloupci je. (Dá se v MSSQL udělat nějak EXPLAIN SELECT?) |
||
| Kajman Profil |
#6 · Zasláno: 18. 5. 2012, 15:44:14
Medvídek:
„Spíše mě zajímalo, jestli si NoSQL DB, která poběží na stejnym stroji pomůžu, nebo řešim neřešitelné“ Záleží na tom, co ten výpis brzí. Pokud vynecháte tu přetextovávací funkci, tak je to svižné? V tom případě si změnou db nepomůžete. „Dá se v MSSQL udělat nějak EXPLAIN SELECT?“ http://msdn.microsoft.com/en-us/library/ms176058.aspx http://msdn.microsoft.com/en-us/library/ms187757.aspx |
||
| AM_ Profil |
#7 · Zasláno: 18. 5. 2012, 16:55:29
[#3] Medvídek
Ať už byla aplikace vymyšlena na cokoliv, tak je celkem hloupost dělit tabulku po dnech - z čeho soudíš, že 6 200 000 000 bude pro mysql moc? naopak, právě tím, že je to roztrhané na víc tabulek, v tom nejde tak efektivně indexovat. Pokud už tuto strukturu nemůžeš měnit, můžeš zkusit vytvořit nad těmi tabulkami pohled a na něm index, třeba si to poradí lépe, ale to jen tipuju do větru. Jinak jak píše Kajman, nejdřív je dobré zjistit, co to opravdu zpomaluje, než budeš dělat změnu typu přesun na jinou databázi |
||
|
Časová prodleva: 12 let
|
|||
0