Hi,
so I've spent some time building a epsg-h2 authority
factory using the latest and greatest of the EPSG
databases, version 7.1
The results are... ok. But not great.
Compared to the HSQL, the H2 provider is not significantly
faster. I've made two tests.
The first scans just once the whole authority an CRS.decodes
all the known codes. The H2 authority has 4400 codes
whilst the HSQL one has 3800 (older EPSG database),
the H2 takes around 9.5s, the HSQL one around 7.8s,
the difference is fair given the bigger amount of
codes in the H2 one.
The I made a stress test, 100 threads that each decode
1000 random codes, the H2 does it in 79s, the HSQL
one in 90s. So, not bad.
One very nice thing is that H2 eats the official
EPSG scripts for postgres verbatim, no changes needed.
Another downside is disk consumption, hsql used 8MB,
h2 uses 36MB. Now, I understand I'm not comparing
apples to apples, but the database did not actually
grow that much, it's more that HSQL has a compation
command ("shutdown compact") that H2 has not (it's
in the roadmap).
On par with HSQL is also the ability to share the
same DB with multiple processes, something that
I verified it's not possible with Derby.
GeoToolkit has been bitten by this one,
see http://jira.geotoolkit.org/browse/GEOTK-13,
and the solutions are not so great. Do you
picture someone setting up a server mode database
just to run on the same machine uDig and GeoServer?
(or any other GeoTools based application?)
Oh, I also tried out putting the database in a zip
file. First off, it's still not possible to put
the zip in the classpath (bummer), thought some
workarounds are suggested, which are not going
to help that much I fear (getting
the full location using class.getResource,
what if the zip is in a non exploded .war?)
Also, the performance/size tradeoffs are not great.
If I create the zipped version with normal compression,
the zip is less than 2MB, but a simple test that
extracts all the CRS from the database takes 30 times more!
If, on the contrary, the zip is created with no compression
(pure storing) the performance is almost identical to
the standard version, but the zip file is 45MB.
Hummm... I guess there is still reason to upgrade
to H2, the db is maintained and unlike HSQL it can eat
non ASCII strings just fine
(see http://jira.codehaus.org/browse/GEOT-2493).
Yet, the reasons are not as great as I hoped.
Oh, another thing I've made during my tests is to
make each version of the database be created in
its own folder: this way applications using
multiple versions of GeoTools can coexist in peace
in the same system (the old HSQL authority wiped out the
older version and created the new one, creating some
troubles for the older systems).
So, I'd propose to commit epsg-h2, graduate it
to supported land, move epsg-hsql to unsupported,
and check everything works fine for everybody.
Opinions?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
