On Mon, Feb 2, 2009 at 12:42 AM, Kim Shepherd <k...@waikato.ac.nz> wrote:
> Hi all,
>
> I'm currently developing a standalone stats package to analyse dspace logs
> and generate usage reports based on some custom requirements (similar to
> built-in stats, but with per-author views/downloads statistics, allow search
> for any item/handle to display views/downloads, etc.)
FWIW, I am considering something similar except that the reports are to be
COUNTER-compliant (see http://www.projectcounter.org/about.html). I think
that DSpace needs to consider COUNTER for its stats, especially for use in
the UK.
At the moment, I'm too paranoid to let my stats app query dspace's DB
> directly, and am just regularly dumping tables from dspace and spitting them
> over to a separate database.
The system I am looking at is also considering this. The main reason is that
the system and user base is so large that we do not want the reporting to
consume resources on the machines that are dishing up the content. So the DB
gets regularly replicated to the reporting machines. Sybase has an out of
the box solution for this. I am told that Oracle now has a similar facility
but I don't know any specifics. Still, it means that a DSpace solution with
Oracle might be able to take advantage.
> However, I'm aware that dspace does protect itself from running out of
> resources with a managed connection pool, and that I'm only doing read
> operations. (no UPDATEs or INSERTs, they would only ever happen on my
> separate stats DB).
That's why something like the sybase replication server but for Oracle might
be useful.
>
> at
> Can anyone either (a) confirm that my paranoia is justified,
Yes, I think it is, if the collection and/or user base is very large.
> or (b) point out some safe ways of querying the dspace DB from a standalone
> app? Increase max connections in postgresql to $dspacepool + $statspool + a
> bit of overhead?
>
> At the moment, dumping to a separate DB works fine, but it probably doesn't
> scale very well and just seems like an ugly -- albeit 'safe' -- hack.
>
I agree that is seems ugly but I don't know what else to do either! With a
replication server the solution should be scalable though.
--
Regards,
Andrew M.
http://www.andrewpetermarlow.co.uk
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
