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

Oliver Bandel oliver at first.in-berlin.de
Do Aug 9 20:18:02 CEST 2007


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

> 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 :)
[...]
> > 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.


Achso. Dateibasierte (also klar lesbar, oder wie?) DB?

Interessant. Sowas hatte ich auch mal gedacht mir zu bauen,
aber wenn es das schon gibt, kann man ja ggf. auf SQLite zurückgreifen,
falls es stabil läuft und auch schnell einsetzbar ist.
Dann würde das ggf. für ganz allgemeine Anwendungen auch Zeit sparen,
diese Code-basis auch einzusetzen.

Hängt aber wohl vom Anwendungsfalle ab.


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

Hmhhh, und warum dann nicht mit MySQL oder PostgreSQL verwenden?
Ist SQLite wirklich wesentlich mehr lite?


Bei apalog habe ich (vor dem Aufruf der Compile-Scripte,
also wenn man aus den ocamllex- und ocamlyacc-Files noch
nicht die entsprechenden *.ml* Files generiert hat)
folgendes:


oliver at siouxsie2:/tmp/apalogretieve-0-9$ wc *.ml*
   69   294  2103 logentry.ml
   32   120   723 logentry.mli
   28   120   688 loglex.mll
   67   218  1803 main.ml
   13    54   342 querytypes.ml
   56   186  1400 readlog.ml
  559  1792 17734 retrievegrammar.ml
  216   750  4454 retrievegrammar.mly
   70   250  2052 retrievelex.mll
 1110  3784 31299 insgesamt



Nach dem Kompilieren habe ich dann als Codebasis:

 3129   6314 155394 insgesamt

und das Binary hat 356871 Bytes.

Ich weiss nicht, wieviel Krams ich für SQLite installieren muesste und dann
an Code noch dazu kommt.
So wie ich das sehe, müsste man da ja wohl mit C arbeiten.
Dann muss man ja so viel tippen ;-) jedenfalls wenn es sauber
programmiert sein soll. ;-)




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

Ist wohl anzunehmen, ja.


>
> > 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 ;)


Ich wollte mit dem Kontrast-Beispiel nur mal das Bild schärfen. :)


>
> > 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 ;)

Lümmel! ;-)


>
> > 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,
[...]

Ach so. Na, habe ich mich wieder unnötig angepisst gefühlt ;-)



> alles was ich meinte war ja, dass dein
> Programm mit SQLite außer der Syntax nichts gemeinsam hat.

Ach so. Naja, stimmt schon.

Die Syntax war ja "inspired by SQL", der Anwendungsfall ein ganz spezieller
(eben Logfiles auslesen) und kein allgemeiner wie bei SQLite und es sollte
ein Stand-Alone-Tool sein, das man mal eben schnell installieren kann,
wenn man in der Webalizer-Statistik nix mehr sieht (Wald und Bäume und so)
und sich mit grep bereits die Karten gelegt hat.


Man könnte das Teil auch domainspezifisches
grep mit ReadEvalPrintLoop und SQL-inspirierter
Syntax nennen ;-)


Gruß,
   Oliver



Mehr Informationen über die Mailingliste linux-l