Speicherbedarf von Access-DB sehr groß

[KPBecker]

Hallo, Delphi-Praktiker,

eine Applikation erzeugt große Mengen von Textdateien mit Größen von 4-15 kB, im Mittel ca. 6 kB. Dieses Dateien ähneln Ini-Dateien.
Um nicht Verzeichnisse mit > 100.000 Dateien bearbeiten zu müssen, möchte ich diese Dateien mit einem kleinen Delphi-Programm in einer Access-DB ablegen.
(Verzeichnis durchsuchen mit FindFirst/FindNext, Lesen als StringList mit LoadFromFile, Speichern mit SQL als CommaText, ein Satz pro Datei.)
Felder: Primary-Key, Dateiname (8 Zeichen), Dateidatum, Text als Memo (4.000 - 15.000 Zeichen je Eintrag).

Zu meiner (unangenehmen) Überraschung benötigt die DB ca. 2,5x soviel Platz wie die einzelnen Dateien.
Die Frage, ob PrimKey, Dateiname und Datum indiziert sind, spielt dabei praktisch keine Rolle. Komprimieren der DB hilft auch nicht weiter. Der Overhead durch CommaText erklärt die Situation auch nicht annähernd.

Frage:
Wie kann das sein ? Wofür wird dieser Platz benötigt ?

Vielen Dank,
Klaus-Peter

[s.h.a.r.k]

Die DB speichert ja nicht nur die Daten selbst, sondern wohl auch weitere Informationen, sodass Abfragen wesentlich schneller von statten gehen können. Ich denke, dass wohl auch diverse Caches angelegt werden, sodass z.B. wenn eine Abfrage mehrfach kommt, nicht immer erneut berechnet werden muss.

Und was verstehst du eigentlich unter groß? Wenn eine DB mal mehrere MB groß ist, wäre das imho immer noch nicht wirklich groß. Kommt halt zusätzliche auf die Datenmenge an.

[jobo]

Ich würde mal tippen, dass ACCESS Memos auch mit festen, minimalen Blockgrößen und Vielfachen davon arbeitet, bspw. 8KB.
Wenn Du die Anzahl der Dateien mal dieser (vermuteten 4,8,16.. Kb) Größe nimmst, oder auch noch alle größer 8KB mit 8KB mal 2 usw. rechnest, kommst Du ja vielleicht auf die Größenordnung.
Einfach als Proof.

Wenn Du Platz sparen möchtest, könntest Du doch ein ZIP File oder einen komprimierten Ordner nehmen. Vielleicht gibts da mittlerweile noch andere tolle Möglichkeiten.

[Bernhard Geyer]

Sind die Textdateien Ansi-Codiert? Access speichert String als Unicodestrings und diese haben damit den doppelten Speicherbedarf gegenüber deiner Ansi-Textdateien.

Falls der Platz wichtig ist müsstest du die Textdatei als Blob ZIP-Komprimiert speichern oder ein DBMS nehmen das das automatisch macht (komprimierten von text)

[KPBecker]

@Bernhard: Gute Idee! Ich versuche einmal, die Datei zeilenweise als ANSI-String in die DB zu bringen.

@jobo: Das wäre aber sehr hinderlich, möglich ist das schon. Ich versuche, Informationen über eine Blockgröße für Memos in Access zu bekommen.

@shark: 100.000 Dateien belegen im Verzeichnis ca. 600 MB (bei 6kB/Datei). Schon bei 500.000 Dateien ist das Limit von Access (3 GB) erreicht. Das und dazu der Faktor 2,5 im Speicherbadarf zwischen Verzeichnis --> DB macht die Sache so, wie sie sich jetzt darstellt, in der Praxis für mich uninteressant.
Der Speicherbedarf geht praktisch linear mit der Zahl der Sätze hoch, so daß ein Overhrad für Verwaltungs- und Optimierungszwecke keine große Rolle zu spielen scheint. Der Einfluß von Indizes ist ebenfalls sehr klein. Der Platz wird wohl zur Ablage des Textfeldes gebraucht.

Euch allen vielen Dank !
Klaus-Peter

[Bernhard Geyer]

Zitat:

Zitat von KPBecker (Beitrag 1099635)

@Bernhard: Gute Idee! Ich versuche einmal, die Datei zeilenweise als ANSI-String in die DB zu bringen.

Da müsstest du die Textdateien als Blob speichern. Access hat nur einen Unicode-Textdatenetyp.

[p80286]

Wofür soll das denn gut sein?
Wenn Du Dateinamen "sparen" willst dann pack doch zuzammengehörige Dateien Zusammen:

Code:

copy Datei1+Datei2...Datein Summendatei

(nähere Informationen zu copy enthält die windowshilfe)

