Re: question/suggestion Message-id: <493823B5.1030400@hogranch.com>
От | Mark Kirkwood |
---|---|
Тема | Re: question/suggestion Message-id: <493823B5.1030400@hogranch.com> |
Дата | |
Msg-id | 493B6CA7.2090100@paradise.net.nz обсуждение исходный текст |
Ответ на | Re: question/suggestion Message-id: <493823B5.1030400@hogranch.com> (John R Pierce <pierce@hogranch.com>) |
Список | pgsql-bugs |
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 whats the alternative? Watch cloud computing take off leaving >> Postgres with the reputation of great database software in >> yesterdays 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
В списке pgsql-bugs по дате отправления: