Collections Speicherproblem

[wersi77]

Hallo zusammen,

ich schreibe gerade an einem Programm zum Einlesen großer Datenmengen (ca. 80MB txt-Datei).
Hierbei werden die einzelnen Zeilen nach Schlüsselworten durchsucht und dann in die entsprechenden HashMaps geschrieben, damit anschließend besser auf die gelesenen Daten zugeriffen werden kann.
Damit das Programm fehlerfrei durchläuft, muss ich den VMProperties folgendes mitgeben -Xmx512m.
ansonsten bekommen ich eine Exception like:
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

Gibt es eine Möglichkeit dieses Speicherproblem anderweitig zu lösen? Bisher ist mir nur in den Sinn gekommen nur die Schlüsselwörter einzulesen, welche auch einen zugehörigen Wert besitzen und nicht auch "" im Hashmap abzuspeichern. Oder ist HashMap an dieser Stelle vielleicht sogar eine sehr speicherraubende Variante?

Bitte um Ideen.
Vielen Dank

 

[SlaterB]

80 MB Rohdaten können im Java-Speicher durchaus in diese Regionen kommen, wenn du bis auf 1-2GB hochgehen kannst,
mag es vorerst reichen,

ob du wirklich alle Daten gleichzeitig brauchst ist grundsätzlich eine Frage, ohne Information kann man das
(wie die weiteren Ideen) nur in einem Satz ansprechen,
ne Map sieht ja danach aus

Zwischenvarianten:
- Daten einlesen, in Teilen sortieren, am Ende sortiert vorliegen haben um dann endlich nicht mehr vollständig zu benötigen
sondern dann nacheinander einlesen zu können
- Map nur mit kurzen Ids/ Infos, anhand derer von woanders umfangreichere Daten nachgeladen werden können

alle Daten im Speicher:
wie man das optimieren kann hängt von den Daten ab, eine Zeile als String ist wohl günstiger als ein verarbeiteter Datensatz,

gibt es andererseits viele gleiche Texte/ Bausteine?
ich fand schon immer interessant, noch nicht wirklich allzu genau ausprobiert, Strings zu ersetzen:
1000x "Fussball" aus Datei eingelesen sind 1000 verschiedene Strings, je ein Objekt mit internen char[] usw., ziemlich groß,
wenn man dagegen häufige Wörter in einer Map speichert oder vielleicht intern() benutzt, dann braucht nur ein String "Fussball" im Speicher und tausend Stellen verweisen mit je nur 4 Bytes darauf


soweit lose paar spontane Gedanken, die meisten Richtungen vielleicht egal

 

[Kjubert]

1000x "Fussball" aus Datei eingelesen sind 1000 verschiedene Strings, je ein Objekt mit internen char[] usw., ziemlich groß,
wenn man dagegen häufige Wörter in einer Map speichert oder vielleicht intern() benutzt, dann braucht nur ein String "Fussball" im Speicher und tausend Stellen verweisen mit je nur 4 Bytes darauf

RLE im Programmablauf :reflect:

 

[parabool]

Die Frage ist, ob es tatsächlich die HashMap ist die das Speicherproblem verursacht.

Im ersten Moment dachte ich auch , warum keine DB ? (Performance/langsamerer Zugriff als auf HashMap?)

Es gibt auch key-value - basierte NoSQL-DB's z.B Redis
Diese kann soweit ich es richtig verstanden habe, In-Memory arbeiten als auch bei Bedarf auf Persistent.

 

[timbeau]

DBs sind deutlich(!) langsamer als ne Map.

80MB dürften aber keine Probleme bereiten wenn das nur Key-Value-Paare sind. Was sind schon 80MB?

 

[SlaterB]

> Was sind schon 80MB?

wie gesagt als reine Daten auf der Festplatte in Java dann gerne das Zehnfache

 

[parabool]

DBs sind deutlich(!) langsamer als ne Map.

Ja klar. Aber man kann fragen:

1 Ab wieviel Einträgen hebt sich das auf oder kehrt sich um (wenn es das denn tut.Ich vermute mal: ja) ?
(mal vorausgesetzt DB ist auf selben Rechner)

2 Ab wieviel ms Unterschied opfert man die Zeitersparnis gegen flexiblere und speichertechnisch günstigere DB-Lösung ?

nebenbei: Besagte redis db soll ja wesentlich schneller als relationale. DB's sein.

 

[timbeau]

ME lohnt eine DB nur dann, wenn man auch die Möglichkeiten der DB braucht. Ansonsten sind ganz viele Persistierungen besser. Und ne DB im Ram wird wohl rausfallen.