Subject | Re: [Firebird-Architect] Re: Coherence, ACID, and Clusters, et al |
---|---|
Author | Jim Starkey |
Post date | 2008-06-20T20:40:10Z |
paulruizendaal wrote:
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).
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.
Partitioning makes sense to parallelize very large queries, but Web
applications don't have very large queries. Database warehousing does,
but data warehousing doesn't excite me much.
neither interesting nor likely to be fruitful.
Monty. Long winters in Finland. Also black vodka.
James A. Starkey
President, NimbusDB, Inc.
978 526-1376
> "I think the model of a local SQL engine layered on a replicatingPut data doesn't particularly live anywhere specific. It can have many
> object substrate is exactly the way to go."
>
> Whilst I agree, this has lots of interesting problems to solve. One
> such problem is data proximity. Will the query distribute to be close
> to the data or will the data distribute to be close to the query? How
> will partioning work without user configuration of such partioning
> and how can de partions be adjusted in response to changing
> data/access patterns?
>
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).
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.
Partitioning makes sense to parallelize very large queries, but Web
applications don't have very large queries. Database warehousing does,
but data warehousing doesn't excite me much.
> Also, taking a stateless design, the local SQL engines cannot buildI'd go so far as to say counter productive.
> up a stable cache, as its clients are ephemeral. One solution would
> be to also partition the SQL engines; depending on the implementation
> this would abstractly tie the local SQL engine node to a object
> subtrate node. This to me seems less than desirable.
>
> By the way, did you have time to read the Orri Erling post?I don't think trying to build a cloud database around disk pages is
>
neither interesting nor likely to be fruitful.
> PaulLet's not forget my good friend Marten Mickos or my former colleague
>
> PS I just realised the following. Orri Erling (Kubl, Virtuoso),
> Artturi Tarjanne (SolidDB) and Heikki Tuuri (InnoDB) were all
> colleagues in the nineties, back in Finland. Funny, isn't it, how so
> much DB stuff goes back to so few sources.
>
Monty. Long winters in Finland. Also black vodka.
>--
>
James A. Starkey
President, NimbusDB, Inc.
978 526-1376