Suche schnelle Offline Datenbank

[Osse]

Hallo,

ich habe ein Programm geschrieben, mit dem es möglich sein soll, Daten von einem Bussystem zu analysieren. Zu diesem Zweck werden die Daten in Delphi eingelesen und in eine .csv Datei gespeichert. Das ist die Bedingung, mit einer .csv Datei zu arbeiten. Mittlerweile ist mir aufgefallen, dass die Datei sehr groß wird, da ich jede ms mit ca. 150 Telegrammen rechen. Naja, besser zu spät als nie merken. Wichtig ist, dass die ankommenden Daten schnell sichtbar sind. Des weitern soll es aber auch möglich sein einen Filter einzuschalten, oder nach bestimmten Einträgen zu suchen. Ich hab jetzt schon mal im Netz gesucht, aber da hab ich ganz viel gefunden von DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, Borland Interbase, Firebird bis hin zu SQL. Hab aber nicht wirklich Ahnung von dem ganzen.

Anforderung:

- muss im .csv Format gespeichert werden
- schnell (wer will das nicht, dass ich die Daten schnell suchen kann ) :zwinker:
- zum einen schnell die ankommenden Daten speichern
- zum anderen eine Suchmaske auf die ankommenden Daten setzten
- nach bestimmten Telegrammen in der Datenbank suchen, auch während weiterhin Daten darin gespeichert werden
- reines Offline programm. Die Daten werden nur lokal auf der Festplatte gespeichert. Es soll kein Onlinezugang bestehen.
- die Datenbank muss so eigenständig sein, dass keine Zusatzprogramme dafür benötigt werden, um Daten zu schreiben oder abzurufen.
Die ganze Datenbankverwaltung muss von meinem Programm gehändelt werden.


Könntet ihr mir etwas empfehlen, oder habt ihr selber schon mal vor einem solchen Problem gestanden??
Gibt es in Delphi fertige Tools, wie siehts mit Quellcode und Tutorials aus (ich bin ja ganz schön gierig :spin: !!!)


Bin für alle Vorschläge offen.

Vielen Dank.

[Sharky]

Hai Osse,

was verstehtst Du unter "muss im .csv Format gespeichert werden"?
In keinem Datenbankserver werden die Daten im CSV-Format gespeichert.

Würde es nicht ausreichen wenn über dein Programm die Möglichkeit besteht die Daten aus der Datenbank in eine CSV zu exportieren?

Mit Bussystemen kenne ich mich jetzt nich aus. Aber ich denke das ein Telegram aus 4-12 Byte besteht?
Dies bedeutet also das pro Sekunde bis zu 1.800.000 Byte gespeichert werden müssen.

Welcher der SQL-Datenbankserver das kann müsste man einmal testen.

Grundsätzlich würde ich in so einem Fall zwei Programme einsetzten.
Programm A empfängt die Telegramme und speichert sie in die Datenbank.
Programm B zeigt die Daten der Datenbank (inkl. Filter und Suchfunktion) an.

[Garfield]

Zweimal dasselbe Thema?

http://www.delphipraxis.net/internal...ct.php?t=54894

[Domo Sokrat]

@Garfield: :shock: Jepp :shock:

Einen Lösungsvorschlag hab' ich da auch gepostet ... :stupid:

[alzaimar]

