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