Lokale Archivierung, chronologisch geordnet. Welches DBMS brauche ich?

[Der schöne Günther]

Hinweis: Ich habe bewusst nicht das Datenbanken-Unterforum gewählt da dieses sich mit konkreten Problemem und deren Lösungen beschäftigt. Ich hoffe, das war richtig.

Da ich im Titel schon nach einer konkreten Technologie frage, die ich einsetzen soll ist der Glaubenskrieg möglicherweise schon vorprogrammiert. Ich möchte erst einmal vorstellen, was ich vorhabe, und in welchen drei Dingen ich Rat brauche:

Ich möchte Sätze von Messwerten langzeit-archivieren. Wir sprechen hier über ein, zwei, vielleicht drei Jahre. Darüber hinaus macht es keinen Sinn mehr. Ein Satz von Messwerten ist wiederum mit einem Satz von ganz anderen Messwerten verknüpft. Beide beginnen und enden zur selben Zeit. Und in dieser Zeitspanne fallen einzelne, für sich genommene Ereignissee an. Die möchte ich auch mitloggen.
Auf Dauer ist mit ein paar zehn- oder hunderttausend solcher Sätze an Messwerten zu rechnen. Fast schon ein Stack - Bereits geschriebene Datensätze werden nicht mehr verändert.

Ich habe nun praktisch null Praxiserfahrung mit Datenbanken: Mehr als wahllos Daten in bereits bestehende Postgres, Advantage oder SQLite-DBs werfen und lesen habe ich nie gemacht. Nun geht es um den Aufbau eines neuen Systems.

1a) Allen Datensätzen haftet bei ihrem Eintrag in die DB der momentane Zeitstempel an. Soll heißen: Die "natural order" in der DB ist ihre wirkliche chronologische Reihenfolge. Nehmen wir an, ich möchte nun alle Datensätze, die zwischen November 2013 und Februar 2014 liegen. Was muss ich tun, damit das DBMS so schlau ist, sich nicht jeden der Datensätze anzuschauen, ob er in den gewünschten Zeitrahmen passt? Reicht die Verwendung eines nativen "TIMESTAMP"-Datentyps für eine Spalte? Muss ich mehr beachten? Oder habe ich sowieso keinen Einfluss, was sich hinter den Kulissen abspielt und muss mit wachsender DB hilflos zuschauen, wie die Performance immer weiter in den Keller geht?

1b) Die Daten sollen lokal auf einer einzigen Maschine gespeichert werden. Geht diese in Flammen auf, hat man eben Pech gehabt . Oder vorher eine "Kopie" der Datenbank auf einen Netzwerkpfad, USB-Stick oder gesichert. Es sollte sich so einfach lösen lassen, wie eine (oder mehrere wenige) Datei im Windows-Dateisystem zu kopieren. Die "Wiederherstellung" sollte sich auch vom Kunden selbst bewerkstelligen lassen. Wenn ich, wie bsp. bei SQLite, eine einzelne Datei kopiere und habe wieder den gesicherten Stand - Perfekt.

2) Das Projekt wird momentan nur mit dem RAD Studio XE4 Enterprise gebastelt, deshalb wäre es mir lieb, auch mit Delphi oder dem C++ Builder direkt ewtas basteln zu können. Ist zwar kein Muss; Wenn ich allerdings sehe, was für Mengen an DB-Funktionalität und klangvolle Namen (FireDAC, dbExpress, InterBase,...) einem von Embarcadero gleich um die Ohren gehauen werden, wäre es natürlich gut, gleich so etwas, das bereits "dabei" ist, zu nutzen.
Bislang kommt als lokale DB der Advantage Local Server zum Einsatz. Der sieht schonmal nicht übel aus. Vor SQLite hätte ich, aufgrund der Datenmengen, etwas Angst.

Ich frage nun nach einer konkreten Technologie, mit welcher ich Punkte 1a) und 1b) am besten erreiche. Ist die Advantage Local DB geeignet? Scheidet SQLite aufgrund der Datenmengen aus? Ich habe null Praxiserfahrung und langsam gehen mir auch die Ideen aus wie man ein "Ich habe keine Ahnung, sagt mir einfach, was ich nehmen soll" weiter hinter blumigen Worte verstecken kann.

