ADO Command mit mehreren Inserts

[Tomektor]

Hallo!

Habe folgende Aufgabe:
Bestimmte Datenpunkte (bis zu 10000 Stück!) müssen über Monate bis Jahre hinaus in einer Datenbank archiviert werden.
Die Zustandsänderung wird jede Sekunde archiviert.
Für jeden Datenpunkt wird eine Tabelle angelegt: dp1 bis dp9999. Die Tabelle besitzt nur zwei Spalten (Timestamp und Wert).
Natürlich muss ich bei der Anzahl von Tabellen unmöglich sein ADOCommando.Execute in einer Schlaufe laufen zu lassen (aus Spaß getestet ;) - bei 250 Executes pro Sekunde ist Schicht im Schacht)
Die Insert-Anweisungen sollten deshalb gesammelt werden und in Paketen über ein ADOCommando.Execute gesendet werden. (wie in einer Dump-Datei).
Und hier taucht schon ein Problem auf:

Dies funktioniert problemlos:

Delphi-Quellcode:

commando := 'INSERT INTO dp1 VALUES (' + unixstamp + ', ' + wert + ');';
ADOCommando.CommandText := commando;
ADOCommando.Execute;

Das Sammeln von Werten für einen Datenpunkt in einer Insert-Anweisung funktioniert ebenfalls:

Delphi-Quellcode:

commando := 'INSERT INTO dp1 VALUES (1137061871, 0.568),(1137061872, 0.654),(1137061873, 0.564)';
ADOCommando.CommandText := commando;
ADOCommando.Execute;

Das funktioniert gar nicht:

Delphi-Quellcode:

commando := 
'INSERT INTO dp1 VALUES (1137061871, 0.5); ' +
'INSERT INTO dp2 VALUES (1137061871, 0.5); ' + 
'INSERT INTO dp3 VALUES (1137061871, 0.5); ' +
'INSERT INTO dp4 VALUES (1137061871, 0.5); ' +
'INSERT INTO dp5 VALUES (1137061871, 0.5); ' +
'INSERT INTO dp6 VALUES (1137061871, 0.5); ' +
'INSERT INTO dp7 VALUES (1137061871, 0.5); ' +
'INSERT INTO dp8 VALUES (1137061871, 0.5); ' +
'INSERT INTO dp9 VALUES (1137061871, 0.5); ' +
'INSERT INTO dp10 VALUES (1137061871, 0.5); ';
ADOCommando.CommandText := commando;
ADOCommando.Execute;

Hat jemand eine Ahnung woran es liegen mag?!?
Es schaut so aus, also ob man in einen CommandText des ADOCommand nur eine Tabelle ansprechen könnte, aber das ist doch Quatsch.
Ich will doch reines SQL über die Schnittstelle schieben...
Gebe ich dieselbe SQL-Anweisung an die Datenbank über ein Tool wie phpMyAdmin ein, werden die Inserts ausgeführt...




Falls jemand es ausprobieren möchte hier der Code für die Tabellen erstellung (für 10 Datenpunkte):

Delphi-Quellcode:

   
procedure TForm1.Button1Click(Sender: TObject);
var
i: Word;
table: String;
begin
   for i := 1 to 10 do
   begin
     table := 'dp' + IntToStr(i);
     ADOCommandDelete.CommandText := 'DROP TABLE IF EXISTS ' + table;
     eSQLBefehl.Text := ADOCommandDelete.CommandText;
     ADOCommandDelete.Execute;
   end;

   for i := 1 to 10 do
   begin
     table := 'dp' + IntToStr(i);
     ADOCommandDelete.CommandText :=
     'CREATE TABLE ' + table + ' ( ' +
     'tstemp int(12) NOT NULL default 0, ' +
     'dpvalue float(16,15) NOT NULL default 0.000000000000000, ' +
     'PRIMARY KEY  (tstemp) ' +
     ') TYPE=MyISAM;';
     ADOCommandDelete.Execute;
   end;

end;

Danke im Voraus für die Mühe!

[Bernhard Geyer]

Ich habe ein paar Anmerkungen:

1, Wieso nutzt du ADO? Für MySQL gibt es doch mit MyDAC eine sehr gute native Zugriffskomponente. Auch die ZEOS-Komponenten sind ganz gut für MySQL.

