.csv File durchsuchen oder andere 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 ganze Programm ist schon zu 70% fertig. 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. Des weitern soll es aber auch möglich sein einen Filter einzuschalten, oder nach bestimmten Einträgen zu suchen. Nun meine Frage, muss ich jede Zeile meiner Datenbank mit meinen Suchkriterien vergleichen??
Das wird wohl sehr lange Dauern. Doof!!! :wall:

Gibt es sonst eine andere Möglichkeit dies zu umgehen??? :gruebel:
Es soll auf jeden Fall keine SQL Datenbank sein.

Hab so keinen Schimmer von den Delphi Datenbanken. Hört sich aber stark danach an.
Könntet ihr mir etwas empfehlen, oder habt ihr selber schon mal vor einem solchen Problem gestanden??
Gibt es in Delphi fertige Tolls??

Die Daten dienen nur zur Projektierung und sollen zur Not auch in Excel darstellbar sein.

Später soll mit den Sucheinträgen besondere Telegramme dokumentiert werden.

Bin für alle Vorschläge offen.

Vielen Dank. :zwinker:

[alzaimar]

Erst eine Frage: Wieso keine SQL-Datenbank? Wobei SQL eine Sprache ist, die Access auch 'kann', aber Du meinst sicherlich eine richtige DB, wie MSSQL, FireBird, Postgres etc.

Du musst deine Werte ja abspeichern. da musst Du schon eine DB nehmen. Alles Andere ist IMHO Blödsinn.

Was das Filtern / Anzeigen etc. anbelangt, müsstest Du spezifizieren wie und vor Allen Dingen wann Du das machen willst. Eine MSDE z.B. ist, bei richtiger Indexierung, verdammt schnell, schneller als jedes selbstgeschriebene Programm wenn es darum geht, bereits gespeicherte Daten zu analyiseren bzw. zu filtern. Beim Speichern dagegen tut sich die MSDE schwer, weil sie eine 'echte' DB ist, die Dir garantiert, das deine Daten sicher wie in Fort Knox sind. Allerdings gibt es da Tricks (Stichwort 'Bulk Copy', BCP) womit man riesige Datenmengen en block sauschnell in die DB importieren kann.

Ich würde die Daten in einer Tabelle speichern mit dem Zeitpunkt als Primär-Index. Dann kannst Du -schnipps- sofort jedes beliebige Zeitfenster auswählen. Wenn Du dann noch weitere Filterkriterien hast, dann indexiere auch danach. Eventuell sogar kombiniert: Also Zeitpunkt-Unterkriterium als ein Index. Das ist dann auch saumäßig flink.

[marabu]

Hallo Osse,

wenn du die Daten eines CAN-Bus in Echtzeit visualisieren willst, warum speicherst du die Daten dann überhaupt? Bei einer Rate von 150 Telegrammen pro Millisekunde hast du 10 Mio pro Minute. Sowas lässt sich nur gefiltert oder aggregiert darstellen. Ist ein Ringpuffer auf einem RAM-Boliden da nicht die beste Lösung? Wenn gespeichert werden muss, dann kommt es darauf an, was später gemacht werden soll. Bei Detailauswertungen auf Massendaten kommst du um eine relationale Datenbank nicht drum rum - aber das ist ja eigentlich auch eine andere Baustelle - dein Monitor kann die Daten ruhig in csv-chunks speichern, die von einem Bulk-Loader in die Datenbank gezogen werden. Wenn keine Detailauswertungen benötigt werden, dann könntest du dir etwas in Richtung Round Robin Datenbank ausdenken.

Grüße vom marabu

[Osse]

Hey marabu und alzaimar

Vielen Dank für die schnelle und doch wieder neue Auftragslage für mich. Muss mich nun mit der Baustelle Datenbanken und deren Suchalgorithmen auseinandersetzten.

Marabu dein Round Robin Ansatz ist nicht schlecht, aber ich brauche alle Daten mit den ganzen einzelheiten, da sie als Sicherungsprotkoll dienen. Es werden alle Daten gespeichert um auch später nochmal die Daten analysieren zu können. In der Inbetriebnahme kommt es auf die Schnelligkeit an und das alle Telegramme auch angekommen sind. Später kann man dann nochmal nach Auffälligkeiten suchen.
Somit brauch ich also alle Daten.

Die Datenbank versuche ich hier zu dikutieren:
Suche AND Schnelle AND Offline AND Datenbank