150.000 recs/Sec schafft kein DB-Server (behaupte ich mal()

Du benötigst sie ja auch nicht, sondern nur am Anfang, während der Testphase.
Eventuell wirst Du einfach pro Minute eine neue Datei anlegen. Damit hast Du schon eine Art 'Bucket Sort' realisiert, kannst also die Werte nach dem Erfassungszeitpunkt schnell finden. Ein Scan mit geeigneten Programmen (ähnlich einem 'grep') wird für Deine Versuche ja ausreichen. Später solltest Du die verdichten und in eine stinknormale DB speichern.

Access z.B. schafft bei mir nur 150 recs/sec. (4 Felder, Datum , 3xInteger) ... 150.000 Recs/sec ist schon eine ziemliche Hürde.

Ich habe mal eine kleine DB mit Bayer-Bäumen geschrieben, die kam so in etwa auf die 100.000 Recs (@ 16 byte) pro Sekunde. Das könnte klappen. Da B-Bäume fast vom Aufwand O(1) sind, könnte das die richtige Wahl sein.

Sehr interessantes Thema...

[franktron]

Vieleicht kann die das hier weiter helfen Link

[Osse]

Hey, vielen Dank für diese guten Hinweise.

Hab ja schon son Progrämmlein geschrieben, nur halt ohne wirkliche Datenbankkomponenten, sondern nur Datei öffen, Daten schreiben und visualisieren. Wollte mal zum vergleich das Programm mit einer Datenbank testen, um die Geschwindigkeiten zu vergleichen.

Nochmal was allgemeines. Das Telegramm besteht aus bis zu 18 Byte, wobei am Anfang immer eine ID geschickt wird. Es soll später nachd den Einzelnen ID und auch Daten gesucht werden. Ist ein Recht komplexer Suchalgorithmus, natürlich noch nicht ausgereift, da ich mir den selber zusammengebaut habe. :coder:

@ Sharky

Zitat:

Grundsätzlich würde ich in so einem Fall zwei Programme einsetzten.
Programm A empfängt die Telegramme und speichert sie in die Datenbank.
Programm B zeigt die Daten der Datenbank (inkl. Filter und Suchfunktion) an.

Ich habs mit 3 Threads realisiert: 1. Guckt die ganze Zeit am Datenport und speichert die Daten temporär zwischen
2. Schreibt die Daten in eine Datei
3. Kümmert sich um die Viualisierung, Anzeige...
Konnte es aber leider nicht in freier Wildbahn testen, sondern nur zu Hause mit einigen Telegrammen.


@alzaimar
Leider muss ich nicht nach dem Zeitpunkt sortieren, sondern nach den ID's und Daten. Damit wird die ganze Geschichte schon schwieriger.


Werde mir nochmal intensiver 'Bulk Copy' und im gegensatz dazu Bayer-Bäume http://www.stcarchiv.de/stc1988/04_pascal.php durchlesen. Das mit den Bayer Bäumen hört sich sehr interesant an. Damit könnte ich also recht schnelle Zugriffszeiten realisieren. Nur bei der speicherung der Daten kann es recht lange dauern, oder??

Bin weiterhin für jeden Hinweis dankbar.

[Robert_G]

Zitat:

Zitat von alzaimar

150.000 recs/Sec schafft kein DB-Server (behaupte ich mal()

Auch wenn ich den SInn dahinter nicht wirklich sehen kann...
3-5 Oracle 10 Server in einem Grid machen das ohne auch nur mit der Wimper zu zucken. ;)
Kosten wären aber etwa zwischen 20.000 - 30.000 € anzusiedeln... (Sorry, ich verwende sowas nur, ich habe ehrlich gesagt keine Ahnung welches Lizenzmodell wieviel kostet)

[alzaimar]

Die MSDE kommt auf ca. 500 recs (2x500MHZ Server, alte Mühle), ein Oracle habe ich hier nicht. Ob da aber 3-5 Server ausreichen, käme auf den Versuch an. Schliesslich ist IMHO nicht nur der Server beim INSERT der Bottleneck, sondern das I/O Subsystem...

Ausserdem ist es hier wichtig zu erwähnen, das das SPEICHERN die bei weitem (zeitlich) aufwändigste Operation ist. Schliesslich will man ja sicher sein, das die Daten auch gespeichert sind, und die MSDE z.B. wartet, bis die Daten geschrieben wurden.

BCP beim SQL-Server ist auch saumässig schnell (10-100 recs/ms). Bis der Speicher voll ist. Und dann wird geschrieben. Und geschrieben.... Chrrr.... Poste doch mal Ergebnisse von Eurem Oracle Cluster. Ich habe eine Tabelle mit (Date, 3xint) und einem primary key index auf dem Date, dann nonstop reinballern und performance anzeigen lassen.

@Osse: Die Daten wurden direkt in die Key-Info der B-bäume gespeichert und in 8kb Seiten abgelegt. Die Zeiten galten inklusive Speicherung, allerdings mit einem Cache. Wenn der voll ist, werden die LRU (least recently used, also am längsten nicht benutzten) Seiten geschrieben. Vorteil: Schnell, Nachteil: Wenn Stromausfall dann GAU.

[et2004]

Falls dieses Thema noch jemanden interessiert: Ich habe zur Zeit auch den Bedarf ein möglichst schnelles Datenerfassungssystem zu entwickeln. Gespeichert muss Uhrzeit und ein Wert welcher von der Seriellen Schnittstelle kommt.

Darum habe ich angefangen mit verschiedenen Datenbanken zu testen: "Firebird 1.5", "Advantage Database System" kurz ADS und "Access 2003".

Test-Ergebnisse (1000 Datensätze in eine Tabelle mit drei Feldern (AUTOINC, DATETIME und INT) einfügen):

Firebird 1.5 ca. 47 sek. (mit Transaktion)
MS Access 2003 ca. 5 sek.
ADS <1 sek.


Hier ist der Source mit welchem ich den test durchgeführt habe:

procedure TForm1.Button1Click(Sender: TObject);
var
myStartTime, myEndTime: TDateTime;
i: Longint;
begin
myStartTime := now;

for i := 1 to 1000 do
begin
try
if Tab.Active = false then
begin
Tab.Open;
end;

Tab.Append;
Tab.Edit;
Tab.FieldByName('TIME').AsDateTime := now;
Tab.FieldByName('BEZ').AsString := IntToStr(i);
Tab.Post;

except
on E: Exception do
begin
Prot.Add(E.Message);
end;
end;
end;

myEndTime := now;

Label1.Caption := DateTimeToStr(myStartTime);
Label2.Caption := DateTimeToStr(myEndTime);
end;


Für mich war das Ergebnis eindeutig. Bei der ADS ist nach dem Post der Datensatz gespeichert und bei einem eventuellen Stromausfall gibts keinen Datenverlust.