paulruizendaal wrote:

> --- In Firebird-Architect@yahoogroups.com, Roman Rokytskyy <roman@...>
> wrote:
>
>>> 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.
>>
>
> In Jim's definition, a cluster is static and a cloud is elastic. Not
> sure if those definitions are commonplace, but I find them practical.
>

Having spent a week or two on a Google "cloud computing list", there is
no doubt in my mind that "cloud computing" is one of the most ambiguous
terms in all of computingdom. Techies tend to use the term "cloud" to
mean a platform where a bunch of computers behaves more or less as one.
Most people (> 60%) consider cloud computing to mean a virtual server
hosted elsewhere. The disconnect is essentially the difference between
Google and Amazon. Google uses a cloud to do things that couldn't
possibly be done on a single computer in the time available. Amazon
uses a cloud to host a zillion virtual servers. I consider the Amazon
version boring and limited, but that's not the way the zealots see it.

That said, I'm sticking with my definition of a cloud as elastic set of
heterogeneous machines cooperating as one.

> 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.
>

Don't quote me, please, but recent experience has left me with a deep
distaste for partitioning. If you're designing a database to run inside
a cell phone switch and 99.99% of the load is "where is 978 526-1376",
partitioning makes sense. There are probably other applications for
which it is a solution, but I haven't stumbled across them yet.

But certainly if you partition data across a fixed number of systems,
then change the number of systems, the result is going to be unpleasant.

--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376