Mennyi hasznosnak tűnő plusz infót tároltok el?

 ( dotnetlinux | 2017. szeptember 13., szerda - 17:11 )

Előtörténet:
17 évesen adatbázis kezelőt akartam írni, mert persze mindegyik szar és lassú, majd én mutatok a világnak valami profi cuccot. Aztán persze rájöttem, hogy vannak nálam okosabbak. (6Mrd emberből csak akad egy). Most már nyilván én is más megoldásait használom, kockákból építkezem: percona + speciális indexelő megoldás + stb.

Jelen történet: Szerintem túl sok adatot rakok el az adatbázisban. Nem ügyfél igényeket valósítunk meg, szabad kezünk van az üzleti alkalmazások építésekor és biztos-ami-biztos alapon eltárolunk mindent. Csak hogy lássatok pár példát:

- Összes kattintás "legfontosabb" adatai: mikor, ki, honnan, hova, post mérete, eredmény mérete, válaszidő. Mert majd jó kis statisztika jön ki belőle (amit senki nem kért) és néha jól jön, hogy megtudjuk, mikor járt az adott oldalon (pl.: vevő adatlap) a felhasználó. Persze ha ez üzleti igény lenne, akkor lenne egy PartnerLastVisit tábla erre.

- Összes felhasználói Excel feltöltés: mikor, ki, mit és hol töltött fel. Megkönnyíti a hibakeresést, ha nem az ügyféllel kell beküldetni az Excelt, ami szerinte jó oda, de a rendszer hibát ír ki.

- Összes külső API kommunikáció, még akkor is, ha az eredmény üres. Például árfolyam letöltés vagy készletinfó 5 percenként, még ha nem is változott semmi.

És a fentieket megelégeltem, mert a DB feleslegesen 15Gb, tömörítve és ha néha kell egy stat, hogy mikor változott az árfolyam, akkor persze, hogy nem 1mp a válaszidő, hanem 3 perc a sok felesleges "LOG" miatt.

Vitaindtó kérdésem: Ti szoktatok olyan adatot tömegesen elrakni, ami "jó ötletnek tűnik", illetve "biztos ami biztos" mentsük el?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Igen meg kulon neve is van ugy hivjuk hogy data warehouse :)

Néha előfordul. De jól szokott jönni a sok szemét debugra.

Mondjuk legutóbb egy 5 Millió rekordos táblát duplikáltam 10x, performancia teszthez. Jól jött oda is, hogy meglévő adattal dolgoztam, nem kellett még generálni is random szemetet.

--
openSUSE 42.2 x86_64

Ezek az adatok szinte kivétel nélkül LOG-jellegű adatoknak tűnnek (a PartnerLastVisit pl. nem).
Namost LOG tárolására nem az RDBMS az igazi, ugyanis relatíve nagy az overhead, és nem igazán fogod kihasználni a relációsságát. BLOB-jellegű cuccokat (pl. komplett fájl, API hívás, stb) meg depláne nem jó játék RDBMS-ben tárolni, arról még az igazán keménycsávók is le szoktak szokni (egy "tároljunk el minden beeső SNMP trapet BLOB-ban az Oracle adatbázisban, aztán töröljük naponta a 30 napnál régebbi sorokat, és lepődjünk meg, hogy mennyire lassú a BLOB sorok törlése" c. játék után nagyon gyorsan meg lehet bárkit győzni a dolog ésszerűtlenségéről).

Úgy általában: érdemes végiggondolni, hogy milyen adatokat és milyen mennyiségben szeretnél tárolni, milyen módon szeretnél tudni benne keresni, ha mozgóablakos felhasználást akarsz, akkor a törlésen is el kell gondolkodni, és persze azt a megoldást kell keresni, ami leginkább megfelel az adott felhasználásnak.

+1
Sőt, nem csak az RDBMS, hanem az egyszerű text sorok tárolása is időtrabló.

Ha törölgetni kell, akkor helyette a fix méretű ciklikus log sokkal jobb - nem véletlenül használják sok helyen.
Meg tegyünk rá jó sok indexet, hátha keresni kell. ;)

+1

Ajanlom figyelmedbe az Apache Kafka-t

+1

Nálam is (ERP) a log durvább mint maga a munka.