[linux-l] Announcement: apalogretrieve (Apache Logs with SQL-like interface)

[Nico Golde]

Hallo Oliver,

* Oliver Bandel <oliver at first.in-berlin.de> [2007-08-09 15:09]:
> Zitat von Nico Golde <nion at gmx.net>:
> > * Oliver Bandel <oliver at first.in-berlin.de> [2007-08-09 14:35]:
[...] 
> > Wenn ich dein Programm nicht falsch verstanden habe, packst
> > du die Daten ja nicht wirklich in ein SQLite file,
> [...]
> 
> Es ist ja auch nicht SQLite im Spiel.

Gut, das meinte ich ja :)

> > sondern
> > wertest den Query aus und durchsuchst dann die Datei oder
> > (ich habe es nicht getestet)?
> 
> Ich lese / parse die Query und dann lese ich die Log-Datei.
> ich lese nicht die Logdatei einmal ein und arbeite dann auf
> dem zeug im Ram. InsoFern wäre es bei vielen Queries natürlich langsamer,
> als wenn man das Logfile einmal einliest und dann nur im RAM arbeitet.
> Andererseits muss man nicht massenweise uninteressante Einträge
> ins RAM saugen, wenn man eh nach etwas bestimmten sucht.

Jo klar, so ein Logfile kann ja ohne logrotate auch mal ein 
bisschen größer werden.
[...] 
> > Was ich meinte ist, dass das
> > Parsen der Datei und speichern in SQLite vermutlich
> > einfacher ist,
> 
> SQLite habe ich noch nicht benutzt.
> Aber wenn ich schneller etwas neu schreibe, als ich ins Einarbeiten
> einer vorhandenen Lösung brauche, dann schreibe ich es eben neu.

Kenn ich irgendwoher :)

> ich dachte SQLite ist eine Lib, aber vielleicht habe ich da
> falsche Vorstellungen dazu.

Ja ist es ja auch und mit der Lib kannst du SQL(lite) 
queries auf eine Datenbank machen, die in Form einer Datei 
existiert.

> Dennoch müsste man ja die entsprechenden Schnittstellen zum Logfile
> auch selber schreiben. Ob das dann letztlich arbeit spart?!

Naja das ist ein zeilenweises Abarbeiten und in Inserts
verpacken, sollte nicht viel sein.

[...] 
> > als das was du gemacht hast und man eine
> > schnellere Reaktionszeit bei Queries erzielt, als wenn du
> > jede Zeile einzeln checkst.
> 
> Auch SQLite muss ja alle Zeilen (bzw. Eintzräge)
> "einzeln checken".
> 
> Oder worauf willst Du hinaus?

Ja beim Einlesen, sonst nicht. Ich weiß nicht, wie SQLite 
intern funktioniert aber Irgendwas in der Art von 
Hashtabellen oder etwas Ähnliches werden die wohl 
hoffentlich verwenden.

> Ich optimiere erst, wenn es einen Grund dafür gibt.
> 
> ich weiss, es gibt Leute, die bekommen ihre Software nicht in einen
> lauffähigen Zustand, weil sie, bevor sie die Funktionalität
> fertiggestellt haben, bereits auf Speed optimieren.

Man muss ja nicht gleich von einem Extrem ins Andere ;)

> Das kann man IMHO im Nachhinein.

Ja klar, das sollte auch nicht heißen, dass ich deine 
Software total Schrott finde ;)

[...]
> Ist ja GPL'ed, kann man selber machen, wenn man es so haben will.

Bah, das ist ML, das fass ich nicht an ;)

> Für einen großen provider macht das vielleicht Sinn.
> Naja, sich dann an mich wenden oder machen es eben selbst. ;-)
> 
> Ciao,
>    Oliver
> 
> P.S.: Ich habe an dem Teil an einigen Tagen mal Abends ein bisschen gebaut,
>       und SQLite's Historie reicht, wenn man mal in
>          http://www.sqlite.org/changes.html
>       rein schaut, auf das Jahr 2000 zurück. Und wieviele haben da dran herum
>       gecodet?  Da vergleichst Du also auf vielfache Weise Sachen, die so
>       nicht vergleichbar sind: Einersits die bereits eingeflossene
>       Entwicklungszeit, und auch die Begehrlichkeiten, die da drin stecken.
[...] 
Sorry, aber so ganz versteh ich nicht, was du meinst. Ich 
vergleiche nicht dein Programm mit SQLite bzw nicht in 
deinem Sinne, alles was ich meinte war ja, dass dein 
Programm mit SQLite außer der Syntax nichts gemeinsam hat.
Gruß Nico
-- 
Nico Golde - http://ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: nicht verfügbar
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20070809/4b42f73d/attachment.sig>