Stream-basierter Cache

[JuVman5KL]

Hallo zusammen,
ich suche nach einem Cache-Framework, mit dem ich den Inhalt von Dateien verwalten kann, von denen einige mit Sicherheit nicht in den Arbeitsspeicher passen und die in meiner Anwendung ausschließlich mit Streams verarbeitet werden. Die dazugehörigen Dateien sollen zusammen einen bestimmten Speicherplatz auf der Festplatte (als Dateien oder in einem Datenbank-Backend) verbrauchen und dann mit einer Verdrängungsstrategie (LRU, LFU, etc.) gelöscht werden. Das Interface zum Cache muss also in jedem Fall eine Möglichkeit bieten, die Daten Stream-basiert rein- und rauszubekommen.
Hat jemand schonmal von etwas Brauchbarem in die Richtung gehört?

Beste Grüße,
Kalle Richter

 

[dzim]

Wenn ich mich jetzt recht entsinne, bedingt das Öffnen eines FileInputStreams o.ä. nicht automatisch, dass die Datei zuvor auch komplett in den Speicher geschauffelt wurde. Mit den #read-Methoden kannst du ja nur einen bestimmten Abschnitt lesen. Ok, wenn du hier liest wird natürlich was in den Speicher geholt, bis die GC das wieder aufräumt.

Alternativ kannst du natürlich RandomAccesFile verwenden - hier kannst du wirklich enorm schnelle Zugriffe auf ein File realisieren (Beispiel: Die in Linux recht verbreiteten GeoIP-Daten von Maxmind können mit einer Java-API angesprochen werden. Dort wird genannte RandomAccesFile verwendet. Bei meinem alten Arbeitgeber hab ich das mal in produktiven Einsatz gehabt und es waren dadurch mehrere 1000 Dateizugriffe pro Sekunde möglich).

Darüber hinaus kannst du dir auch aus der Klasse einen FileChannel geben lassen, der wohl ein SeekableByteChannel ist und dir damit ähnliche Eigenschaften geben dürfte...

Einziges "Problem" an der Sache: Du musst das Binärformat der Datei kennen/im Griff haben.

 

[dzim]

BTW: Du kannst natürlich auch mit der etwas moderneren API aus dem Packet "java.nio.file.*" arbeiten...

 

[JuVman5KL]

Hallo dzim,
danke für Deine Antwort! Mir ist noch nicht ganz klar, wie ich damit das Problem überwinden kann, dass die Objekte, die der Cache verwaltet zwar im Speicher nur Infos zum Zugriff halten (z.B. ein InputStream mit aktueller Position und ein bisschen bytecode zum Holen des nächsten Pufferinhalts), die Verdrängungsstrategie sich aber ja nicht auf die Größe dieser Objekte beziehen soll, sondern auf die Dateien, für die sie geöffnet wurden). Ich glaube da macht es keinen Unterschied, ob ich (File)InputStream verwalte oder java.nio-Objekt, da das Problem dasselbe ist.
Der GC nutzt nichts, weil die Verdrängung auf der Festplatte stattfinden soll, aber nicht, sobald ein Stream geschlossen und seine Resourcen evtl. vom GC freigegeben werden.

Meine Ansätze waren bisher ehcache mit eigener Sizeof-Implementierung (SizeOf (ehcache 2.8.1 API)), aber das ist nur die Notlösung, wenn es das Rad, das ich nicht neu erfinden will, noch nicht gibt. Auch JCS's auxillary disk cache mit Datenbank-Backend habe ich mir angeschaut (JCS - JDBC Disk Cache), aber es gibt dort keine Möglichkeit die Daten mittels Streams in die DB zu bekommen.

 

[dzim]

Ok. Vielleicht aber verstehe ich auch aufgrund der Menge an Buzzword nicht ganz, worauf du eigentlich hinaus willst 😛