2, Hattest Du schon probiert mit Prepared Statements die Performance zu verbessern?

3, Falls Du MySQL 5.0 einsetzen könntest, könntest Du probieren mittels SP's die Performance nochmals zu verbessern.

[MarcoWarm]

IMHO ist dein Datenbankdesign recht... nunja... wie soll ich sagen... ungünstig :roll:

Warum legst du für jeden Punkt eine separate Tabelle an? Für deine Aufgabe reicht eine einzige Tabelle. Die lässt sich dann auch wesentlich leichter auswerten.

SQL-Code:

CREATE TABLE MESSPUNKTE(
    ID INTEGER NOT NULL,
    DATENPUNKTID INTEGER,
    DATUMZEIT TIMESTAMP,
    WERT DOUBLE PRECISION)

[Tomektor]

Zitat:

Zitat von Bernhard Geyer

Ich habe ein paar Anmerkungen:

1, Wieso nutzt du ADO? Für MySQL gibt es doch mit MyDAC eine sehr gute native Zugriffskomponente. Auch die ZEOS-Komponenten sind ganz gut für MySQL.

2, Hattest Du schon probiert mit Prepared Statements die Performance zu verbessern?

3, Falls Du MySQL 5.0 einsetzen könntest, könntest Du probieren mittels SP's die Performance nochmals zu verbessern.

1. Es ist ein Testbalon. Ich mache die Vorarbeit mit MySQL. Das Tool soll aber mit MSSQL, SAPDB, ORACLE usw. über Standard-ODBC funktionieren.

2. Nein noch nicht

