If you take a look at the comments on the ServerSide article on
Coherence which URL I droped here you will find an interesting
discussion about de pros and cons (mostly cons) of fat data nodes.

Have fun,
PJG

On 2008-06-20, at 22:48, Jim Starkey wrote:

> paulruizendaal wrote:
>> "Put data doesn't particularly live anywhere specific. It can have
>> many locations synchronized with replication or it can be on a disk
>> attached to an archive node (and since the archive node doesn't do
>> SQL,
>> it has to move somewhere else to be processed)."
>>
>> Replicate too much and scalability collapses.
>>
> Platitude. Deduct two points. You might also say "replicate too
> little
> and scalability collapses".
>
> Asynchronous, batched replication isn't expensive. And only do as
> much
> as you need to, of course.
>
> The art is breaking a very large database into manageable size
> objects.
> There's more danger in making them too big than too small. Another
> part
> of the art is keeping request/response round trips to an absolute
> minimum. In fact, I'd say there's a lot of art to be done.
>> "What you really want to do is to direct multiple requests for the
>> same
>> data to one of a smallish subset of nodes. After a short while,
>> those
>> nodes will have most of what they need to handle the requests
>> directed
>> at them."
>>
>> This in effect is the node partioning I referred to. Also note that
>> the
>> one issue high scalability engineers run into is the cost of joins in
>> web scale systems (many advocate denormalising data to deal with it).
>>
> I think more like processor affinity in an SMP scheduler. Send to
> process to where the data is likely to be in cache. If it isn't
> there,
> take the hit and get it.
>
> --
> James A. Starkey
> President, NimbusDB, Inc.
> 978 526-1376
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>