Subject | Re: Cloud databases |
---|---|
Author | paulruizendaal |
Post date | 2008-07-25T11:37:54Z |
--- In Firebird-Architect@yahoogroups.com, Roman Rokytskyy <roman@...>
wrote:
sure if those definitions are commonplace, but I find them practical.
I think that partioning data across an elastic cloud is a major bit of
code. Probably it could be layered into a "distributed disk server"
component and the other layers of code would not be affected much.
Would that lead to optimal perfomance? One would for instance give up
the ability to let the optimiser make different plans for local & non-
local data.
Perhaps I am overestimating the problem. Probably you are a key member
of a JDisk project that already solved the issues involved :^)
Paul
wrote:
>In Jim's definition, a cluster is static and a cloud is elastic. Not
> > Another solution is to partition the data, but that complicates the
> > architecture and lengthens many code paths.
>
> Why that? If I am not mistaken, EnterpriseDB or Green Plum go for
> data partitioning... Ok, those are DWH systems, but Google and Amazon
> go for data partitioning as well.
sure if those definitions are commonplace, but I find them practical.
I think that partioning data across an elastic cloud is a major bit of
code. Probably it could be layered into a "distributed disk server"
component and the other layers of code would not be affected much.
Would that lead to optimal perfomance? One would for instance give up
the ability to let the optimiser make different plans for local & non-
local data.
Perhaps I am overestimating the problem. Probably you are a key member
of a JDisk project that already solved the issues involved :^)
Paul