Der Faktor 2,5 für den Platzbedarf ist aber noch einigermaßen niedrig. Ich rechne im allg. mit 3,0..4,0

Gruß
K-H

[Perlsau]

Zitat:

Zitat von KPBecker (Beitrag 1099635)

@shark: 100.000 Dateien belegen im Verzeichnis ca. 600 MB (bei 6kB/Datei). Schon bei 500.000 Dateien ist das Limit von Access (3 GB) erreicht. Das und dazu der Faktor 2,5 im Speicherbadarf zwischen Verzeichnis --> DB macht die Sache so, wie sie sich jetzt darstellt, in der Praxis für mich uninteressant. Der Speicherbedarf geht praktisch linear mit der Zahl der Sätze hoch, so daß ein Overhrad für Verwaltungs- und Optimierungszwecke keine große Rolle zu spielen scheint. Der Einfluß von Indizes ist ebenfalls sehr klein. Der Platz wird wohl zur Ablage des Textfeldes gebraucht.

Wieso nimmst du nicht gleich eine richtige Datenbank wie z.B. Firebird? Da ist die Größe der Datenbank nur durch den vorhandenen Plattenplatz begrenzt.

[schorsch666]

Moin,
warum willst du das eigentlich soo machen?? Das Betriebssystem ist doch der schnellste Weg. Auch, wenn die DB mal defekt ist, Sperrung, etc.

Wir betreiben eine Landschaft von über 200 Servern durch die monatlich rund 30 Mio! solcher Dateien gehen. Da gibt es wesentlich elegantere Wege.

Handelt es sich denn um zeitkritische Vorgänge oder hat du nur etwas gegen "große Verzeichnisse"?

Wenn du magst kann ich dir da gerne einige Tipps geben..

Ciao..

Schorsch

[KPBecker]

@Perlsau:
Access ist für mich am einfachsten da vorhanden
MySQL wäre auch noch möglich

@schorsch666 & p80286
Das Ziel war, die Information "übersichtlicher" als in großen Verzeichnissen abzulegen, schnelleren Zugriff auf den Inhalt einzelner Dateien zu haben, die Bearbeitung nach Datum vornehmen zu können und im Datensatz einfach ein "Verarbeitungskennzeichen" mitzuführen. Daher auch die Indizes auf diesen Angaben. Außerdem wollte ich Verschnitt durch die Blockung bei Dateien vermeiden (haha).
Tips sind natürlich immer willkommen.

@Bernhard:
Der Gedanke, daß in einem Memo 2-Byte-Zeichen in der DB abgelegt werden und daher der Faktor >2 in den Größen (Dateien vs. DB) liegt, stimmt möglicherweise nicht.

Versuche:

1. Textfeld als Memo bzw. als OLE (BLOB) definiert, schreiben des Inhalts als Stringlist mit Text.CommaText
--> kein Unterschied in der DB-Größe

2. Umsetzen von Text.CommaText in einen Ansi-String, der dann wie bei 1. in ein Memo bzw. OLE-Feld abgelegt wird
--> kein Unterschied in der DB-Größe

[jobo]

@Versuche 1+2
Ich finde den Gedanken von Bernhard trotzdem gut.
Nur wenn sichergestellt ist, dass der Zielfeldtyp binär ist und kein Textformat, dann wäre es widerlegt. (Vorausgesetzt beim Füllen der Felder passiert keine implizite Umwandlung, bevor es binär gespeichert wird)

Deine Gründe kann ich nachvollziehen. Daher wäre es evtl. eine Alternative, nur die Links auf die Dateien im Filesystem zu speichern. Dann muss aber garantiert sein, dass niemand außer dem Programm drin rumpfuscht.

Konntest Du schon was zum Thema Blockgröße finden?
Ein anderer Test wäre das (einmalige) Speichern einer sehr großen Datei, MB Bereich oder sowas, kann man vielleicht besser prüfen.

Noch eine Idee wäre eine Komprimierung der mdb nach dem Import...

[Perlsau]

Zitat:

Zitat von KPBecker (Beitrag 1099845)

@Perlsau:
Access ist für mich am einfachsten da vorhanden
MySQL wäre auch noch möglich

Firebird ist, da kostenlos im Netz verfügbar, quasi auch vorhanden. Du mußt bei einem Kunden kein Firebird installieren, wenn du die Embedded-Version mitgibst, das ist einfach ein paar DLLs (u.a. fbclient.dll), die im Programmverzeichnis liegen. Der Vorteil gegenüber Access ist gewaltig! Schon allein bei Blob-Feldern: speicherst du in Access z.B. JPG-Grafiken ab, fügt Access dem Pic eigensinnig noch ein paar Byte hinzu, die du beim Auslesen mühevoll wieder wegschneiden mußt. Ansonsten gibt es bei Access nichts, was es nicht auch in Firebird gibt. Für MySQL gibt es meines Wissens nach dagegen keine Embedded-Version.

