.csv File durchsuchen oder andere Datenbank??

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

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

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 , das ist ja nicht gerade wenig code .

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

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 und abends dann ein schön .

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

If MoreQuestions Then Shout;