Cool, this looks like it could be used. Do you have design docs
somewhere? Apologies I haven't been paying more attention to this.
A few questions, though I'm completely fine if the answer to them is to
just look at the docs. I found
http://docs.codehaus.org/display/GEOTOOLS/SoC+2007+Caching+data
Did you implement the cache yourself, or are you leveraging existing
caching projects like OSCache and JBoss cache and the like? If you're
not, would it be possible to use one of those? Ideally one could use
your cache with an existing cache that's set up?
How far in your plan did you get? Do you have a disk caching datastore?
Does it have an LRU eviction strategy or anything like that? Like
from memory to disk to completely out?
Do you handle transactions? Like if I do a transaction does it pass to
the main datastore and update it and expire the cachingdatastore's value?
If you've got disk working, how are you storing the features on disk?
Did you get the offline mode stuff working? I've been thinking about
such things, but more with regards to a WFS datastore that does good
caching. But could potentially reuse some of your code. There may be a
project coming up which would allow some work on this.
Sorry for all the questions, this work is very interesting to me. Are
you planning on continuing it at all? I'd like to perhaps try to get
some of it in GeoServer, as I think it could be valuable there. But
would likely be most valuable if it could be disk cached and get that
piece _really_ fast, since it could be more efficient than storing full
tiles.
Chris
Christophe Rousson wrote:
2007/9/11, Chris Holmes <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
Do you have some benchmarks online anywhere?
To give you an idea, I set up a regression test with a dataset of 5000
random features in the unitsquare, put these in a MemoryDataStore and
ran 150 queries (queries are such that one query is in the neighbourhood
of the previous one). Query window size is between 1/20 and 1/100 of the
unitsquare.
In the worst case (the cache needs to query the source datastore and
load new data in its storage), the overhead is on average +300 ms/query
compared to MemoryDataStore.
The mean query execution time difference is about 40 ms in favor of the
cache, as it uses indexation.
There are however some limitations :
. I only implemented a grid index, which is likely to be suboptimal in
many cases. Quadtree or rtree index would do better, but there is not
much work to do to adapt the cache on these.
. the cache stores features on a per feature type basis. It actually
extends FeatureSource rather than DataStore, but it would be easy to
wrap a number of cache instances around a DataStore to create a cached
DataStore.
. current implementation is read-only, though it should be easy to make
it write-thru.
Also, do you have a sense of how easy this might be to include in
GeoServer? We use the datastore api directly, with the SPI mechanism to
make things plug-ins. But I imagine yours would be a bit different
since it probably depends on another datastore that it's caching? Or
maybe I'm totally misunderstanding your work. It sounds like the ideal
would be to have a button in our UI that lets you wrap any of the
normally configured datastores with a caching one.
I think a sample code will do for a demonstration :
int feature_type_index = 0;
int number_of_nodes = 500;
int cache_feature_capacity = 1000;
DataStore ds = ... ; // get any instance of a datastore
FeatureCache cache = new GridFeatureCache(
ds.getFeatureSource(ds.getTypeNames()[feature_type_index]),
number_of_nodes,
cache_feature_capacity,
BufferedDiskStorage.createInstance());
// cache may be used anywhere you would normally use FeatureSource
I hope this somehow answers your questions.
cheers,
Christophe
!DSPAM:4005,46e72e8c94181431913854!
------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
!DSPAM:4005,46e72e8c94181431913854!
------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
!DSPAM:4005,46e72e8c94181431913854!
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
