logo
16.11.2019 17:33
1
Zdravim, mam dve moznosti ako ukladat data do MySQL a neviem sa rozhodnut ktora je spravnejsia:
Možnost 1:
Kód:
Metric{
  Id
  MetricTypeId
  Code
}

MetricType{
  Id
}

Visit{
 Id
}
VisitMetric{
 VisitId
 MetricId
}
vs.
Možnost 2: Metriky v jednotlivych tabulkach .. cca. 10 tabuliek typu Language, Browser etc. a mapovanie vo Visit tabulke do stlpcov:
Kód:
Language{
  Id
  Code
}
Country{
  Id
  Code
}
Browser{
  Id
  Code
}

Visit{
  Id
  LanguageId
  CountryId
  BrowserId
}
Prva možnosť je náročnejšia z hľadiska insertov, cca. 10 insertov do VisitMetric pre kazde vlozenie zaznamu do Visit. Druhá je viac duplictného kódu kedže sa všetky Language, Browser,Country chovajú rovnako, majú rovnaké stĺpce.
16.11.2019 18:27
2
jednoznačně první, splňuje 3. normální formu a takhle se to má dělat.

V druhém případě jakékoliv přidávání dalších metrik způsobí nutnost přidat další tabulky. Nevhodně fragmentuješ data na db
16.11.2019 19:27
3
Diky. System doteraz fungoval ako moznost 2 s len jednou metrikou. Pridavam teraz nove preto ma napadlo to riesit inak, moznost 1 vyzera sexi ale uz teraz su operacie nad tabulkou Visit pomale - bezne treba 200,000 novych riadkov kazdy den, moznost jedna v podstate prida k tomu dalsich 2,000,000 riadkov kazdy den do tabulky VisitMetric a mam obavu ze to bude este pomalsie.. v peakoch sa robi aj 10 insertov do tabulky za sekundu .. to bude zrazu 10x viac.. sice obidenim ORM sa to da spravit 1 insertom a jednym multiinsertom.
Aj ked zohladnis tento performance problem by si isiel do moznosti 1?
Je k tomu aj nejaka teoria preco moznost 1?
16.11.2019 20:27
4
preco to nedas do jednej tabulky? aku ma logiku mat tabulky s jednym stlpcom a linkovat nan v inej tabulke?
16.11.2019 20:33
5
Tabulka Visit ma viac stlpcov, len som ich nenapisal sorry .. napr. url, datum, cas atd.
Ci si myslel inu?
17.11.2019 12:06
6
pokud jde o rychlost, neumím moc poradit. Problém to být nemusí, ale také to může být fatální, neznám typ, verzi a konfiguraci db. Např. Mariadb 10.2 nasazujeme i při 20 000 insertů / s na jediném stroji, ta technologie to umí zvládnout, nelze ale říct, že každá instance s libovolným nastavení to zvládne.

Sám musíš vědět jak je tvůj systém dimenzovaný a kolik toho zvládá, podle toho případně přejít na 4. normální formu jako způsob optimalizace (plochá tabulky a duplicitami bez referenčních struktur), to ale musí vycházet z měření s vědomím jeho nevýhod.

Můžeš použít i kombinaci, prvotní záznam uvedeš do jedné tabulky jako spousty sloupců (běžně se tomuhle říká staging) a až na pozadí asynchronně (třeba každou minutu) tyhle záznamy převedeš do normalizované formy, s kterou se zase lépe pracuje. Stejně tak to je s reportingem, je zbytečně každý reporting počítat online z RAW dat, můžeš mít předpočítané hodnoty pro hodiny, dny, měsíce a s tím pak pracovat v administraci.

10 insertů / s (multiinsert je samozřejmě vždy lepší) by ale neměl být problém snad pro žádný hosting (výjma wedosu, tam i tohle je problém). Počet indexů drž nízko, nepoužívej přílož dlouhé datové typy (aka varchar(255)), ale vždy co nejpřesnější a ideálně numerické. Stejně tak nemusíš nechávat RAW data neomezenou dobu, ale třeba jen pro poslední rok a zbytek držet jinde či už jen předpočítaně na větší celky, záleží jaké jsou tvoje potřeby a jak s těmito údaji zacházíš. Retence či offloading na pomalejší (levnější) databázi lze poměrně jednoduše.