Daten einer Zeitspanne ohne < > ermitteln

[Michael Schneider]

Hi Jens,

vielen Dank, mit dem Code müsste es gehen. Ich hatte schon resigniert, weil ich davon ausging, dass ich datetime nur als binary bekommen könnte.

Nochmal zu KirbyBase: ich habe den Code mal überflogen. Wie es aussieht ist die DB zwar sehr komfortabel, liest aber auch jedes mal den gesamten Dateiinhalt ein und zerpflückt ihn.

Grüße,
Michael

[Joghurt]

Kannst du deinem Admin nicht fragen, ob der pysqlite für dich installiert? Ist auch kein Clent-Server-System, so dass es keine externen Sicherheitslücken öffnet. Und wenn du ihm die Vorteile nennst, vielleicht hat er ein Einsehen.

Ansonsten soll er dickere Hardware beschaffen, die Wahl hat er

[BlackJack]

Was ist mit `gadfly`? Reine Python DB die sogar SQL kann.

[Michael Schneider]

Hi BlackJack,

gadfly? Werde ich mir gleich mal ansehen.

Einen Admin zu erreichen, der was ausrichten kann, benötigt bei uns erfahrungsgemäß mindestens zwei Anträge, fünf Formulare und gute Französischkenntnisse . Aber versuchen kann man vielleicht auch das mal.

Grüße,
Michael

[Michael Schneider]

Hi,

gadfly funktioniert bislang einwandfrei unter python 2.2. Ich habe mich jetzt für die Umsetzung damit entschieden. So kann ich das Zeitcheckproblem direkt mit der SQL-Formulierung:

"where ZEITPUNKT between STARTZEIT and ENDZEIT"

erschlagen. Nochmals danke, BlackJack!

Und natürlich allen, die ihren hilfreichen Senf dazu gegeben haben.
Michael

[gerold]

gadfly funktioniert bislang einwandfrei unter python 2.2.

Hi Michael!

Ich kenne *KirbyBase* ja nicht, deshalb interessiert es mich um so mehr, ob du einen Performanceschwund feststellen konntest, oder ob es sonst einen Grund für dich gab, warum du KirbyBase nicht verwendet hast.

lg
Gerold

[Michael Schneider]

Ich kenne *KirbyBase* ja nicht, deshalb interessiert es mich um so mehr, ob du einen Performanceschwund feststellen konntest, oder ob es sonst einen Grund für dich gab, warum du KirbyBase nicht verwendet hast.

Hi Gerold!

Mir hat anfangs gefallen, dass KirbyBase keine In-Memory Datenbank ist (eigentlich ist es eher eine komfortable Dateiverwaltung). Das wäre gut bei einem kleinen Arbeitsspeicher, aber mit 4 Gigabyte ist das eher unproblematisch.

Beim Vergrößern oder Löschen von Einträgen werden die ganzen Zeilen mit Spaces aufgefüllt, so dass die Datei öfters mal defragmentiert werden muss. Da die Daten nicht im Speicher verwaltet werden gehe ich davon aus, dass die Datei bei jeder Suche neu gelesen werden muss und ich habe nicht probiert was passiert, wenn man Strings mit Zeilenumbruch oder anderen Sonderzeichen verwendet (ich gehe davon aus, dass die nicht maskiert werden). Die Daten werden im ASCII Textformat gespeichert, auch die Zahlen! Das braucht nicht nur mehr Speicher als ein 4-Byte Int sondern bedeutet auch, dass die Zeilen bei jedem Parsen zerlegt (Pipe als Trennzeichen) und in die entsprechenden Typen umgewandelt werden müssen.

Und last but not least war die API (zumindest vergleichsweise) kompliziert. Nicht, dass ich bis Anfang dieser Woche auch nur einen Schimmer von SQL hatte. Aber der jeder SQL-Kundige kommt intuitiv spielerisch mit der API von Gadfly zurecht. Das fand gerade mein Chef vorteilhaft. Darum GADFLY!

Die Performance von KirbyBase werde ich aber nochmal im Vergleich zu Gadfly testen.

Grüße,
Michael

[gerold]

Darum GADFLY!

Hi Michael!

Vielen Dank für deinen Bericht. Damit hast du etwas Licht in die Sache gebracht.

lg
Gerold

[Hannes-Spz]

hi!
ich mag davon nicht allzuviel ahnung zu haben, aber vl. kann es ja IRGENDWAS bringen:
was wäre, wenn man die dateien auf 5 unterteile aufteilen könnte und dann jeweils so viele neue threads started, die immer in einem abschnitt nach den re's suchen?
dann ist zwar mindestens genausoviel der prozessor belastet, jedoch dürften die ergebnisse, da sie ja parallel erstellt werden, schneller kommen...bzw. könnte man sich sogar dadurch VL. erlauben, die ganze datei zu durchkramen .. und bei 4gigabyte....

wie gesagt: ist nur nen vorschlag ; lg hannes;

[Michael Schneider]

Hi Hannes,

multi-threading ist ein guter Ansatz, wenn man beispielsweise auf Ereignisse wartet, wobei Festplatte und CPU Däumchen drehen.
Leider hilft es nichts, einen Prozess mit (fast) 100% CPU-Nutzung auf 5 threads zu verteilen, da die sich auch nur die vorhandene Performance aufteilen können, so dass jeder idealerweise 20% bekommt.

Bevor man aber irgendwas mit REs machen kann, muss die Datei in den Arbeitsspeicher. Auch hier hilft es nichts, die Datei aufzuteilen und gleichzeitig einzulesen. Du hast weniger Leseleistung (ist wie Lesen von fragmentierten Daten), beanspruchst aber mehr Filehandler und Dein Lesekopf veranstaltet nen Breakdance, wenn er zwischen den Sektoren umherspringt.

Und ich kenne keine Funktion, die den Dateiinhalt durchsuchen könnte, ohne ihn vorher von der Platte einzulesen.

Übritens umfasst meine Datenbankstruktur derzeit 38 Tabellen, inklusive LUTs und Zwischen-LUTs (look-up tables) für einige m:n-Beziehungen.

Grüße,
Michael

[Joghurt]

Und ich kenne keine Funktion, die den Dateiinhalt durchsuchen könnte, ohne ihn vorher von der Platte einzulesen.

Doch! Das macht "CIA_search_for". Mit der selben Funktion wurden damals erfolgreich Massenvernichtungswaffen im Irak gefunden.

SCNR

[Michael Schneider]

Hi Joghurt!

Und ich kenne keine Funktion, die den Dateiinhalt durchsuchen könnte, ohne ihn vorher von der Platte einzulesen.

Doch! Das macht "CIA_search_for". Mit der selben Funktion wurden damals erfolgreich Massenvernichtungswaffen im Irak gefunden.
SCNR

Ich gebe es ungern zu, aber hier war ICH offenbar falsch informiert.

Aber es gäbe tatsächlich eine Möglichkeit, die Abfrage per multithreading zu beschleunigen: ich teile die Datei in 3 gleich große Teile und verwalte 2 der Teile auf anderen Workstations. Dann kann ich bei einer Abfrage auf der eigenen Platte suchen und gleichzeitig die Daten der anderen beiden Workstations per 100 Mbit-Netzwerk reinholen. Dann komme ich auf fast 20 MByte/s. Aber ob das der BUS mitmacht...?

Grüße,
Michael