Zitat:

Zitat von KPBecker (Beitrag 1099845)

Der Gedanke, daß in einem Memo 2-Byte-Zeichen in der DB abgelegt werden und daher der Faktor >2 in den Größen (Dateien vs. DB) liegt, stimmt möglicherweise nicht.
Versuche:
1. Textfeld als Memo bzw. als OLE (BLOB) definiert, schreiben des Inhalts als Stringlist mit Text.CommaText
--> kein Unterschied in der DB-Größe
2. Umsetzen von Text.CommaText in einen Ansi-String, der dann wie bei 1. in ein Memo bzw. OLE-Feld abgelegt wird
--> kein Unterschied in der DB-Größe

Die Größe einer Datenbank kann vor und nach dem Einfügen von Daten gleich sein, du siehst die Größenänderung erst nach einer erneuten Kompilation (bei Access: nach Komprimierung, bei Firebird: nach BackUp & Restore).

[Bernhard Geyer]

Zitat:

Zitat von Perlsau (Beitrag 1099889)

Der Vorteil gegenüber Access ist gewaltig! Schon allein bei Blob-Feldern: speicherst du in Access z.B. JPG-Grafiken ab, fügt Access dem Pic eigensinnig noch ein paar Byte hinzu, die du beim Auslesen mühevoll wieder wegschneiden mußt.

Aber nur wenn du es mit der Access-Oberfläche machst. Über ADO nicht.

Zitat:

Zitat von Perlsau (Beitrag 1099889)

Für MySQL gibt es meines Wissens nach dagegen keine Embedded-Version.

Gibt es. Jedoch hat man bei MySQL die GPL-Falle. Entweder OpenSource oder pro Jahr bis zu 20-30k€ Lizenzkosten für eine unbegrenzte Verteilung. Ansonsten für nicht OpenSource pro Verteilung ein MySQL Serverlizenz.


Um zu sehen wie es gespeichert wird: Einfach Hex-Editor nehmen und nach dem Text der Textdatei suchen. Dann sieht man genau wie es im MEMO/Varchar bzw. im Blob-Feld abgespeichert wird. Oder einfach mal 100.000 mal gleichen Text speichern um ungenauigkeiten von "Blockgrößen-Anforderungen" zu vermeiden.

[franktron]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1099922)

Zitat:

Zitat von Perlsau (Beitrag 1099889)

Für MySQL gibt es meines Wissens nach dagegen keine Embedded-Version.

Gibt es. Jedoch hat man bei MySQL die GPL-Falle. Entweder OpenSource oder pro Jahr bis zu 20-30k€ Lizenzkosten für eine unbegrenzte Verteilung. Ansonsten für nicht OpenSource pro Verteilung ein MySQL Serverlizenz.


Um zu sehen wie es gespeichert wird: Einfach Hex-Editor nehmen und nach dem Text der Textdatei suchen. Dann sieht man genau wie es im MEMO/Varchar bzw. im Blob-Feld abgespeichert wird. Oder einfach mal 100.000 mal gleichen Text speichern um ungenauigkeiten von "Blockgrößen-Anforderungen" zu vermeiden.

Dann nimmt man MariaDB ist ein MySQL Fork und ist komplett GPL V2

[mkinzler]

MySQL ist auch unter GPL verfügbar. Diese verlangt aber dass man sein Programm dann auch unter diser veröffentlicht.

[p80286]

Zitat:

Zitat von KPBecker;1099845@schorsch666 & p80286

Das Ziel war, die Information "übersichtlicher" als in großen Verzeichnissen abzulegen, schnelleren Zugriff auf den Inhalt einzelner Dateien zu haben, die Bearbeitung nach Datum vornehmen zu können und im Datensatz einfach ein "Verarbeitungskennzeichen" mitzuführen. Daher auch die Indizes auf diesen Angaben. Außerdem wollte ich Verschnitt durch die Blockung bei Dateien vermeiden (haha).
Tips sind natürlich immer willkommen.

Wenn Du unbedingt Platz sparen willst, und der direkte Zugriff für den Benutzer nicht gegeben sein muß, alle in Dateinen in einer Datei (pro Tag, pro Monat, pro irgendwas zusammen fassen).
Wenn Du jede Datei mit einem Kenner am Anfabg versiehst, und das Abspeichern auch noch mit brachbaren Blockgrößen erfolgt (Platz sparen??) solltest Du auch schnell zugreifen können.
Nur ist das schon beinahe das Nachbauen einer Datenbank.....

Gruß
K-H