Is plaintext inlezen net zo snel/langzaam als met een DB ?

[Koffie]

Beetje rare vraag/topic titel.

Ik heb een script wat logfiles inleest. Logfiles groeien nogal snel, en een file van ca. 4Mb is redelijk standaard ipv uitzondering.

Als ik het script nou in elke regel naa *iets* laat zoeken tot EOF, dan duurt dat redelijk lang.
Echter, als ik nou dat helebestand in een MySQL DB gooi, en elke regel op een nieuw record.
Zou dat dan sneller gaan, of even snel

Ik denk persoonlijk even snel, omdat het aantal regels hetzelfde blijft.

We gaan hier overigens ervan uit dat het de inhoud in het bestand dan wel in de DB identiek zijn, en het hele zooitje op dezelfde server uitgevoerd wordt.

[whoami]

De DB aanpak zal imho sneller gaan mits je goeie indexen op je tabellen legt.
Door die indexen kan het DBMS al gaan 'knippen' in de records welke hij wel en welke hij niet moet hebben.
Bij een flat textfile moet je sequentieel door het bestand lopen en iedere regel bekijken. Daar heb je geen indexen.

Als je natuurlijk slechts 1 veld hebt per record, dan weet ik niet of het nog zoveel sneller zal zijn..... Ff uitproberen misschien?

[ Voor 19% gewijzigd door whoami op 31-03-2003 13:43 ]

[Verwijderd]

Ik weet voor 99,9% zeker dat het vanuit een database sneller gaat, een database staat continu geopend waardoor het inlezen stukken sneller gaat dan zelf het lees/schrijfwerk te doen.
Tevens heb je meer functies, b.v. selecteren op iets wat je wil(gezien logs, dus select op ip en derlijken), probeer dat maar eens te doen vanuit een tekstfile, dit kost veel meer aan tijd.

Anders maak een benchmarkje:

10000 recors in een ascii file en 10000 in een mysql db, kijk daarna hoelang het duurt via de loadtime van de pagina, ik denk dat mysql het wint

whoami schreef op 31 March 2003 @ 13:41:
De DB aanpak zal imho sneller gaan mits je goeie indexen op je tabellen legt.
Door die indexen kan het DBMS al gaan 'knippen' in de records welke hij wel en welke hij niet moet hebben.
Bij een flat textfile moet je sequentieel door het bestand lopen en iedere regel bekijken. Daar heb je geen indexen.

Als je natuurlijk slechts 1 veld hebt per record, dan weet ik niet of het nog zoveel sneller zal zijn..... Ff uitproberen misschien?

idd, het indexen scheelt veel tijd, dat kan niet makkelijk vanuit een textfile(kan wel, maar dat kost een database om de index in op te slaan).

[offtopic]
bah net te traag met mijn reactie

[ Voor 41% gewijzigd door Verwijderd op 31-03-2003 13:45 ]

[Koffie]

Domme vraag .. hoe index ik

Overigens, KOD, ja gaat er nu wel vanuit dat ik dan voor elke regel diverse colums heb, dus eentje voor de IP adressen, eentje voor de files e.d.

Ik bedoel in deze vergelijking dus dat elke volledige regel in 1 colum/cell staat.
Overigens ook met het oog op het feit, die logfiles alleen maar groter worden.

=[EDIT]=

Als je natuurlijk slechts 1 veld hebt per record, dan weet ik niet of het nog zoveel sneller zal zijn.....

Dat bedoel ik dus uit te leggen

[ Voor 21% gewijzigd door Koffie op 31-03-2003 13:51 ]

[whoami]

Verwijderd schreef op 31 March 2003 @ 13:43:
idd, het indexen scheelt veel tijd, dat kan niet makkelijk vanuit een textfile(kan wel, maar dat kost een database om de index in op te slaan).

[offtopic]
bah net te traag met mijn reactie

Dan is het geen plaintext file meer , maar een geindexeerde file.

