Thread

Re: question/suggestion Message-id: <493823B5.1030400@hogranch.com>

chrisj <chrisj.wood@sympatico.ca> — 2008-12-07T01:43:23Z

> yet you propose dumbing down the database even farther, without any hope
of ACID

> compliance, without any transactional integrity, indeed, without even
really being

> relational ? 

> at least, thats what I get from my first read of it.

 

OK so you are a theorist/perfectionist, I can respect that.  Perhaps what I
meant to say instead of "dumbing down the database" was "dumbing down the
use of SQL to the point where it is not much better that indexed-style reads
and writes".

 

Is my idea perfect? No, far from it, and if there are better ideas out there
then great, I hope they get pushed forward.

 

But I do believe my idea is far better than the alternative of sticking our
heads in the sand and hoping that cloud computing goes away and in the mean
time web developers are stuck using databases that only support very "dumbed
down" SQL sub-sets/derivatives like Google's GQL or  Amazon's SimpleDB query
syntax.

 

At a detailed level (which is NOT the direction I want this thread to go) I
do not agree with your statement that my proposal has no "hope of ACID
compliance or transactional integrity".  When the "slices" are stored back
to the cloud, this is the equivalent of a commit and the integrity thereof
is as good as what ever the underlying technology is.  Is the concurrency as
good as native Postgres?  Of course not. Is the commit/rollback flexibility
as good as native Postgres? Again no. But what's the alternative? Watch
cloud computing take off leaving Postgres with the reputation of "great
database software in yesterday's era of monolithic servers"?

Re: question/suggestion Message-id: <493823B5.1030400@hogranch.com>

John R Pierce <pierce@hogranch.com> — 2008-12-07T02:08:13Z

chris wood wrote:
> At a detailed level (which is NOT the direction I want this thread to 
> go) I do not agree with your statement that my proposal has no “hope 
> of ACID compliance or transactional integrity”. When the “slices” are 
> stored back to the cloud, this is the equivalent of a commit and the 
> integrity thereof is as good as what ever the underlying technology 
> is. Is the concurrency as good as native Postgres? Of course not. Is 
> the commit/rollback flexibility as good as native Postgres? Again no. 
> But what’s the alternative? Watch cloud computing take off leaving 
> Postgres with the reputation of “great database software in 
> yesterday’s era of monolithic servers”?

even something as simple as a SERIAL sequence would be a nightmare in a 
distributed cloud environment without a complex centralized arbitrer. 
the same goes for most any other sort of update/query that depends on 
consistency of data.

How do you reconcile a bank account when the money has been 
simultaneously withdrawn from several ATMs at different locations at the 
same time? "Please, sir, give us our money back?" ? I don't think the 
banks would be happy with that implementation.

If the data is partitioned across the cloud ('one version of the 
truth'), things like JOINs are very very difficult to implement 
efficiently. take away JOINs and you might as well be doing simple ISAM 
like we did back in the 70s before Codd and his Relational Database 
concepts upon which SQL is based.

no, IMHO, the cloud people are better off inventing their own data 
models and their own proprietary query languages suited to the 
architecture. maybe SQL and its concepts of 'one version of the truth' 
and 'data integrity' are quaint relics of another age, so be it.

Re: question/suggestion Message-id: <493823B5.1030400@hogranch.com>

Mark Kirkwood <markir@paradise.net.nz> — 2008-12-07T06:26:47Z

John R Pierce wrote:
> chris wood wrote:
>> At a detailed level (which is NOT the direction I want this thread to 
>> go) I do not agree with your statement that my proposal has no “hope 
>> of ACID compliance or transactional integrity”. When the “slices” are 
>> stored back to the cloud, this is the equivalent of a commit and the 
>> integrity thereof is as good as what ever the underlying technology 
>> is. Is the concurrency as good as native Postgres? Of course not. Is 
>> the commit/rollback flexibility as good as native Postgres? Again no. 
>> But what’s the alternative? Watch cloud computing take off leaving 
>> Postgres with the reputation of “great database software in 
>> yesterday’s era of monolithic servers”?
>
> even something as simple as a SERIAL sequence would be a nightmare in 
> a distributed cloud environment without a complex centralized 
> arbitrer. the same goes for most any other sort of update/query that 
> depends on consistency of data.
>
> How do you reconcile a bank account when the money has been 
> simultaneously withdrawn from several ATMs at different locations at 
> the same time? "Please, sir, give us our money back?" ? I don't think 
> the banks would be happy with that implementation.
>
> If the data is partitioned across the cloud ('one version of the 
> truth'), things like JOINs are very very difficult to implement 
> efficiently. take away JOINs and you might as well be doing simple 
> ISAM like we did back in the 70s before Codd and his Relational 
> Database concepts upon which SQL is based.
>
> no, IMHO, the cloud people are better off inventing their own data 
> models and their own proprietary query languages suited to the 
> architecture. maybe SQL and its concepts of 'one version of the truth' 
> and 'data integrity' are quaint relics of another age, so be it.
>
>

Objecting to an idea because it is difficult to implement is not 
necessarily a clincher - there are projects trying to adapt Postgres to 
more cloud-like capabilities (e.g Greenplum, Netezza) - neither of these 
are open source however. There is also Pgcluster, however I'm not sure 
that counts as cloud-like in its architecture...

regards

Mark