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 :: [log in to unmask] :: http://www.nkuitse.com/
|