Daher bedanke ich mich fürs Lesen und harre weisen Ratschlägen.

[joachimd]

Da Du schon speziell nach dem ALS fragst: Ein Index auf einem Timestamp-Feld genügt, um auch bei vielen tausend Datensätzen schnell filtern zu können (1a). Zur Datensicherung (1b) einfach das Programm beenden und den Daten-Ordner weg kopieren - geht auch hervorragend als batch mit gleichzeitigem packen danach:

Code:

@echo off
cls
set ordnername=data
set archivname=MyBackup%date:~6,4%%date:~3,2%%date:~0,2%.rar
set password=-hpGEHEIM

"%programfiles%\winrar\rar.exe" a -r %password% %archivname% %ordnername%
copy %archivname% c:\mnt\myotherdevice
rem del /F /S /Q %archivname%
pause

[mkinzler]

Es gibt keine "natural order":
-Beim Löschen entstehen Lücken, welche später gefüllt werden.
-Abfragen verwenden Indizes, so dass Ergebnisse eine andere Reihenfolge haben können.

Jedes aktuelle DBMS sollte deinen Anforderungen genügen.

zu 1a) TIMESTAMP sollte reichen; Index auf Spalte
zu 1b) Entweder Sicherung auf Netzpfad oder Replikation

zu 2) Mit FireDAC sollte jedes aktuelle DBMS unterstützt werden. Als Datenbanksystem würde auf Firebird verwenden ( wenn dich nicht stört das es OpenSource ist; für manche ist das ja ein absolutes NoGo, da kein garantierter Support und Weiterentwicklung) sonst halt MSSQL oder ein schon vorhandenes DBMS ( z.B. Oracle, dann gibt es vor Ort einen der sich damit auskennt - sonst lieber nicht).
Aber das verwendete DBMS ist eine Geschmacksfrage, bei der es viele verschiedenen Meinungen gibt.

[generic]

Als mögliche Techniken des Datenbanksystems schmeiße ich mal Tabelle Partitionierung z.B. nach Jahren vor oder einfach BigData/NOSQL Ansätze (Map and Reduce).

[Der schöne Günther]

Danke für die Antworten

Zitat von mkinzler:

Es gibt keine "natural order":
-Beim Löschen entstehen Lücken, welche später gefüllt werden.

Gerade das ist, soweit ich das durch Hörensagen mitbekommen habe, bsp. bei der Advantage DB nicht der Fall. Die Reihenfolge bleibt erhalten, die Datensätze werden noch nicht einmal gelöscht, sondern nur ein "deleted"-Flag gesetzt.

Das momentane Produkt nutzt auch genau das aus, indem es sich die RowIDs als Pseudo-Fremdschlüssel auf andere Tabellen nutzt. Und das funktioniert seit etlichen Jahren.

Zitat von joachimd:

Da Du schon speziell nach dem ALS fragst: Ein Index auf einem Timestamp-Feld genügt, um auch bei vielen tausend Datensätzen schnell filtern zu können

Bei einem kleinen Test gestern mit einer Advantage 9.0 habe ich innerhalb von einer Zehntelsekunde alle Datensätze innerhalb eines Zeitbereichs aus einer DB von ca 85.000 Datensätzen geholt. Das sah schon sehr gut aus, aber trotzdem kann ich bei einer größeren DB und Verknüpfung von zwei oder drei Tabellen nur ungerne ein, zwei Sekunden warten. Ich möchte nutzen, dass eigentlich schon vorher relativ sicher ist, wo in der DB ich meine Datensätze finde. Oder geben das relationale DBMSs einfach nicht her?

Ihr beide sprecht vom einfachen Kopieren von Daten, da hake ich lieber gleich nach: Vor vielen Wintern hatte ich unter Java Kontakt mit Postgres-Datenbanken, Linux wie Windows. Ich habe irgendwie noch im Hinterkopf, dass sich gerade unter Windows in der Registry und Systemverzeichnissen alle möglichen Einstellungsfitzel verteilen und eine Datenbank sich nicht einfach in einen Koffer packen und transportieren ließ. War das eine hässliche Ausnahme?

