On Tue, 18 Aug 2009, Tom Anderson wrote:
On Tue, 18 Aug 2009, Patricia Shanahan wrote:
Stefan Ram wrote:
This should be a common need. Yet I am not aware of anything
like it in Java SE. What is the most common (pure Java)
solution to it?
I would like to have an implementation of java.util.Map,
which is constructed with an int ?m? and a java.io.File ?f?.
It will use no more than ?m? bytes of memory, but ?swap? out
(the least often used) entries to the file ?f?, when they do
not fit into the given memory size anymore.
Have you considered putting the data in a database instead, and using
java.sql to access it? The data structures and algorithms that Java
uses for in-memory maps are not very suitable for disk-based maps.
Database managers use structures and algorithms designed for the job.
'The job' in question being relational data access. Stefan doesn't
want that, he wants to do stores and lookups by key, and nothing else
(well, that and removals, and iteration - but i would imagine the
priority is fast storage and lookup). Yes, this is a subset of what
you can do with a relational data store, but it's quite possible that
an implementation which does keyed storage and nothing else will do it
faster and more efficiently.
And if you don't believe me - how about Oracle?
http://www.oracle.com/technology/products/berkeley-db/je/index.html
Relational databases are the most sophisticated tool available to the
developer for data storage and analysis. Most persisted object data is
never analyzed using ad-hoc SQL queries; it is usually simply retrieved
and reconstituted as Java objects. The overhead of using a sophisticated
analytical storage engine is wasted on this basic task of object
retrieval. The full analytical power of the relational model is not
required to efficiently persist Java objects. In many cases, it is
unnecessary overhead. In contrast, Berkeley DB Java Edition does not have
the overhead of an ad-hoc query language like SQL, and so does not incur
this penalty.
The result is faster storage, lower CPU and memory requirements, and a
more efficient development process.
That software is freeware; if i was going to implement a disk-backed
map, it's where i'd start.
I am not sure that I agree with the argument.