Autor Zpráva
Jimmik
Profil *
Ahoj, mám dotaz na zkušené v databázích. Zkouším programovat něco jako Google Analytics a potřeboval bych poradit ohledně rozvržení databáze.

Jelikož jsem předpokládal, že tabulky budou velice obsáhlé začal jsem dělit jednotlivé účty do oddělených tabulek ("návštěvy_účtu_1", "návštěvy_účtu_2" - kde číslo určuje daný účet stránky), každý účet se skládá z cca 15 tabulek. Využívám i importy dat, třeba objednávek, které ukládám podobně do jiné databáze, aby se první nezahltila tabulkami - což teď volbu chápu jako zcela nešťastnou, protože potřebuji pracovat s tabulkami v obou databázích současně, takže to musím předělat do stejné databáze a tím pádem v jedná databázi bude mít jeden účet cca 50 tabulek.

Můj hlavní dotaz, když to budu předělávat je, zda volba rozdělovat účty po samostatných tabulkách je dobrá, abych neztroskotal později i na tomto. Jeden účet již testuji na jednom obchodu a tabulka s přístupy se plní neuvěřitelným způsobem proto si nedovedu představit, že by všechny účty mířili do jedné tabulky nazvané třeba "návštěvnost".

Prosím o nějaké tipy, jak byste problematiku řešili vy?

Moc děkuji za pomoc!
Kajman
Profil
Nemyslím, že třeba Google Analytics budou mít pro každý účet samostatné tabulky.

Nad tabulkou je v některých systémech možné nakonfigurovat partitioning, čímž fyzicky dojde k oddělení do více souborů i když to je tabulka jedna.
Keeehi
Profil
Pokud se v tabulce "návštěvy_účtu_1", "návštěvy_účtu_2" vyskytují data stejného typu, a toto dělení je jen pro "rozložení zátěže" tak by mělo jít jen o jednu tabulku. Počet záznamů v tabulce by vůbec při návrhu neměl hrát roli. Teoreticky by mělo být jedno, zda tam bude záznamů 50 nebo nekonečno.
Jimmik
Profil *
Kajman:
To si také nemyslím, jen mě nenapadl žádný jiný způsob. Děkuji za vlákno zkusím o tom načíst více.


Keeehi:
Původní cíl byl optimalizovat vyhledávací dotazy, přece i s použitím správných indexů by mělo být jednodušší vyhledávat podle tabulky a poté až podle záznamů mluvíme-li o stamilionech záznamů vezmu-li v potaz třeba tabulku se záznamy zabrazení stránky (co načtení stránky - to záznam)?
Keeehi
Profil
Jimmik:
Je to velmi obecný popis a těžko se něco o tom pak soudí. V teoretickém popisu databází se s počtem řádků vůbec nepracuje. Předpokládá se, že tabulka (relace) může mít neomezné množství záznamů a vůbec to ničemu nevadí. Samozřejmě že v reálu může být výhodné nějaká pravidla porušit ale vždy si pak musím být vědom co porušuji, proč to porušuji, jaký to bude mít přínost a jeké mohou vzniknout problémy. Rozhodně není správné porušovat pravidla jen proto, že si myslím, že by to mohlo být lepší.
Jinak MySQL samozřejmě nějaký ten milion záznamů zvládne. Ovšem MySQL není jediná databáze na světě. Jsou i napríklad takové, které jsou dělané právě na práci s velkými daty.
A ještě k tomu zrychlení. Z toho vašeho popisu to bude dost nepřesné, ale hrubě: Řekněme, že jste zátěž rovnoměrně rozdělil mezi 50 tabulek. Pokud budeme předpokládat lineární vyhledávání, zrychlil jste to 50x. Což je konstanta, nazávislá však na počtu záznamů. Nejsem v tomto oborník, ale kdyby databáze vyhledávali lineárně, tak by asi moc dobré a použitelné nebyly. Co jsem se díval, tak MySQL nad indexy staví stromy. U nich je složitost vyhledávání je typicky nějaký logaritmus. A log(50) ~ 4. Což tedy není nic moc.
Jimmik
Profil *
Keeehi:
Poptal jsem se i jinde a určitě máš pravdu, že dělení do více tabulek můj problém vůbec neřeší, jen to maximálně komplikuje pozdější zprávu dat. Bylo mi doporučen horizontal partitioning, který doporučil Kajman. Jen zcela nechápu z návodů, zda lze třeba tabulku automaticky dělit podle hodnoty v určitém sloupci - to by řešilo můj problém - dělil bych tabulky na "podtabulky" pomocí id účtu, který je přidělen všem záznamům..
juriad
Profil
Jimmik:
K tomu dělení viz: http://dev.mysql.com/doc/refman/5.6/en/create-table.html#idm140325637713424
A v MySQL to má některé omezení: nelze použít cizí klíče v InnoDB.
Jimmik
Profil *
juriad:
Díky za vlákno.

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: