ADO Command mit mehreren Inserts

[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 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.
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:
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 von Tomektor:

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