[avon]

Geef is een overzicht van de velden!, kunnen we normaliseren & testen!

[ Voor 9% gewijzigd door avon op 31-03-2003 13:55 ]

[Verwijderd]

whoami schreef op 31 maart 2003 @ 13:54:

[...]


Dan is het geen plaintext file meer , maar een geindexeerde file.

inderdaad, dan heb je al een gedeelte van het werk gedaan dus valt het benchmarken van de file tegenover de mysqldb niet meer te checken... imho

maar denk dat wanneer je een log in een db zet je inderdaad veel snellere queries kunt draaien dan op een flatfile, ook omdat de mysql db een vulvuldig gelezen bestand in het geheugen zet...

[Koffie]

AvOn schreef op 31 March 2003 @ 13:54:
Geef is een overzicht van de velden!, kunnen we normaliseren & testen!

Ik heb nog helemaal geen DB, omdat ik me afvraag of het nut heeft om een logfile erin te vrotten.

Echter zoals whoami ook al opmerkte, plaats je dan elke volle regel in 1 enkel record.
Als voorbeeld kun je een apach log-file nemen bijvoorbeeld.

[ Voor 28% gewijzigd door Koffie op 31-03-2003 13:59 ]

[whoami]

Koffie schreef op 31 March 2003 @ 13:58:
[nohtml]
[...]
[/nohtml]


Echter zoals whoami ook al opmerkte, plaats je dan elke volle regel in 1 enkel record.
Als voorbeeld kun je een apach log-file nemen bijvoorbeeld.

't Is te zien hoe je logfile eruitziet. Welke gegevens log je ed?
(Heb hier geen apache, kan er dus ook geen logfile van zien. )

[Verwijderd]

Koffie schreef op 31 March 2003 @ 13:58:
Ik heb nog helemaal geen DB, omdat ik me afvraag of het nut heeft om een logfile erin te vrotten.

ja en nee, tis net wat je wilt, wil je vaak je log file uitlezen en of er queries op los laten dan jah zo niet dan zou ik het dus gewoon met een klein scriptje doen..

Echter zoals whoami ook al opmerkte, plaats je dan elke volle regel in 1 enkel record.
Als voorbeeld kun je een apach log-file nemen bijvoorbeeld.

als je meer gegevens wilt combineren zou je het beste de logs kunnen splitten in regels en de regels in onderdelen, zodat je kan kijken welke url de meeste hits heeft gehad etc etc

tabel id.
datum
tijd
url
ip
whatever

[avon]

Dat ligt aan je velden, normaliseren schrijft een aantal stappen voor
om bv afhankelijkheden er uit te halen en in een aparte tabel te stoppen.

Natuurlijk kan je in de een tabel alle velden stoppen maar dat is vaak niet het beste
(hoe heette die term ook alweer, niet inconsitentie maar ... r nog wat.)

[Verwijderd]

whoami schreef op 31 maart 2003 @ 14:00:

[...]


't Is te zien hoe je logfile eruitziet. Welke gegevens log je ed?
(Heb hier geen apache, kan er dus ook geen logfile van zien. )

code:

