Actually, one of the strengths of B-trees is that they perform better
than alternatives when *not* kept in RAM. Excerpt from Wikipedia:
: B-trees have substantial advantages over alternative implementations
: when node access times far exceed access times within nodes. This
: usually occurs when most nodes are in secondary storage such as hard
: drives. By maximizing the number of child nodes within each internal
: node, the height of the tree decreases, balancing occurs less often,
: and efficiency increases. Usually this value is set such that each
: node takes up a full disk block or an analogous size in secondary
: storage.
A B-tree's nodes are likely to be cached in RAM whenever practicable,
of course.
Paul.
On Dec 2, 2005, at 3:36 PM, Andrew Nagy wrote:
Roy Tennant wrote:
Andrew, just as an additional data point, we have millions of records
indexed in our Lucene-based XTF system, and the response isn't too
bad even on a development server.
Can you and others on this list briefly describe your hardware platform
for this? I am assuming this is not running on an old 486 that is
lying
around in your office :)
Do you feel that the searching is processor intensive and may be best
suited for a load balanced infrastructure? I am implementing my pilot
using eXist which stores the XML Database in B Trees which from my
knowledge is an in memory data structure so therefor the machine would
need lots of ram however I am curious as to the processing
requirements.
Thanks, you guys rock!
Andrew
--
Paul Hoffman :: [EMAIL PROTECTED] :: http://www.nkuitse.com/
