Daten einer Zeitspanne ohne < > ermitteln

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Benutzeravatar
Michael Schneider
User
Beiträge: 567
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Bremen
Kontaktdaten:

Beitragvon Michael Schneider » Dienstag 22. August 2006, 13:56

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
Diese Nachricht zersört sich in 5 Sekunden selbst ...
Benutzeravatar
Joghurt
User
Beiträge: 877
Registriert: Dienstag 15. Februar 2005, 15:07

Beitragvon Joghurt » Dienstag 22. August 2006, 20:12

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

Beitragvon BlackJack » Dienstag 22. August 2006, 23:17

Was ist mit `gadfly`? Reine Python DB die sogar SQL kann.
Benutzeravatar
Michael Schneider
User
Beiträge: 567
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Bremen
Kontaktdaten:

Beitragvon Michael Schneider » Mittwoch 23. August 2006, 06:28

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
Diese Nachricht zersört sich in 5 Sekunden selbst ...
Benutzeravatar
Michael Schneider
User
Beiträge: 567
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Bremen
Kontaktdaten:

Beitragvon Michael Schneider » Samstag 26. August 2006, 17:53

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
Diese Nachricht zersört sich in 5 Sekunden selbst ...
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Samstag 26. August 2006, 18:04

Michael Schneider hat geschrieben: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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
Michael Schneider
User
Beiträge: 567
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Bremen
Kontaktdaten:

Beitragvon Michael Schneider » Samstag 26. August 2006, 20:34

gerold hat geschrieben: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
Diese Nachricht zersört sich in 5 Sekunden selbst ...
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Samstag 26. August 2006, 20:50

Michael Schneider hat geschrieben:Darum GADFLY!

Hi Michael!

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

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs

Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
Hannes-Spz
User
Beiträge: 123
Registriert: Sonntag 7. August 2005, 22:42

Beitragvon Hannes-Spz » Samstag 26. August 2006, 21:24

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 :oops: ; lg hannes;
Benutzeravatar
Michael Schneider
User
Beiträge: 567
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Bremen
Kontaktdaten:

Beitragvon Michael Schneider » Sonntag 27. August 2006, 11:01

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
Diese Nachricht zersört sich in 5 Sekunden selbst ...
Benutzeravatar
Joghurt
User
Beiträge: 877
Registriert: Dienstag 15. Februar 2005, 15:07

Beitragvon Joghurt » Sonntag 27. August 2006, 11:10

Michael Schneider hat geschrieben: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. :P

SCNR
Benutzeravatar
Michael Schneider
User
Beiträge: 567
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Bremen
Kontaktdaten:

Beitragvon Michael Schneider » Sonntag 27. August 2006, 12:11

Hi Joghurt!
Joghurt hat geschrieben:
Michael Schneider hat geschrieben: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. :P
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...? :D

Grüße,
Michael
Diese Nachricht zersört sich in 5 Sekunden selbst ...

Wer ist online?

Mitglieder in diesem Forum: Bing [Bot]