3. Ich nutze MySQL4 zum Test. Alles soll aber auf Standard-SQL laufen, also keine Spezial-Performance Funktionen... :(

[Bernhard Geyer]

Zitat:

Zitat von Tomektor

1. Es ist ein Testbalon. Ich mache die Vorarbeit mit MySQL. Das Tool soll aber mit MSSQL, SAPDB, ORACLE usw. über Standard-ODBC funktionieren.

Vergiss ODBC. Unter Win64 gibt es kein ODBC mehr und wer weiss wie stabil M$ ODBC32 pflegt. Hab da meine Erfahrungen mit ODBC16.

Zitat:

Zitat von Tomektor

3. Ich nutze MySQL4 zum Test. Alles soll aber auf Standard-SQL laufen, also keine Spezial-Performance Funktionen... :(

Wenn du das letzte Prozent Performance benötigst wirst Du nicht darum herumkommen.

[Tomektor]

Zitat:

Zitat von MarcoWarm

IMHO ist dein Datenbankdesign recht... nunja... wie soll ich sagen... ungünstig :roll:

Warum legst du für jeden Punkt eine separate Tabelle an? Für deine Aufgabe reicht eine einzige Tabelle. Die lässt sich dann auch wesentlich leichter auswerten.

SQL-Code:

CREATE TABLE MESSPUNKTE(
    ID INTEGER NOT NULL,
    DATENPUNKTID INTEGER,
    DATUMZEIT INTEGER,
    WERT DOUBLE PRECISION)

Hast Recht, aber ich muss mich an Vorgaben halten :(
Es ist eine Umstetzung eines bereits vorhandenen Tools, welches für jeden Datenpunkt eine Textdatei erzeugt.
Die Dateien (hier einzelne Tabellen) müssen separat gesichert werden können.
Das zweite Problem ist:
Es entstehen pro Datenpunkt 31.536.000 Datensätze pro Jahr (und das ist die Mindestzeit der Archivierung).
Damit ist jede Tabelle ca. 0,5 GB groß und läßt sich einzeln ganz gut wegsichern.
Würde ich alle 10.000 Datenpunkte in eine Tabelle packen und über die DatenpunktID ansprechen, hätte ich im Januar 2007 eine Tabelle mit 315.360.000.000 Datensätzen und > 5.000 GB. Das können wir gleich vergessen...

Das alles könnte man ja noch lösen, aber das blödeste sind die Vorgaben...
Und ich stehe schon am Anfang vor einem Problem, welches so einfach erscheint...

Trotzdem danke!

[Jelly]

Zitat:

Zitat von Tomektor

Zitat:

Zitat von Bernhard Geyer

1, Wieso nutzt du ADO? Für MySQL gibt es doch mit MyDAC eine sehr gute native Zugriffskomponente. Auch die ZEOS-Komponenten sind ganz gut für MySQL.

1. Es ist ein Testbalon. Ich mache die Vorarbeit mit MySQL. Das Tool soll aber mit MSSQL, SAPDB, ORACLE usw. über Standard-ODBC funktionieren.

Dann vergiss aber mal ganz schnell so Konstrukte wie

SQL-Code:

INSERT INTO dp1 VALUES (1137061871, 0.568),(1137061872, 0.654),(1137061873, 0.564)

die sind nämlich MySQL spezifisch.

Mal so ne Frage... Was sind das für Daten, dass nach 1 Jahr über 300 Milliarden Datensätze anfallen... Die kannst Du doch unmöglich noch auswerten.

[MarcoWarm]

Zitat:

Zitat von Tomektor

Hast Recht, aber ich muss mich an Vorgaben halten!

Welche Vorgaben hast du denn. Auftraggeber sollten das mit dem Datenbankdesign besser dem Fachman (sprich: Dir) überlassen, wie du deine Daten hälst.

Zitat:

Zitat von Tomektor

Es ist eine Umstetzung eines bereits vorhandenen Tools, welches für jeden Datenpunkt eine Textdatei erzeugt.
Die Dateien (hier einzelne Tabellen) müssen separat gesichert werden können.

Du würdest doch sowieso als Datensicherung nur die gesamte Datenbank sichern. So macht man das gewöhnlich.
Außerdem bist du mit der Eintabellenlösung flexibler auf die Änderung der Messpunktanzahl vorbereitet.

Zitat:

Zitat von Tomektor

Es entstehen pro Datenpunkt 31.536.000 Datensätze pro Jahr (und das ist die Mindestzeit der Archivierung).
Damit ist jede Tabelle ca. 0,5 GB groß und läßt sich einzeln ganz gut wegsichern.
Würde ich alle 10.000 Datenpunkte in eine Tabelle packen und über die DatenpunktID ansprechen, hätte ich im Januar 2007 eine Tabelle mit 315.360.000.000 Datensätzen und > 5.000 GB.

Ihr quält eure Server ja... lol. Also, das Datenaufkommen hast du ja so oder so, egal in wieviele Tabellen du schreibst. Und wenn du die Daten dann archivieren sollst (sprich exportieren), kannst du ja per Query nur einen einzigen Messpunkt rausholen, und dessen Daten archivieren. Ich sehe da kein Problem. Naja bis auf eine 5000GB große Datenbank ... in MySQL. Vielleicht solltest du mal fragen, ob jemand schon Erfahrung hat überhaupt so viele Daten in eine MySQL Datenbank zu packen. Die Panzer der USA setzen für derartige Dinge (speichern von Daten) Interbase ein, aber das nur am Rande (ich geh mal davon aus, daß du keinen Panzer programmieren sollst *lach*)

[Bernhard Geyer]

Bei der Anzahl der Datensätze und "einfachheit" eines Datensatzes ist es eh fraglich ob man das Sinnvoll überhaupt jeden Wert als einzelnen Tabelleneintrag eintragen sollte? Evtl. ist eine Speicherung als Blob für größere Zeiträume sinnvoller oder direkt die Meßdaten extern speichern. Es ist nämlich Fraglich ob du noch performant bei mehreren Mio./Mrd. Datensätzen Einträge vornehmen kannst bzw. in endlicher Zeit Reports fahren kannst und zwar ganz unabhängig ob es MySQL oder auch ein MS-SQL oder Oracle wäre.

Ich würde erstmal die Datenbank über mehrere Tage mit Testdaten füllen um zu sehen wie sie überhaupt mit diesem Ansatz reagiert. Die angedachte Trennung ist m.E. bei der Datenmenge sinnvoll (Hab ich schon mal in ähnlicher Form aber bei komplexeren Records auch gemacht). Denn es ist fraglich ob eine Tabelle mit 31 Mio * 10.000 Datensätzen auch mit passenden Indexen auf "normalen" PC's noch vernünftig abfragbar ist. Indexe müssen um schnell zu sein möglichst komplett im Hauptspeicher liegen. Und ob du da mit ein paar GB Hauptspeicher bei voller Datenbank auskommmst? :gruebel:

[nieurig]

Ich würde Bernhard Aussage unterstützen ...

Bei dieser Anzahl von Datensätzen helfen Dir auch die Möglichkeiten zur Segmentierung der Daten (Aufteilung z.B. in zwei Tabellen mit neuen bzw. alten Daten) nicht weiter um Abfragen in vernünftiger Zeit durchführen zu können.

Nimm z.B. ein BLOB-Feld in dem Du den Inhalt einer Textdatei mit allen Messdaten je Tag (oder Stunde?) speicherst. Die Datenbank enthält denn je Zeitintervall einen Datensatz mit dem Inhalt der Datei und ggf. zusammenfassenden Daten die sich aus den Messdaten ergeben und deine Abfragen sind sehr schnell ...

Falls Du wirklich die einzelnen Daten eines Zeitintervalls brauchst, mußt Du eben den gespeicherten Text "auseinandernehmen".

Viel Erfolg.
Niels

P.S.
Die "Vorgaben", die vom Auftraggeber sollte selbst dann hinterfragen wenn dieser EDV-Experte ist. In den meisten Fällen steht hinter der Vorgabe "Jeder Messpunkt soll gespeichert werden" lediglich eine gewünschte Funktionalität. Diese kann man auf unterschiedlichsten Wegen gewährleisten ...

[Ferber]

Ändern die Messpunktwerte sich tatsächlich alle Sekunden ?
Falls nicht, wäre IMHO ein zusätzliches Feld mit Timestamp hilfreich um die Datenflut einzudämmen.
Dem Anwender könnte man dann für die Auswertung ja Sekundenwerte vorgaukeln (oops:generieren).

[Jelly]

Ich komme aus der Physik, und dort sind grosse Datenmengen auch an der Tagesordnung. Was wir aber nie während des Studiums untergekommen ist, ist es all diese einzelnen Messpunkte für immer und ewig zu halten. Vielmehr wurde eine einzelne Messung ausgewertet. Und die Auswertungsparameter wurden aufbewahrt. Nicht jedoch jeder einzelne Messpunkt.

Deshalb frage ich nochmals, was das für Daten sind, dass nach 1 Jahr diese 300 Milliarden Datensätze anfallen. Diese Datenmenge wird kein Computer dieser Welt in akzeptablen Zeiten auswerten können.

Es ist meines Achtens einfach mal ne ordentliche Überlegung wert, was alles gespeichert werden muss, wie man seine Daten strukturiert, und vor allem wie man die Anzahl der Datensätze drastisch senken kann. Wenn mir vorstellen muss, diese Datenmenge soll ein popeliger MySQL Server verwalten, wird mir schlecht. Da geb ich Dir ne 100%-ige Garantie dass das in die Hose geht.

[shmia]

Zitat:

Zitat von Tomektor

Es schaut so aus, also ob man in einen CommandText des ADOCommand nur eine Tabelle ansprechen könnte, aber das ist doch Quatsch.
Ich will doch reines SQL über die Schnittstelle schieben...

Du musst direkt über die ADOConnection arbeiten.

Delphi-Quellcode:

ADOConnection1.Execute(alleSQLAnweisungen);

Zumindest beim MS-SQL-Server kann man so mehrere 100 oder 1000 INSERTs auf einmal abschicken.
Die Jet-Engine (Access) kann das allerdings nicht.
Es hängt also vom Treiber/Provider ab, ob mehrere Anweisungen abgeschickt werden können.

Beachte auch, was <MarcoWarm> in seiner 1. Antwort geschrieben hat.
Es hat damit nämlich völlig recht.
Das Feld "DATUMZEIT" braucht natürlich einen Index.

[Tomektor]

Erst ein mal vielen Dank, für die vielen Antworten.
Das Thema streift den Bereich der Systemgrenzen und scheint ziemlich interessant zu sein.

Mein erstes Posting erfolgte wenige Minuten nach dem ich mit dem Thema konfrontiert wurde. Es gab Vorgaben und wenig eigene Überlegungen.
Nun sieht (auch Dank Euer Anregungen1!) so aus:
- Alle Werte werden in einer Tabelle gespeichert. Diese besitzt ein weiteres indexiertes Feld DPName.
- Die Tabelle wird je 24 Std. aufgeteilt, aber nicht wie vorgeschlagen durch sichern der letzten Daten in einer Backup-Tabelle (zu hoher Ressourcenverbrauch), sondern durch das einfache erzeugen einer neuen Tabelle (z.B.: A20060112 A20060113 usw...) - Jede dieser Tabellen wird somit maximal 20 GB gross.
- Die Daten sollen dauerhaft gesichert werden und da führt einfach kein Weg daran vorbei (Kunde ist König), aber man kann sicherlich die Datenmenge verringern. Der Hauptansatz ist die eine gewisse Abweichungsspanne zu nutzen. Bei den zu archivierenden Werten handelt es sich um recht stabile (ruhige ;) ) Werte. Aus dem Praxisbereicht über das bisherige Tool stellt sich heraus, dass bei einer Mindest-Abweichung von 1%, die Datenmenge sich um den Faktor 100 bis 1000 (je nach Messwert) verringern würde - damit entstehen nutzbare Tabellen von 20-200 MB.
- Für die Zeitspanne zwischen den Einträgen wird bei der Auswertung entweder der letzte Wert genommen oder es wird interpoliert.
- Dass es mit MySQL nicht geht ist klar, aber ich nutze das Teil so liebend gern, dass ich erstmal mich daran versucht habe. Soweit ich weiß erlaubt MySQL4 keine Speicherung von Tabellen über 2GB und auch sonst hatte ich noch kein MySQL-System mit dieser Datenmenge gesehen.
- Zur Verfügung wird wohl ein normaler PC mit 4GB RAM und irgend einem Pentium DualCore stehen.

So langsam glaube ich an die Machbarkeit des Ganzen :)
Das Tool ist ja bereits im Einsatz nur basiert es auf Textfiles (!!!!!). Es wäre ja gelacht wenns nicht mit einer Datenbank klappen würde...

Übrigens ich kennzeichne das Thema als beantwortet, denn Shmia (danke!!!) hat im letzten Post die Lösung geliefert:

Delphi-Quellcode:

ADOConnection1.Execute(alleSQLAnweisungen);

War eigentlich alles was ich gebraucht habe. Trotzdem schöne Diskussion.

Übrigens ohne Details zu nennen. Es handelt sich um ein grosses Gebäude, welches etwa 10000 Messwerte aus der Haustechnik liefert.
Es würde zwar reichen, wenn Meldungen (Alarme) bei Schwellwertüberschreitung dauerhaft gesichert würden, aber...

Reinhauen und schönes WE!

[Jelly]

Auch, wenn Du das Thema als beantwortet siehst... Vielleicht hilft Dir dieser Denkanstoss dennoch, die Datenmeng zu reduzieren.

Ein Messpunkt liefert Dir im Grunden einen einzigen relevanten Wert: dpvalue

Das aber zu hauf, 31 Millionen Werte.

Welche Genauigkeit ist denn nötig. Wenn deine Werte, sagen wir mal, alle zwischen 0 und 1 liegen (beliebig skalierbar), so hast du bei 31 Millionen Werten eine Auflösung von 1/31.000.000, d.h. eine Auflösung von 1:3*10^-8

Ist diese Genauigkeit wirklich nötig ? Wenn nicht, hier mal meine Idee:

Zitat:

Zitat von Tomektor

SQL-Code:

commando := 'INSERT INTO dp1 VALUES (1137061871, 0.568),(1137061872, 0.654),(1137061873, 0.564)';

Wenn ich jetzt mal frech bin, und bei dieser Konstellation davon ausgehen, dass nur eine Genauigkei von 1:1000 ausreicht, so speichere jeden einzelnen möglichen Wert erstmal in einer Tabelle ab, mit deiner gewünschten Genauigkeit, also

Code:

MoeglichenWerte
1 0.000
2 0.001
3 0.002
4 0.003
..
1.000

Deine eigentliche Messreihe referiert auf diese möglichen Werte, und zwar kummulativ.

Code:

Messwerte: 
ID int
Datenpunkt int   (referiert auf eine Tabelle Datenpunkte)
Wert int    (referiert auf MoeglichenWerte)
Anzahl int

Wenn für Datenpunkt ein Wert 0.123 reinkommt, so suchst du nach 0.123 in der Moeglichenwertetabelle, und holst Dir dessen ID (=123).
Suche in Messwerte nach dem unique Record mit gewünschtem Datenpunkt und Wert=123. Findest Du keinen, legst Du einen an. Anzahl setzt du auf 1. Ist bereits ein Record enthalten, so inkrementierst du Anzahl um 1.

10 Messwerte (für gleiche Datenpunkt jetzt mal vereinfacht:

Code:

0.100
0.200
0.250
0.250
0.100
0.300

gibt für Dich in der Messwerte:

Code:

ID      Datenpunkt    Wert    Anzahl
1       1             200     1
2       1             250     2
3       1             100     1
4       1             300     1

Durch diese Struktur reduzierst Du dein Datenaufkommen drastisch, und dennoch sind alle Werte gespeichert.

Einziger Wermutstropfen: eine Information geht Dir so dennoch verloren: wann der Messpunkt aufgenommen wurde.

Ein wirklich ernst gemeinter Rat von (wohl jetzt schon zum 3.): Auch wenn diese neue Struktur jetzt dein Problem nicht ganz abdeckt, mach Dir auf jeden Fall mal ein paar neue Gedanken, wie Du diese Datenmenge reduzieren kannst. Eine gescheite Datenstruktur ist das A und O. Lieber hier bischen Hirnschmalz investieren als einfach blind Milliarden Datensätze zu speichern.

Übrigens noch was zu deinem vorgeschlagenem Rechner mit 4 GB RAM. Alles schön und gut, aber dein DBMS muss dieses RAM auch nutzen können. Die MSDE fällt da schon mal weg, ich glaub die ist limitiert auf 1 GB RAM. Willst Du den restlichen Speicher ausnutzen, so muss der grosse Bruder her (MSSQL Server).

[alzaimar]

Zitat:

Zitat von Jelly

Übrigens noch was zu deinem vorgeschlagenem Rechner mit 4 GB RAM. Alles schön und gut, aber dein DBMS muss dieses RAM auch nutzen können. Die MSDE fällt da schon mal weg, ich glaub die ist limitiert auf 1 GB RAM. Willst Du den restlichen Speicher ausnutzen, so muss der grosse Bruder her (MSSQL Server).

Viel RAM bracht man doch nur bei hochperformanten Auswertungen. Für das Abspeichern ist das unnötig. Die Daten werden sowieso *sofort* geschrieben (ohne Cache, Pufferung etc.) Fürs updaten der Indexe reichen ein paar 100KB Cache.

[Jelly]

Zitat:

Zitat von alzaimar

Viel RAM bracht man doch nur bei hochperformanten Auswertungen. Für das Abspeichern ist das unnötig. Die Daten werden sowieso *sofort* geschrieben (ohne Cache, Pufferung etc.) Fürs updaten der Indexe reichen ein paar 100KB Cache.

Ja, das ist mir schon bewusst. Aber der SQL Server nimmt was er kriegt. Und wenn eh schon ein Dual Prozessor Rechner mit 4 GB RAM da steht bzw. angeschafft werden soll, dann sollte man sich schon bewusst sein, dass man mit der MSDE davon nicht viel zu spüren kriegt.

[sir-archimedes]

Die MSDE fällt ja a priori sowieso direkt raus, da sie maximal 2GB Datenbankgröße kann. Auch der kostenlose SQL Express 2005 fällt daher raus und das kostenlose Oracle Express meine ich auch.

Ich denke aber, das eine Firma, die eine solche Menge von Messpunkten erzeugen/speichern und auswerten möchte, sich auch eine Lizenz für ein richtiges DBMS kaufen kann... Das sollte wohl das kleinste Problem sein! Hoffe ich ;-)

[alzaimar]

Die MSDE ist aber ein bisserl blöd, weil sie nur die Vergrößerung über 2GB nicht mitmacht. Wenn Du ihr eine 3GB Datenbank unterschiebst (oder per Restore erzeugst), funktioniert alles ohne Probleme.
Die k.o. Kriterien sind eher, das die Editionen (MSDE und 2005 Express) nur eine CPU unterstützen, die Anderen liegen brach.
Das Eine GB RAM würde ich als absolut ausreichend ansehen.

mySQL ist (laut Aussage auf mySQL.com) für kleine bis mittlere Tabellengrößen (10-100 Mio Zeilen) gedacht.

Ich weiss nicht, wie schnell mySQL ist (laut Literatur nur mit MyISAM ähnlich schnell wie MSSQL), aber dafür hat die MSSQL ein kleines Programm 'BCP.EXE'. Das ist ein Programm für sehr schnellen Import (10000 Zeilen/Sekunde) von Tabellen. Diese müssen in einem Text-Format vorliegen. Ich hab damit wirklich gute Import-Ergebnisse erzielt.

In der hier skizzierten Problematik würde ich die Rohdaten (wenn man sie denn wirklich alle benötigt) in Textdateien ablegen, und bei geeigneter Größe per BCP importieren lassen. Das Programm zur Messdatenaufnahme erzeugt also immer nur Textdateien mit z.B. 100.000 Zeilen und legt diese Dateien in einem Ordner ab. Ein zweites Programm importiert hintereinanderweg einfach Alles, was in diesem Ordner liegt, in MSSQL.

Das sollte schnell genug sein.

[sir-archimedes]

Du hast trotzdem ja eine Menge Daten: du sprichst von 10000 Datenmesspunkten, die jeweils 1 Messwert pro Sekunde liefern. Das heißt du lieferst 10000 Zeilen/Sekunde, wenn du tatsächlich jeden Messwert als eigene Zeile speicherst. (Die Diskussion war oben - die will ich nicht wieder antreten). Wenn die BCP.Exe nun 10000 Zeilen/Sek verarbeiten kann, geht das gerade eben so gut.

Daher sehe ich das schon noch als Problem - eine Sammlung in Textdateien und anschließende Speicherung fällt also weg - wenn, dann müsstest du schon permanent die BCP.exe arbeiten lassen.

[Jelly]

@Dominik: Aus genau den Gründen versuch ich ja die ganze Zeit eine geschicktere Datenbankstruktur zu forcieren. 10000 Records pro Sekunde sind eine Menge, und gerade wenn bereits zisch Millionen Einträge in einer Tabelle sind, geht das Hintufügen von weiteren Records nicht gerade schneller, geschweige denn spätere Select Abfragen. Egal wie es ist... Aber eine Tabelle anlegen wo man eifach Messpunkt für Messpunkt hinten ranklatscht halt ich definitiv für unpassend.

[alzaimar]

Ich hatte mir die Eckdaten (#Messdaten, #Messpunkte) nicht angeschaut, aber mit BCP oder egal welchem System wird das wirklich auf Dauer Nichts.
Ich habe zwar eine DB, die das kann (Schreiben mit 80.000 - 500.000 Messpunkte pro Sekunde), aber das ist doch nicht die Lösung.

Wir müssen vorher nochmal die o.g. Diskussion aufwärmen. Hier stimmt wirklich etwas nicht. Ich kann mir kein Szenario vorstellen, bei dem man alle 10.000 Messunkte jede Sekunde speichern muss. Die Granularität, also das je Sekunde gemessen wird, kann ich mir gut vorstellen, i.a. ist es aber so, das nur besondere Ereignisse (Statuswechsel) geloggt werden müssen. Insofern wäre es ratsam, je Datentabelle (oder alles in Eine, eigentlich wurscht) eine Spalte 'DateTime' (auf die Sekunde genau) anzulegen und nur diese 'besonderen Ereignisse' abzulegen.

Hier oder im DF hatte ich vor einigen Monaten ein Problem, bei dem *zu Verifizierungszwecken* mal ALLE Messwerte gespeichert werden mussten (20GB pro Tag). Einfach, um die Verdichtungsheuristik, die dann zum Einsatz kommen soll, zu testen. Da waren es knapp 200.000 Daten pro Sekunde. Das bekommt man mit einem schnellen Rechner, B-Baum, Cache und Speicherung in 8k-Blöcken (System page) ganz gut hin. Über den B-Baum hat man dann auch eine schnelle Recherchemöglichkeit. Aber hier sehe ich das nicht. Hier sollte verdichtet und nur Veränderungen gespeichert werden. Alles Andere ist falsches Design (oder man erklärt nochmal kurz, WARUM wirklich ALLE Daten gespeichert werden müssen).