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