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?
- 1111 megtekintés
Hozzászólások
Igen meg kulon neve is van ugy hivjuk hogy data warehouse :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+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. ;)
- A hozzászóláshoz be kell jelentkezni
+1
Ajanlom figyelmedbe az Apache Kafka-t
- A hozzászóláshoz be kell jelentkezni
+1
Nálam is (ERP) a log durvább mint maga a munka.
- A hozzászóláshoz be kell jelentkezni