Zitat von mkinzler:

Aber das verwendete DBMS ist eine Geschmacksfrage, bei der es viele verschiedenen Meinungen gibt

Vielleicht hätte ich noch erwähnen sollen, dass dafür möglichst nichts gezahlt werden sollte
Deswegen das explizite Interesse für Dinge, die bei RAD Enterprise wohl schon "dabei" sind.

Zitat von generic:

Als mögliche Techniken des Datenbanksystems schmeiße ich mal Tabelle Partitionierung z.B. nach Jahren vor oder einfach BigData/NOSQL Ansätze (Map and Reduce).

Zu nicht-relationalen Datenbanken habe ich noch nicht einmal Theoriewissen, deshalb scheidet das leider vorerst vollkommen aus.

[jobo]

"jedes aktuelle RDBMS..."
Also Oracle kann ich nicht empfehlen. Ein Backup mal eben durch kopieren der Tablesspace Files anzufertigen kann gut in die Hose gehen..

[mkinzler]

Zitat:

Gerade das ist, soweit ich das durch Hörensagen mitbekommen habe, bsp. bei der Advantage DB nicht der Fall. Die Reihenfolge bleibt erhalten, die Datensätze werden noch nicht einmal gelöscht, sondern nur ein "deleted"-Flag gesetzt.

Das momentane Produkt nutzt auch genau das aus, indem es sich die RowIDs als Pseudo-Fremdschlüssel auf andere Tabellen nutzt. Und das funktioniert seit etlichen Jahren.

Dann scheint es bei ADS im besonderen so zu sein. Es wird aber auch dort eine Funktionalität geben (Zap o.ä) um die Datensätze zu löschen.

Zitat:

Ihr beide sprecht vom einfachen Kopieren von Daten, da hake ich lieber

Ich sprach von Sicherung oder Replikation, beides ist nicht einfaches Kopieren. Bei der Sicherung wird im Betrieb eine Kopie gezogen ( normalerweise in einen besonderen Format). Bei Replikation werden Änderungen auf ein anderes System übertragen ( kann auch eine zentrale DB für mehrere lokalen DBs sein, welche die Daten der lokalen umfasst).

Zitat:

Also Oracle kann ich nicht empfehlen. Ein Backup mal eben durch kopieren der Tablesspace Files anzufertigen kann gut in die Hose gehen.

Ich würde von Kopieren auch grundsätzlich abraten.

[jobo]

Zitat von Der schöne Günther:

Danke für die Antworten

Zitat von mkinzler:

Es gibt keine "natural order":
-Beim Löschen entstehen Lücken, welche später gefüllt werden.

Gerade das ist, soweit ich das durch Hörensagen mitbekommen habe, bsp. bei der Advantage DB nicht der Fall. Die Reihenfolge bleibt erhalten, die Datensätze werden noch nicht einmal gelöscht, sondern nur ein "deleted"-Flag gesetzt.

Je nach Datentyp / Timestamp Genauigkeit und Frequenz der Messwerte sorgt nicht mal der Timestamp für die "natural order".
Dabei muss man im Grunde sogar darauf achten, ob Speichergenauigkeit und Auflösung des generierten Zeitwerts ausreichen.
Sicherheitshalber empfiehlt sich eine Sequenz / AutoID an der Stelle.

[mkinzler]

Zitat:

Sicherheitshalber empfiehlt sich eine Sequenz / AutoID an der Stelle.

Das würde ich zusätzlich immer tun. Der Einsatz von syntetischen Schlüsseln ist aber auch eine Glaubensfrage.

[Der schöne Günther]

Danke für die Antworten soweit.

In Sachen "Sicherung" war ich möglicherweise zu ungenau: Das Exportieren von ge-backupten Daten und Wiederherstellen sollte sich entweder über eine mit der heißen Nadel gestrickten Anwendung von mir oder direkt über den Windows Explorer bewerkstelligen lassen. Den Nutzer will ich nicht direkt an an DB-Verwaltungssoftware lassen, damit käme er auch nicht zurecht.