Database logging
Din ideile crete care imi circula prin cap in ultima vreme: ma bate gandul sa trec toate vhosturile sa faca logging in DB (MySQL, probabil). Ideea ar fi ca imi place sa sap prin ele si cu select-uri e ceva mai simplu decat cu grep-uri. In plus, fac tot felul de vhosturi si e enervant sa tot fac loguri noi, intr-un db e doar o cheie dupa vhost. Ar fi si alte avantaje legate de alte idei crete, dar sa nu divaghez.
Nu mi-e insa foarte clar cum fac cu arhivarea logurilor. In primul rand, n-am idee care ar fi raportul de marime intre tabela (sa zicem MyISAM, dar sunt curios sa aud alte alternative mai avantajoase) si fisiere plaintext. In al doilea rand, rotirea logurilor e un lucru inevitabil si va trebui implementata cumva si in situatia asta. Nu prea-mi place sa arunc datele in direct in /dev/null, asa ca as gasi un cutoff decent (sa zicem ca bitii mai vechi de 1 luna ma intereseaza doar in cazuri rare) si as muta datele alea sub o forma cu biti mai ieftini de stocat si mai scump de accesat, adica mutate periodic recordurile vechi intr-o tabela care se arhiveaza ... cumva. Cumva-ul traditional e mysqldump comprimat, dar asta ar insemna ca pot accesa datele alea doar cu gunzip si restore, which kinda sucks. Adica as vrea sa am o functie, sa-i zicem big_select care se plimba incet prin toate arhivele vechi si extrage rapoarte pe termen lung. O idee "inhouse" ar fi sa tin tabelele vechi in cate un sqlite comprimat care sa poata fi din cand in cand intrebate de sanatate. Alta idee, mai web3.0, ar fi arhivarea in ceva gen SimpleDB sau BigTable intr-unul din clouds (in masura in care nu costa o mana si un picior), in definitiv, e o problema de map/reduce.
As fi tare curios sa aflu experientele altora, ca sa nu reinventez roti patrate.
Update: Se pare ca nevoile imediate mi le rezolva mod-log-sql (no idea yet ce inseamna ca performanta, va trebui sa fac niste teste in viitorul indepartat), iar pentru solutii de arhivare on-site o sa iau in considerare myisampack sau archive engine si mai vedem ce se intampla cu spatiul. Mersi lorin si zamolxes pt. sugestii.
4 Responses to “Database logging”
July 30th, 2009 at 11:58 pm
Daca o sa ai vreodata nevoie de ceva super mare, Oracle face asta cu table partitions (hot, warm, cold data). L-am vazut facand asta ca DB al unui produs de am apucat si eu sa-l butonez o data.
July 31st, 2009 at 12:04 am
Mersi. Ma interesa mai mult ca exercitiu de optimizare si ca unealta pentru alte scamatorii de scalabilitate si disponibilitate pe care le am in cap. Daca ai la indemana ceva documentatie despre best practices de ‘racire a datelor’, ma intereseaza.
July 31st, 2009 at 9:50 am
Dacă tu vrei logurile în DB doar ca sa te dai prin ele cu selecturi, eu zic să lași sitemul de logging așa cum e. Logurile care te interesează le parsezi și scrii în DB ce vrei (eventual tot) = un script/cron care ia info din logs și scrie în DB pentru analiză ulterioară (poate să șteargă la rulare ce e mai vechi de X secunde).
July 31st, 2009 at 10:10 am
Hi Liviu!
Oricum logurile sunt prin definitie ceva in care doar te dai cu selecturi, altceva nu prea ai ce face cu ele. Dar una din chestii ar fi ca mi se pare cam barbarie sa fac datele flat ascii dupa care sa le iau iarasi la puricat cu regexpuri and stuff. Second ar fi ca asa as pune la gramada tot fara sa-mi bat capul per vhost (sau physical host). Si third ca na, e cool
.
Am pus mod-log-sql de proba si acum studiez scheme de arhivare a DB-ului din fast-insert tables in fast-select tables si mai departe in cheap storage tables.