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

[Oliver Bandel]

Zitat von Nico Golde <nion at gmx.net>:

> Hallo Oliver,
>
> * Oliver Bandel <oliver at first.in-berlin.de> [2007-08-09 14:35]:
> > Zitat von Nico Golde <nion at gmx.net>:
> > > * Volker Grabsch <vog at notjusthosting.com> [2007-08-09 13:11]:
> > > > On Thu, Aug 09, 2007 at 01:52:40AM +0200, Oliver Bandel wrote:
> > > > > Man kann dann zum Beipiel sowas hier machen:
> > > > >
> > > > >  select date, host, referrer, request from "access.log" where request
> > > like
> > > > > "%PROFIL%";
> > > >
> > > > Klingt interessant. Quasi wie SQLite, nur read-only und mit
> > > > menschenlesbaren Dateien.
> > >
> > > Ja nur, dass man die Vorteile von SQLite nämlich schnelle
> > > Zugriffe nicht hat ;)
> >
> > Kannst Du mir das mal erläutern, was Du meinst?
> > Welche schnellen Zugriffe hat man wobei womit nicht?
>
> 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.


> 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.
Webalizer z.B. macht Massenabfertigung und man findet nicht gezielte
Einträge, sondern hat statistische Aussagen / einen Überblick.
Genau das sollte ja dieses Tool anders machen: man sucht eine
bestimmte Art von Einträgen gezielt heraus und daher braucht man
auch nicht alles im RAM lagern.

Das wäre aber auch möglich; kann man ja zwischenspeichern,
wenn man es mag.

Wer mit 10 GB Logfiles arbeitet und noch nicht genau weiss, was er
sucht, fährt dann bestimmt besser, alles in den RAM zu lesen,
aber auch nur wenn genug RAM verfügbar ist ;-)






> 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.

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

Dennoch müsste man ja die entsprechenden Schnittstellen zum Logfile
auch selber schreiben. Ob das dann letztlich arbeit spart?!
Nur, wenn man viele derartige Projekte macht, weil man dann
SQLite bereits kennt. Ansonsten ist der EInarbeitungsaufwand zu groß.
Davon abgesehen macht mir Programmieren auch Spaß (au weia! ;-)).



> 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?


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.

Das kann man IMHO im Nachhinein.

Sollte aus irgend einem Grund der bisherige Ansatz zu langsam sein,
würde ich dei Daten eben zwischensppeichern, ggf. auch schon vorsortieren,
so daß Queries schneller sind.

Aber dies schon vorher zu machen ohne Grund?
Unsinn.

Ist ja GPL'ed, kann man selber machen, wenn man es so haben will.
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.
      Wenn es so auf speed getrimmt ist, dann sicherlich, weil es bestimmte
      Anwendungsfälle gab. Und wenn das wirklich eine DB-Engine ist, dann
      ist das vollkommen was anderes, als ich überhaupt vor hatte zu bauen.
      Also der Anwendungsfall ist ein anderer.
      Sonst hätte man ja auch einen konverter bauen können, der Apache-Logs in
      SQL-statements umbaut und das in MySQL oder PostgreSQL laden können
      und das dann benutzen.
      Mir gng es aber nur um ein Interface, das mir das Auslesen der Logs
      vereinfacht. Ergo ein einfacher Umsetzer von SQL-like Query auf das
      Logfile. Ich finde es sehr nützlich. Wem es nicht gefällt, der braucht es
      nicht benutzen. Daß Du es aber mit einer vollkommen anderen Ecke
      vergleichst, finde ich seltsam.
      Aber jetzt verstehe ich, was Du mit dem AWK-vergleich meinst.
      Wäre mit einem perl-Script, das ein Log absucht auch nicht anders gewesen.

       Es war NICHT als RDBMS gedacht!