127.0.0.1 - - [16/Mar/2003:20:37:24 +0100] "GET / HTTP/1.1" 200 3116
127.0.0.1 - - [16/Mar/2003:20:37:28 +0100] "GET /babes HTTP/1.1" 301 317
127.0.0.1 - - [16/Mar/2003:20:37:47 +0100] "GET /forum/forum.php HTTP/1.1" 200 375
127.0.0.1 - - [16/Mar/2003:20:37:47 +0100] "GET /forum/template/newforum.css HTTP/1.1" 200 1725
127.0.0.1 - - [16/Mar/2003:20:37:47 +0100] "GET /forum/template/forum.js HTTP/1.1" 200 15772
127.0.0.1 - - [16/Mar/2003:20:37:47 +0100] "GET /forum/template/off.gif HTTP/1.1" 200 237
127.0.0.1 - - [16/Mar/2003:20:37:50 +0100] "GET /babes HTTP/1.1" 301 317
127.0.0.1 - - [16/Mar/2003:20:38:52 +0100] "GET /picstore HTTP/1.1" 301 320
127.0.0.1 - - [16/Mar/2003:20:39:20 +0100] "GET /sig2datnet/layout/script.js HTTP/1.1" 200 769
127.0.0.1 - - [16/Mar/2003:20:39:20 +0100] "GET /sig2datnet/layout/style.css HTTP/1.1" 200 3686
127.0.0.1 - - [16/Mar/2003:20:39:20 +0100] "GET /sig2datnet/layout/preload.js HTTP/1.1" 200 2493
127.0.0.1 - - [16/Mar/2003:20:39:20 +0100] "GET /sig2datnet/layout/images/lower_left.gif HTTP/1.1" 200 109
127.0.0.1 - - [16/Mar/2003:20:39:20 +0100] "GET /sig2datnet/layout/images/cleardot.gif HTTP/1.1" 200 43
127.0.0.1 - - [16/Mar/2003:20:39:20 +0100] "GET /sig2datnet/layout/images/search_go.gif HTTP/1.1" 200 232
127.0.0.1 - - [16/Mar/2003:20:39:21 +0100] "GET /sig2datnet/layout/images/lower_right.gif HTTP/1.1" 200 110
127.0.0.1 - - [16/Mar/2003:20:39:21 +0100] "GET /sig2datnet/layout/images/upper_left.gif HTTP/1.1" 200 109
127.0.0.1 - - [16/Mar/2003:20:39:21 +0100] "GET

[avon]

daar is wel een leuke db van te maken!, die sneller is dan plain kwa queries.

[ Voor 9% gewijzigd door avon op 31-03-2003 14:05 ]

[Soultaker]

Als je op een specifiek onderdeel zoekt (een volgnummer, code of IP-adres bijvoorbeeld) kan een databaseserver de bijbehorende regels snel vinden, wanneer je voor dat onderdeel een apart veld hebt gedefinieerd en je er een index op hebt gezet.

Als je je regels gewoon in een enkel TEXT-veld propt, zal de database eigenlijk geen voordelen bieden. Dan kun je net zo goed je plaintext file blijven gebruiken, in combinatie met (bijvoorbeeld) grep.

Sowieso haal je de winst er pas uit als je zo vaak queries op je database doet, dat de extra overhead van het up to date houden van de database (nieuwe log files invoeren) terugverdient wordt door de verhoogde efficientie van de queries. Als je direct in de database kan loggen is dat natuurlijk veel beter, maar dat kan niet altijd (maar Apache kan dat bijvoorbeeld wel).

[Verwijderd]

Soultaker schreef op 31 maart 2003 @ 14:04:
Als je op een specifiek onderdeel zoekt (een volgnummer, code of IP-adres bijvoorbeeld) kan een databaseserver de bijbehorende regels snel vinden, wanneer je voor dat onderdeel een apart veld hebt gedefinieerd en je er een index op hebt gezet.

idd de onderdelen onderbrengen in velden in de database

Als je je regels gewoon in een enkel TEXT-veld propt, zal de database eigenlijk geen voordelen bieden. Dan kun je net zo goed je plaintext file blijven gebruiken, in combinatie met (bijvoorbeeld) grep.

Yep, dat denk ik ook, want dan nog moet je alle regels doorlezen en er regexjes ofwhatever overheen halen wil je de juiste info er uitkunnen halen.

Sowieso haal je de winst er pas uit als je zo vaak queries op je database doet, dat de extra overhead van het up to date houden van de database (nieuwe log files invoeren) terugverdient wordt door de verhoogde efficientie van de queries. Als je direct in de database kan loggen is dat natuurlijk veel beter, maar dat kan niet altijd (maar Apache kan dat bijvoorbeeld wel).