(Wie schreibt man einen link in diesem Forum auf diesen Thread??)

Würd mich sehr über weitere Anregungen freuen und nochmal Danke für die flinke Antwort.

Gruß aus HH

[Sharky]

Zitat:

Zitat von Osse

... (Wie schreibt man einen link in diesem Forum auf diesen Thread??)

Hai Osse,

benutze dafür einfach den URL-Tag ;-)

[*url=http://www.delphipraxis.net/internal_redirect.php?t=54903]Klicke hier zum neuen Thread[/url]

ergibt (ohne den * am Anfang)

Klicke hier zum neuen Thread

[Domo Sokrat]

Moin Osse,

auch wenn Du nichts mit Datenbanken am Hut hast (haben willst), hätte ich da noch einen kleinen Tip für Dich: TjanSQL. Eine Library, die eine Klasse zur verfügung stellt, mir der Du z. B. CSV-Files wie Datenbanktabellen behandeln kannst und das mit SQL-Befehlen! So könntest Du über einfache SELECT-Statements z. B. Deine Filter realisieren. Lies Dir's einfach mal durch und dann entscheide, ob das etwas für Dich ist. Achja: Ein Demoprogramm ist auch dabei.

Grüße!

[Domo Sokrat]

Hi,

ich nochmal. Hab' eben gerade einen kleinen "Erfahrungbericht" zu TjanSQL in diesem Thread hier entdeckt :wink: Da wird auch kurz auf die Geschwindigkeit eingegangen...

[alzaimar]

@Domo Sokrat: Ich bezweifle, das eine sequentielle Suche auf einer 10GB Datei schnell geht. Es fallen doch pro Sekunde 2MB Daten an. Die 4 Sekunden in dem Beitrag in Bezug auf TjanSQL bei gerade mal 15000 Zeilen sind niedlich, aber nicht schnell.

[Domo Sokrat]

Hi alzaimar,

ich kann mir nicht vorstellen, daß die CSV'n von Osse :shock: 10 GB :shock: groß sind. Aber wer weiß :stupid: ... Von daher kann ich auch nur darüber spekulieren, ob die erwähnte Performance (15000 Zeilen in 4 sec.) nicht doch akzeptabel ist :roll: Aber ich denke, das sollte Osse selbst entscheiden :thumb:

@Osse: Gib doch bitte mal Laut, ob Du die TjanSQL-Library überhaupt in Betracht ziehen würdest ... War ja nur mal ein Tip bzw. Vorschlag von mir.

Grüße und gute Nacht!

[Osse]

Hey Domo Sokrat

habs mir die TjanSQL angeschaut und ich Denke,damit kann ich mal rumspielen. Ist aber recht umfangreich das Demoprojekt. Da muss ich mich mal richtig son Tag damit beschäftigen und orentlich :gruebel:.

Hab das demo Progrämmlein so lala zum Laufen gebracht irgendwas stimmt da noch nicht, da ich keine qstrings in jansqlstrings einbinden kann und auch keien janSQLWhere.pas. Habs dann auskommentiert, konnte aber keine .csv Dateien auswählen, sondern nur *.sql. Hast du schon "zufällig" mit TjanSQL ein kleines tool geschrieben um .csv Dateien zu bearbeiten??


Werde mir mal die schreib und öffnenroutinen sowie die Filter angucken. Sicherlich kann ich dabei viel lernen. Es ist auf jeden fall eine große bereicherung.

Danke

Einen schönen Gruß aus dem warmen HH und eine gute Nacht

[alzaimar]

Hi Domo Sokrat, hi Osse:
Wenn 150 Recs pro ms auftreten, mit 16 byte pro rec, dann sind das 2,4k pro ms, oder 2,4MB pro Sekunde. Pro Minute 144MB, pro Std 8,7 GB und pro Tag dann 207GB. Dann sind 10 GB doch realistisch, oder nicht? Irre ich?

[Domo Sokrat]

Hi alzaimar,

ich hab' mich zu sehr auf das CSV-Thema versteift. Mit Deiner Rechnung bzgl. des Datenvolumens hast Du mich jetzt doch ein wenig ins Grübeln gebracht :oops:. Ich denke für sowas ist TjanSQL dann doch "ein wenig zu langsam". Ich hab' jetzt auch keine EW's mit solch einem fetten Datenhaushalt auf 'ner bestimmten Datenbank...

Grüße

[Osse]

So Leute, ich glaube das geht so nicht mit meinen .csv Datein.

Die Suche würde viel zu lange dauern. Alleine dsa einlesen der Daten aus der Datei ist ja schon recht zeitintensiv.
Ich denke mit meiner .csv Datei komme ich da nicht weit.

Bin jetzt davon ab und suche nach alternativen. Eine Datenbankstruktur ein einfacher Normalform (nur eine Datei), in der ich in bestimmten Spalten suchen kann, ohne den ganzen Datensatz auslesen zu müssen. Das kann ich dann immer noch später machen.

ISt es mit .xml möglich so etwas zu schreiben?? :gruebel:

[alzaimar]

XML bläht die Daten nochmehr auf.
XML ist 'nur' eine universelle eierlegende Wollmilchsaubeschreibungssprache, mit der Du eigentlich alles beschreiben kannst...

Dein Problem ist, das Du netto 2,4 MB Daten erstmal speichern musst. Erzähl doch mal, was in den 16 Byte drinsteht und wonach Du primär und sekundär filtern musst. Ich bleibe dabei, mit einem B-Baum und einem sehr schnellen PC sowie schneller HD könnte es klappen.

Dessenungeachtet würde ich mal drüber nachdenken, ob es *wirklich* nötig ist, *alle* Daten zu speichern. Während der Testphase kannst Du ja Csv-Dateien ('logs') anlegen und die per 'Grep' durchsuchen. Das geht sogar recht flink, vor allen Dingen, wenn Du die Daten nicht per CSV, sondern als 'fixed spaced' speicherst. Also, z.B. alphanumerisch, aber pro Wert immer fest 4 Stellen oder so vorsehen. Dann geht das Suchen wesentlich schneller.

Später verdichtest Du die Daten ja sowieso, und *die* schreibst Du in eine ordendliche DB.

Ich mache das so mit meinen Projekten, da habe ich zwar nur 5MB/Tag aber die Analyse dieser Rohdaten hat mir immer geholfen. Eben weil ich damit dem Anwender nachweisen konnte, das *ER* Mist gebaut hat und nicht *MEINE* Software...

[Osse]

Nach einigen Nachlesen und Nachdenken (deshalb hat das auch so lange gedauert:roll: ) bin ich zu dem Entschluss gekommen B-Bäume zu benutzen. Muss nun erstmal wissen was das ist.

Die Daten die ich spechern muss sind in TCANRcvMsg enthalten.

Delphi-Quellcode:

// Eine CAN-Message, die ueber CAN_Read_Multi() empfangen wurde.
  TCANRcvMsg = record
    msgbuff: TCANMsg;   // Message
    hNet: byte;      // Netz, aus dem die Msg empfangen wurde
    rcvtime: TCANTimestamp; // Rueckgabe des Empfangszeitpunktes
  end;

// total microseconds = micros + 1000 * millis + 0xffffffff * 1000 * overflows
  TCANTimestamp = record
    millis: Longword;      // base-value: milliseconds: 0.. 2^32-1
    millis_overflow: Word; // roll-arounds of millis
    micros: Word;          // microssecond: 0..999
  end;

// Eine CAN-Message
  TCANMsg = record
    ID: Longword;       // 11/29 Bit-Kennung
    MSGTYPE: Byte;      // <> 0, wenn remote request
    LEN: Byte;          // Anzahl der gueltigen Daten-Bytes (1..8)
    DATA: array[0..7] of Byte;    // Daten-Bytes 0..7
  end;

msgbuff : Wichtige Daetn aus dem Protokoll z.B. ID, Datenlänge und selbsverständlich die Daten
Timestamp : Zeit, die ich vom Microcntroller ausgelesen bekomme und nur zur berechnung brauche. Wenn zweimal das gleiche Telegramm
kommt, soll ein Index hochgezählt werden und die Zeit, welche dazwischen verstrichen ist soll angezeigt werden.

Später will ich dann nach ID sortieren und auch die Möglichkeit haben auch in den Daten nach bestimmen Einträgen zu suchen.

Da häufig die gleiche ID kommt und Teilweise auch Telegramme mit 0 Daten ankommen ist das wohl die efizienteste Methode Daten zu speichern.

Ich versuchs mal mit einem theoretischem Ansatz:

Ich lege den Index mit meiner ID fest (Knotenpunkt)


ID---------------Daten-------------------Timestamp---------------Wiederholungen

3----------------344567-------------------345277----------------------- 2
-----------------345663-------------------222256----------------------- 0
-----------------45634673 ----------------223457----------------------- 3

5----------------345664-------------------345767----------------------- 2
-----------------123444-------------------678876----------------------- 0
-----------------78978666 ----------------789667----------------------- 3

.....

Oberstes Suchkriterium ist die immer ID. Danach folden dann die Daten als "Unterkriterium". Also recht gut als Datenbank aufzubauen, oder??

Tja, da steh ich nun mit meinem Ansatz.
Ist das einigermassen OK so, oder gibt es andere Anregungen??

Wenn ja, dann wäre jetzt der nächste schritt sich über die Datenbank und über das Speichern gedanken zu machen.
Weche DB nehme ich denn da?? mysql, Firebird,...
Gibt es fertige Komponenten in Delphi, die das schreiben von B Bäumen übernehmen??
Problematisch sehe ich nur das schreiben der Daten. Kann man zum schreiben in eine Datenbank eine höhere Priorität wählen als zum lesen???

Fragen über Fragen.

Vielen Dank

[alzaimar]

:wall: Ich habe das mal ausgetestet, die 100.000 Recs/sec werden nur z.T. erreicht:

Als Schlüssel habe ich die ID + DATA genommen.
Die Performance ist von der ID abhängig:

ID = Random (10000000) ---> ca. 15.000 Recs/Second
ID = N++ --> 12.000 Recs/Second
ID = (N++)/10 ---> 35.000 Recs /second
ID = (N++)/100 ---> 200.000 recs/sec.

2GHZ-AMD PC (langsame HD). Solange ich nicht speichern muss, schaffe ich ca. 500.000 Items/sec. Wenn Du eine schnelle HD hast, dann könnte es klappen...

Ich puffere immer 100 Einträge und speichere dann die Daten en block. Ich weiss nicht, ob Dir das reicht...

Man kann noch an einigen Stellen drehen. Wenn Du ASM beherrscht, kannst Du einige Programmteile schneller machen...

Hier ist der Code.

[Osse]

Ufff :gruebel: , das ist ja nicht gerade wenig code :pale: .

OK, da dachte ich mir zunächst mal einfach mal die Taste F9 zu drücken und gucken mit Hilfe des Debuggers was passiert. Doch Leider kamen da mal wieder son paar blöde Fehlermeldungen:

CANTestMain.pas ist die unit Variants eingebunden, welche nicht gefunden werden kann.Es fehlt der PCardinal Type.
Hab ich jetzt einfach in csBtree deklariert.
type
PCardinal = ^Cardinal;


Außerdem fehlte mir die csCRC.pas. Hab ich das Orakel befragt und eine Antwort aus diesem Forum erhalten. http://www.delphipraxis.net/internal...ct.php?t=53653

Fazit DEIN PROGRAMM läuft :thumb: :dancer: :thumb: :zwinker:

Kann man sich die Daten in der Test.DTA mit einem Programm angucken, um zu sehen ob die Daten richtig geschrieben wurden, oder überhaupt mal da rein zu gucken??

Ich glaub da fehlt mir noch ne Menge Theorie, auch später zum auslesen.

Da noch eine kleien Frage vorweg. Wenn ich die Daten schreibe, kann ich sie parallel dazu auslesen??

Werde morgen mal mit einem Zettel und der F7 Taste hinsetzten und das verstehen :zwinker: und abends dann ein schön :cheers: .

Vielen Dank alzaimar. ICh denke das bringt mich ein ganzes stück weiter.

Einen schönen Tag heute

[alzaimar]

Du kannst natürlich die Datei lesen UND schreiben, solange Du immer über Btree gehst. Threadsicher ist das Ganze, glaube ich.

Die Datei Test.DTA besteht aus den B-Baum-Seiten (also den Knoten und Blättern des Baumes).
Die Deklaration einer Seite ist in der Unit csBtree (Type TcsBtreePageData)

Ein B-Baum ist nun mal nicht trivial. Der Code drumherum beschäftigt sich in erster Linie mit dem Page-Cache, also einem Puffer für 8kb Speicherblöcke.

Halt mich auf dem Laufenden.

[Osse]

Zitat:

Ein B-Baum ist nun mal nicht trivial. Der Code drumherum beschäftigt sich in erster Linie mit dem Page-Cache, also einem Puffer für 8kb Speicherblöcke.

OK, das gebe ich zu. Der Code drumherum :shock: ist für mich aber recht viel. Ich sitze jetzt schon 4Stunden davor und nach der Theorie müsste ich die Bäume jetzt verstanden haben. Das nächste Ziel für mich ist nunmal das Testen, ob diese art der Datenspeicherung wirklich für mich in Frage kommt. Dazu möchte ich den ganzen Code in meinem Projekt einbinden, welches schon besteht. Nur leider verstehe ich noch nicht wie ich die Daten aus der Datei auslese und wie ich nach einträgen suchen kann und diese mir dann anzeigen lassen kann. Also die Frage, wie kann ich alle Daten auslesen und wie kann ich nach Daten suchen??

Ich weiß, dass das in einer der 7 units steht, doch wo??

Über diesen Tip wäre ich sehr dankbar, dann könnte ich das ausprobieren.

"Ich sehe den Wald vor lauter Bäunen nicht." :zwinker:
Wenn nix geht, aber Metaphern.

Danke

[alzaimar]

Osse, das ist wirklich nicht einfach.

Die Daten werden also sortiert (nach einem bestimmten Schlüssel) abgelegt. Normalerweise speichert man ein Tupel, also (Schlüssel, Daten). Wenn ich also an ein Datum X will, das vorher mit dem Schlüssel 'ABC' gespeichert wurde, dann suche ich nach dem Schlüssel ABC.
Ich habe Speicher gespart, weil ich nur nach einem Schlüssel sortiert ablege und ich den Schlüssel jederzeit aus den Daten erzeugen kann. Die Methode 'TForm1.BtreeCompare' erzeugt eine totale Ordnung auf den Daten, indem es der Btree-Klasse sagt, welches von zwei 'TcsBtreeItems' (identisch mit dem CANrecord) größer ist.

Du kannst natürlich die Methode BtreeCompare an deine Bedürfnisse anpassen. Dabei musst Du aber darauf achten, das 'identische' Records (die also den Vergleichswert '0' liefern) als Identität behandelt, also auch überschrieben werden.

Zurück zum Thema: Wie suche ich einen Record? Da gibt es erstmal zwei Funktionen.

Delphi-Quellcode:

function TcsBtree.FindKey(Var aItem : TcsBtreeItem) : boolean;
function TcsBtree.FindNearest (Var aItem : TcsBtreeItem) : Boolean;

Is klar, was die machen: Du füllst dein TcsBtreeItem (TCANrcvMsg) mit den schlüsselrelevanten Daten und rufst FindKey auf. Der sucht im Baum und liefert eben den record zurück. Blöd ist hier, das Du ja vorher die Daten wissen musst, also wozu noch suchen :oops: ? Klar, das geht hier nicht. Die Funktion ist also z.B. für eine DB gedacht, wo die Kundendaten gespeichert werden, und als Schklüssel die Kundennummer dient. Dann einfach TKundenRec.KundenNr='12345', FindKey und dann hat man den ganzen Kundendatensatz...

Also, suchst Du z.B. den 'nächstliegenden'. Z.B. Füllst Du dein record mit 'ID=12345' und als DATA=0,0,0,0. Dann liefert FindNearest eben den Record, der deinem Kriterium am ähnlichsten ist.

Oder du benutzt die 'BtreeCursors'. Die sind sehr praktisch, weil sie immer 'Bereiche' abdecken. Stell Dir einen B-Baum als sortierte Liste vor. Du willst nun alle recs zwischen ID=12345 und ID=12400.
Deklariere zwei TcsBtreeItems (a und b). Du belegst a mit den Daten, die garantiert 'links' vom ersten Record der ID=12345 liegt (oder identisch mit dem ist) und b belegst du mit Daten, die garantiert 'rechts' vom letzten Record der ID=12400 ist.

Angenommen, du willst alle 'Meyers' aus dem Telefonbuch. Dann suchst Du nach einem 'Meyer', Vorname'AAAAA' (Record a) und dem
'Meyer", Vorname "ZZZZZ". Wenn Du die Positionen hast, dann liegen alle Meyers garantiert dazwischen.

Das macht der Btree-Cursor.

Delphi-Quellcode:

Var
  aCursor : TcsBtreeCursor;
  aFirstRec, aLastRec : TcsBtreeItem;

Begin
  aFirstRec.msgbuff.ID :=  12345;
  a.msgbuff.LEN := 0; // Garantiert die untere Grenze des zu suchenden Bereiches
 
  aLastRec.msgbuff.ID :=  12401;
  a.msgbuff.LEN := 0; // Garantiert die obere Grenze des zu suchenden Bereiches
   
  aCursor := TcsBtreeCursor.Create (aBtree, aFirstRec, aLastRec);
  Try
    aCursor.First; // Isser nach dem Create schon, aber sische' is sische'
    While not aCursor.EOF Do begin
       ProcessCANRec (aCursor.Pos); // aCursor.Pos ist die aktuelle CANrcvMSG
       aCursor.Next; // Gehe zum nächsten record
       End;
   Finally
    aCursor.Free;
    End;
End;

Nochmal:
1. DU definierst erstmal, in welcher Reihenfolge die Daten sortiert werden sollen.
2. Dann erzeugst Du die Datei.
3. Dann kannst Du einen beliebigen Bereich innerhalb des Baumes finden, indem Du die untere und obere Grenze angibst.

Delphi-Quellcode:

If MoreQuestions Then Shout;

[Osse]

Hey Alzaimar,

nicht leicht das ganze für einen E-Techniker :gruebel: :gruebel: , ABER es funktioniert, zumindest in dem kleien Beispiel. Doch da ist noch etwas:

Zitat:

Du kannst natürlich die Methode BtreeCompare an deine Bedürfnisse anpassen. Dabei musst Du aber darauf achten, das 'identische' Records (die also den Vergleichswert '0' liefern) als Identität behandelt, also auch überschrieben werden.

Ich will aber gar nicht dass die Daten überschrieben werden, sondern ich brauche alle Daten als Protokoll. Dies dient da´zu später nach bestimmten Zeiten zu gucken, wann das Telegramm gekommen ist. Ach :wall: , werden sie ja auch nicht, da der Timestamp immer anders ist. Dadurch wird der Verglichswert 0 so nie erreicht!! :angel2:

Ist es dann überhaupt noch sinnvoll solche Datensruktur zu benutzen, oder würdest du etwas anderes vorschlagen??

Ich hab mal einfach versucht, nach den Daten zu sortieren und später das ganze wieder auszulesen. Kam aber leider nichts erfolgreiches raus, außerdem führt jede neue Suchroutine zu einer enormen Verlangsamung. Ansonsten kann ich die Daten ja so lassen wie sie sind und später beimauslesen dann sortieren aufm Grid ausgeben.

Hab das so realisiert :zwinker: :

Delphi-Quellcode:

  If a.msgbuff.ID < b.msgbuff.ID then aresult := -1
  else if a.msgbuff.ID > b.msgbuff.ID then aResult := +1
  else if a.msgbuff.DATA[0] < b.msgbuff.DATA[0] then aResult := -1
  else if a.msgbuff.DATA[0] > b.msgbuff.DATA[0] then aResult := +1
  else if a.msgbuff.DATA[1] < b.msgbuff.DATA[1] then aResult := -1
  else if a.msgbuff.DATA[1] > b.msgbuff.DATA[1] then aResult := +1
  else if a.msgbuff.DATA[2] < b.msgbuff.DATA[2] then aResult := -1
  else if a.msgbuff.DATA[2] > b.msgbuff.DATA[2] then aResult := +1
  else if a.msgbuff.DATA[3] < b.msgbuff.DATA[3] then aResult := -1
  else if a.msgbuff.DATA[3] > b.msgbuff.DATA[3] then aResult := +1
  else if a.msgbuff.DATA[4] < b.msgbuff.DATA[4] then aResult := -1
  else if a.msgbuff.DATA[4] > b.msgbuff.DATA[4] then aResult := +1
  else if a.msgbuff.DATA[5] < b.msgbuff.DATA[5] then aResult := -1
  else if a.msgbuff.DATA[5] > b.msgbuff.DATA[5] then aResult := +1
  else if a.msgbuff.DATA[6] < b.msgbuff.DATA[6] then aResult := -1
  else if a.msgbuff.DATA[6] > b.msgbuff.DATA[6] then aResult := +1
  else if a.msgbuff.DATA[7] < b.msgbuff.DATA[7] then aResult := -1
  else if a.msgbuff.DATA[7] > b.msgbuff.DATA[7] then aResult := +1
  else    aResult := 0;
end;

Wenn ich die Daten dann in einer Listbox ausgebe, siehts am Anfang noch recht gut aus, aber dann :?

Zitat:

ID Data 1 Data2 Data3 .....
21 ; 20 ; 68 ; 89 ; 126 ; 219 ; 107 ; 216 ; 248
21 ; 20 ; 90 ; 65 ; 95 ; 150 ; 226 ; 65 ; 247
21 ; 20 ; 98 ; 55 ; 123 ; 20 ; 197 ; 127 ; 170
21 ; 20 ; 105 ; 80 ; 159 ; 236 ; 28 ; 52 ; 235
21 ; 20 ; 114 ; 104 ; 119 ; 201 ; 197 ; 138 ; 117
21 ; 20 ; 120 ; 153 ; 63 ; 97 ; 8 ; 40 ; 17
21 ; 20 ; 125 ; 117 ; 125 ; 13 ; 27 ; 181 ; 29
21 ; 20 ; 127 ; 240 ; 30 ; 250 ; 85 ; 155 ; 218
21 ; 20 ; 133 ; 191 ; 180 ; 119 ; 249 ; 53 ; 15
21 ; 20 ; 145 ; 249 ; 140 ; 235 ; 107 ; 72 ; 234
21 ; 20 ; 156 ; 20 ; 160 ; 154 ; 213 ; 109 ; 122
21 ; 20 ; 168 ; 212 ; 233 ; 4 ; 217 ; 147 ; 13
21 ; 20 ; 186 ; 240 ; 41 ; 60 ; 122 ; 180 ; 96
21 ; 20 ; 196 ; 39 ; 115 ; 63 ; 66 ; 92 ; 207
21 ; 20 ; 196 ; 173 ; 179 ; 123 ; 106 ; 218 ; 234
21 ; 20 ; 223 ; 225 ; 30 ; 0 ; 33 ; 249 ; 250
21 ; 20 ; 234 ; 48 ; 58 ; 56 ; 30 ; 140 ; 175
21 ; 21 ; 1 ; 234 ; 220 ; 30 ; 181 ; 177 ; 110
21 ; 21 ; 2 ; 19 ; 153 ; 150 ; 121 ; 191 ; 227

Wie gesagt, wenns nicht anders geht, kann ich die Sortierung auch in der Anzeige machen. Da kommt es auf die Zeit nicht an.

Hättest du eine andere Idee??

Nochmal :kiss: für die Super Unterstützung, ist nicht so leicht für mich..

[alzaimar]

Was ist an der Listbox so falsch? Sieht doch gut aus, sind die nun alle sortiert oder bin ick zu blind? Egal.

Sag doch einfach mal, WONACH du suchen willst, bzw. WAS du auswerten möchtest. Dann deichseln wir das schon. (Oder auch nicht :zwinker:)

Es IST ein vertracktes Problem. Wenn das direkte Speichern in den B-Baum so nicht geht, dann würde ich auch einfach (is ja wohl nur ne Testphase) die Teile in eine Text-Datei reinballern und mit geeigneten suchroutinen später auswertungen machen.

Fragen:
1. Musst Du die Records wochenlag mitschneiden, oder nur für 1-2 Tage, oder wie?
2. Wie hoch ist die Datenmenge, wenn alles ok ist?
3. (Wiederholung) Wonach willst Du suchen und was brauchst Du als Filter/Anzeige?

[Osse]

NAja, wenn ich mir die letzte Spalte so angucke, ist das wohl nicht mehr so ganz richtig mit 248, 247,170,235,117...

Zitat:

1. Musst Du die Records wochenlag mitschneiden, oder nur für 1-2 Tage, oder wie?

Ich denke, dass das Programm so 2Tage durchläuft. Wollte jeden Tag eine eigene Datei anlegen. Später solle és dann auch möglich sein Nacheinander in den Dateien zu suchen. Sollte hier aber nicht das Problem sein, oder??!!

Zitat:

2. Wie hoch ist die Datenmenge, wenn alles ok ist?

Ok, dann will ich mal einen losrechnen. Mayby hab ich da ja einen Fehler drin.

Max. Übertragungsrate 1 Mbit/s wenn das kürzeste Telegramm 40Bit lang ist und eine Busauslastung von 100% besteht, wovon ausgegeangen werden muss, dann beläuft sich das ja auf:

1oooooo Bit/s
------------- = 25000 Telegramme/s = 25 Telegramme/ms oder hab ich da falsch gerechnet.
40 Bit

Nun die 25000 Telegramme/s * 3600 um auf Stunden zu kommen := 90000000bit/h um das mal komfortabel darstellen

1 byte = 8 bit -> 11250000Byte/h -> 11,25Mb pro Stunde oder :gruebel: :gruebel:

Zitat:

3. (Wiederholung) Wonach willst Du suchen und was brauchst Du als Filter/Anzeige?

- Ich will zunächst nach ID gucken können und alle Telegramme mit der Such ID Darstellen können.
- Ein unterpunkt ist nun nach bestimmten Daten zu suchen, mit zugehöriger ID. Die ID muss immer mit angegben sein.
Bsp.

Ich möchte nach der ID 200 suchen und zwar im 1.Datenbyte sollen alle Einträge zwischen 23-98 und im 4. Datenbyte 34-78 angezeigt werden. Welche Werte die anderen Datenbytes haben ist völlig wurst.
Hier ein Bsp für die Suchanfragen:

ID Data0 Data1 Data2 Data3 Data4 Data5 Data6 Data7
200 --- ----- ---- ----- ---- ---- ---- ----- (alle Telegramme mit ID 200 darstellen)
200 --- 23-98 ---- ----- 34-78 ---- ----- ------

Das ist das höchste der Gefühle, wonach gesucht werden soll.
Wichtig ist nur, dass immer die ID mit angegeben wird. Das ist der "Schlüssel".

Filter(werden nur für die Anzeige realisiert) und das mache ich schon beim ankommen der Telegramme, geht schon. Aber bin für besserungen offen.

[alzaimar]

Deine Ordnung, die du aufbaust, bedingt, das erst nach ID, dann nach erstem byte, dann nach dem 2. usw sortiert wird. Insofern ist alles o.k. Schau Dir das alles an. Innerhalb gleicher ID ist nach dem 1.Byte aufsteigend sortiert, innerhalb des 2. auch (kommt nicht vor, egal).

Wir haben also 12 MB/h (aufrunden ist immer gut), dann sind das gerade mal ca. 1G für 2 Tage. Mein Btree kann 2G verwalten (meine ich).

Wenn Du nur nach allen Telegrammen einer ID 200 mit 1.DATA zwischen 23 und 98 suchen willst, dann müsstest Du einen Cursor erzeugen, der den Bereich zwischen
ID:200, DATA :23,0,0,0,0,0,0,0 und
ID:200, DATA:98,255,255,255,255,255,255,255
abdeckt. Die Ordnung ist ja streng von links nach rechts. Dann scanst Du den Bereich und zeigst nur die Recs, deren 4.Datenbyte in dem Bereich liegt. Das bekommst Du relativ leicht allgemeingültig hin. Das geht relativ schnell, so im Bereich von (geschätzten) 100.000 - 500.000 recs/sec. Ich meine, Du solltest mal ein paar mio recs ablegen und dann schauen.

Wenn die Performance hinhaut und mein Tool die Tests (Stabilität, Speicherlecks) besteht (also, wenn es 2 Tage durchhält), dann bist Du ein gemachter Mann :mrgreen:

[Osse]

Jo, super dann wollen "wir" das mal versuchen. Werde erstmal austesten, ob das ganze Threadsicher ist.

Zitat:

Wenn die Performance hinhaut und mein Tool die Tests (Stabilität, Speicherlecks) besteht (also, wenn es 2 Tage durchhält), dann bist Du ein gemachter Mann

Super das Tool. :dancer: :dancer: Sag mal, wo hast du das denn her, oder etwa selber :coder: .

Ist auf jedenfall toll.

Zitat:

Mein Btree kann 2G verwalten (meine ich).

Was passiert dann?? explodiert die Festplatte??

Ok, wird der Adressraum vom Zeiger dann zu groß???

So, dann mal ran an die Buletten, nach soviel Input werde ich schön weiter :coder:

Gruß aus dem verregneten Hamburg

[alzaimar]

Die Teile musste ich selbst schreiben.
Bei Dateigrößen über 2GB wird unser Universum, so wie wir es kennen, durch etwas viel Schrecklicheres ersetzt. Es gibt Gerüchte, nach dies schon geschehen ist (Frei nach "Hitchhickers Guide to the Galaxy").