Autor Zpráva
SwimX
Profil
Ahoj všem znalcům DB,

mějme modelový příklad, chtěl bych napsat "Analytics", takže budu mít tyto tabulky:

Sites
- id, name

Visits
- site_id, datetime, count

Referrer
- site_id, datetime, url, position // odkud uživatel přišel, ukládají se všechny s pozicí (první uživatel uloží první referrer záznam, druhý druhý, atd.)

Stránek budou řekněme tisíce, návštěv každé stránky tisíce denně - to máme milion záznamů v tabulce visits. Každá taková návštěva bude mít referr. Teď přežeňme a počítejme se vším krát 10 nebo i 100 když se projekt rozroste.

Potřebuji zobrazit statistiku návštěv vybrané stránky za měsíc. Porovnat s minulým měsícem.
Potom pro nějaký den zobrazit všechny referrery pro danou stránku. když si vyberu nějakou url v referrer tabulce, tak chci vypsat, kolikátým referrerem je tato url pro jiné stránky.

Moje otázka tedy zní: hodí se na to MySQL? Vyplatí se mi, ukládat data po měsících do jiné tabulky, aby se vyhledávalo nad menšími tabulkami (destíky milionů) a ne nad velkými (stovky milionů). Nebo mám použít něco jiného? Jinou DB, nějakou cache, atd, ocením všechny rady. Díky za pomoc
peta
Profil
Kdyz bys to daval do jedne tabulky, mozna by se vyplatilo pridat jeste navic sloupec mesic a rok pro rychlejsi vyhledavani. S gigovymi soubory system obvykle dost pomalu pracuje, pokud neni server nebo diskove pole. Jestli by treba nebylo lepsi to take ukladat na externi disk.
SvvimX
Profil *
peta:
Na externí disk? V serveru máme SAS 15 k otáček, pochybuji, že externí disk by běhal rychleji. Já se právě ptám, jestli to dělit po tabulkách=měsícíh, tím bude méně dat v jednom souboru a půjde to asi rychleji, ale zase dotazy napříč několika měsíci budou tahat data z více tabulek. Případně jetsli udělat na měsíci vždy po roce view?
Jestli nejít radši do PostgreSQL?
Kajman
Profil
Možná by se hodily dvě mysql databáze (nebo rovnou servery). Jeden master na ukládání, z něho nakonfigurovat repliky na druhý stroj, který bude určený na čtení pro analýzy.

Rozdělení po měsících asi nebude výhodné. Občas se dělávají dvě tabulky, pokud je hodně velký rozdíl v četnosti čtení. Tedy např. data s posledními dvěma kalendářními roky + stejná tabulka s archivem s předcházejímí roky. Ale třeba to ani potřeba nebude.

Pro výběr řešení nebo i sql platformy bude potřeba udělat testy s očekávanou maximální zátěží.
peta
Profil
Jj, server jsem myslel. Abys neukladal tenhle log na provozni server, ale nekam bokem. By se ti mohlo stat, ze to zatizis tak, ze ti nepobezi hlavni programy, coz je casto vetsi maler nez prijit o o par logu, statistik.
Ty si muzes ty vypocitane statistiky take ukladat bud do db nebo uz primo html, abys to nemusel znova generovat.
SvvimX
Profil *
Kajman:
díky za reakci (vrátil jsem se na diskuzi po pár letech a vidím, že ty tu stále reaguješ :-) Takže myslíš, že je zbytečné dělit tabulky po měsících i letech, přestože měsíčně přibyde do tabulky 10 miliónů záznamů? Vyhledávání (správně indexované, což v mém případě bude datum a FK na sites) bude nad stovkami miliónů záznamů stejně rychlé, jako to dělit?

Více serverů asi nevyjde, ale více databází s replikací může být, zápis přes den na jeden server a noční replikace, to zní dobře. Ale toho se nebojím tolik, jako pomalé odevzdy při vyhledávání ve webové aplikaci.

Poslední 2 roky (nebo i jeden) bych klidně vyčlenil do jiné tabulky jak píšeš, neboť více než rok (max 2) dozadu se nikde dívat nebude, nebo jen hodně výjmečně.
Kajman
Profil
SvvimX:
zápis přes den na jeden server a noční replikace

Měl jsem na mysli realtime replikaci.
http://dev.mysql.com/doc/refman/5.5/en/replication.html
SvvimX
Profil *
ta noční mi přijde lepší - méně vytěžuje server, než realtime. Data potřebujeme vždy až den zpátky...

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:

0