[/quote]

dus voor 1 malig gebruik kan je beter een extern scriptje schrijven zonder mysql bladediebla.

Psies wat ik dacht maar anders heb verwoord (zoals normaal )

[whoami]

Je kan dus een tabel maken met 3 kolommen:
1 kolom voor het ip adres
1 kolom voor de datetime
en 1 kolom voor de actie.

Je legt dan indexen op ipadres en datetime kolom.
Als je dan wilt zoeken op ip adres of in een range van datums, dan zal dat echt snel gaan.

[Verwijderd]

whoami schreef op 31 March 2003 @ 14:09:
Je kan dus een tabel maken met 3 kolommen:
1 kolom voor het ip adres
1 kolom voor de datetime
en 1 kolom voor de actie.

Je legt dan indexen op ipadres en datetime kolom.
Als je dan wilt zoeken op ip adres of in een range van datums, dan zal dat echt snel gaan.

en natuurlijk 1 kolom voor de respons van de server en 1 voor de grote van het bestand

[Verwijderd]

whoami schreef op 31 maart 2003 @ 13:54:

[...]


Dan is het geen plaintext file meer , maar een geindexeerde file.

doh

Verwijderd schreef op 31 March 2003 @ 13:57:
[...]

inderdaad, dan heb je al een gedeelte van het werk gedaan dus valt het benchmarken van de file tegenover de mysqldb niet meer te checken... imho

maar denk dat wanneer je een log in een db zet je inderdaad veel snellere queries kunt draaien dan op een flatfile, ook omdat de mysql db een vulvuldig gelezen bestand in het geheugen zet...

nee je moet gewoon KAAL testen, ik gaf alleen een voorbeeld, dus 100% db en 100% file.

Even een voorbeeldje(van een bezoekersteller princype):

Table User_IP:
id autoinc bigint 11
ip varchar 15 ( of ip1 tm ip4 int 3 )
hitsbyip int 11

Table Pages_IP:
id autoinc bigint 11
ip varchar 15 ( of ip1 tm ip4 int 3 )
page_url varchar 150
histbyip int 11


Je kijkt of de gebruiker vanaf dit ip al eerder op je site is geweest, zoniet:
Gebruiker met ip 1.2.3.4 opent voor het eerst pagina index.php, je maakt in
user_ip een row aan met het ip en zet hits op 1.
zowel:
Je telt hotsbyip met 1tje omhoog(UPDATE user_ip hitsbyip = hitsbyip + 1 WHERE ip = jeip).

Je kijkt of de gebruiker al op deze pagina geweest is, zoniets:
Je maakt een row aan, met ip + pagina + hits op 1
zowel:
hitsbyip 1 omhoog.

Ik zou dan wel iets maken dat je het voor 1 maand laat staan, zijn de waardes dan te oud dan automatisch toevoegen in een total table, dus waardes samenvoegen(dan heb je per maand maar 1 row, maar dit moet je alleen doen met waardes die ouder zijn dan 1 maand, zodat je je stats van afgelopen maand altijd kan zien(gezien hackers enzo, zodat je ip's niet verliest).

[offtop]
ben niet helemaal helder(dit weekend lan gehad), klopt toch wat ik zeg hé

edit:
ben traag

[Koffie]

Als je je regels gewoon in een enkel TEXT-veld propt, zal de database eigenlijk geen voordelen bieden. Dan kun je net zo goed je plaintext file blijven gebruiken, in combinatie met (bijvoorbeeld) grep.

En dat vroeg ik me dus af

Initieel zal het dus weinig verschil maken, tenzij je bij het invullen van je DB meteen aparte veldjes gaat gebruiken voor delen van elke zin.

dat is dus wat ik me afvroeg; als ik dus meteen van begin af aan de DB goed opzet en vul, zal er zeker snelheids winst te behalen zijn tov elke keer een plaintext file doorlezen.