Hi all,
I waned to poll the list to do some brainstorming about how to go about
archiving request data information in the monitoring extension.
As it stands now the extension simply persists request data (via hibernate)
into a single table called "REQUEST". You can imagine that a busy server
will fill this table up quite quickly eventually getting to the point where
operations start to perform poorly. So some sort of strategy to clear out
the main table and possibly archive existing information will be needed.
My practical database admin experience is quite limited so i am very eager
to hear thoughts on this one. But that said I can think of a couple of
different ways to skin this cat.
1) no archiving
Sort of lame, but leave all facilities for archiving to the db admin. The
main downside of this is that it makes it impossible for the monitoring
extension to retrieve historical request information for reporting purposes.
So we would basically saying you can only do your own analysis on
your achieved data.
2) automated archiving
Flipping the coin would be to attempt to archive request data transparently.
I tried to google for information about people using hibernate that need to
archive in this manner but could not come up with much. One thought I had
was to come up with a second mapping, creating a table "REQUEST_HISTORY".
And periodically move data from one table to the other. However i am not
sure how feasible this is strictly going through hibernate. It seems kind of
clunky and could be problematic to try and synchronize, trying to archive
while the server is still under a load. I guess we could only support an
"offline" archiving...
Another thought I had that is less hibernate centric would be to use
triggers. Basically duplicate the REQUEST table creating REQUEST_HISTORY and
set up a trigger on the main table so that any insert results in a duplicate
row in the history table. Then an "archive" really just becomes clearing out
the main request table. Obviously this would not be possible with straight
hibernate so would require some homegrown jdbc stuff. Which gets tricky when
you try to support different databases, messing with dialects is sort of a
messy business.
3) hybrid
The third solution would sort of be a hybrid. Basically we would not provide
any archiving facilities leaving it up to the admin. But we would support
querying a REQUEST_HISTORY table (if it exists) in order to retrive the
historical information.
Thats all I got. Any feedback on this one would be much appreciated.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
