How big is yours?

zgudmunt at my-deja.com zgudmunt at my-deja.com
Tue Jun 27 07:04:43 EST 2000


  Hey, guys, thanks for last time. I have noticed what Ed mentioned
about looking through each of very many objects in a large database
leading  to poor performance. I am mirroring the GDB-database amplimer
objects over to my local Ace, with each amplimer being represented by an
STS-object, with up to 15 aliases each (talk about redundancy!) as a
Text tag. I had a problem at first when I was looking for markers by
aliases if they were not found by name; looking through each of those
100.000+arkers and check their alias was of course mindboggingly slow.
But when I changed the Alias from Text to a XREF to an Alias-object and
queried the Alias-class instead, all was well and fast. It did however
give my over 600.000 Alias objects and increased my dbase size !:)


              Mummi


In article <395087D3.288CE1E8 at sanger.ac.uk>,
  Ed Griffiths <edgrif at sanger.ac.uk> wrote:
> > What are the largest ace databases that people have worked with (in
either
> > size Mb (or even Gb), or number of objects) and have people found
any
> > performance problems with very large databases (obviously this is
> > dependent on the computer hosting and accessing the database).
> >
> > Are there any theoretical limits on the number of objects an ace db
could
> > hold?
>
> This is, unfortunately, a "how long is a piece of string" like
question. The
> number of objects you can stuff into an ace database will be dependent
on the
> size of those objects. I'm sure you can appreciate that the size can
be just
> about anything (allowing for various bits of house-keeping information
that
> every object stored will need). If you mean "can I have a really large
number of
> objects ?", then the answer is yes, you are likely to run out of disk
space
> before acedb runs out of index space.
>
> In terms of performance, again its a bit tricky to be specific, there
are two
> pathological extremes:
>
> 	- if you have very big objects in your database then they will take a
long time
> to load and use up lots of memory.
>
> 	- if you have lots of tiny objects and want to search through them
all without
> using acedbs indexes, then each object must be loaded and explored and
again
> this will lead to poor performance.
>
> Most databases sit in between these two and acedbs indexing allows
many queries
> to be done without the need to load objects and look through them,
thus giving
> very good query performance.
>
> In terms of how big a database can get, well this is (as far as we
know) only
> dependent on the biggest file size that can be supported by a system.
The file
> position is usually given by a "long" which could mean anything from a
32 to a
> 64 bit signed integer. This implies that EACH of the database
blockN.wrm files
> could be huge. In practice operating systems usually only allow file
sizes
> somewhat smaller than the theoretical maximum allowed by the file
position size.
> Its unlikely that this is going to present problems at the moment.
>
> hope this helps a bit...Ed
>
>
------------------------------------------------------------------------------
> | Ed Griffiths, Informatics
Group,                                             |
> |               The Sanger Centre, Wellcome Trust Genome
Campus,               |
> |               Hinxton, Cambridge CB10 1SA,
UK                                |
>
|
|
> | email: edgrif at sanger.ac.uk      URL:
http://www.sanger.ac.uk/Users/edgrif    |
> |   Tel: +44-1223-494780 (switch  +44 1223 834244) Fax: +44 1223
494919        |
>
------------------------------------------------------------------------------
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.








More information about the Acedb mailing list