| Subject | Re: [Firebird-Architect] Re: Cloud databases |
|---|---|
| Author | Roman Rokytskyy |
| Post date | 2008-07-27T13:14:34Z |
paulruizendaal wrote:
might be wrong), that they found better use for technological limitation.
There was an attempt (years 1996-1999) by Stonebraker to create database
system that would scale to thousands or tens of thousands hosts over the
WAN called Mariposa. The idea was that nodes must not be up-to-date all
the time. Instead, nodes would subscribe for update streams with
appropriate periodicity. To make system self-configurable and prevent
hosts from subscribing for the most active streams, each host would have
to pay for the stream in the appropriate currency. Also host were able
to propagate the updates that happen on them via subscribed upstreams
(AFAIK, read-write streams were more expensive). However, since nodes
should not be able to produce the currency themselves (and thus avoid
the inflation), nodes were supposed to "earn" currency from the clients
that execute queries on their nodes.
The project, AFAIK, never become more than research project sponsored by
ARPA. But maybe we just do not know - they know how to keep their
secrets. :)
Roman
P.S. When I was writing this email, I remembered another idea that was
floating in the air few years ago. It is about Leslie Lamport's PAXOS
distributed agreement algorithm. It has very nice story/fiction behind
it, but proved to be not trivial to implement. It should allow building
systems that would be able to make decisions also when some nodes are
offline without compromising the overall consistency. The idea was to
use this algorithm for distributed databases. Just made quick search in
Google for "paxos database" and found this PDF:
http://labs.google.com/papers/paxos_made_live.html - they use it in the
Chubby, another technology used by GFS and BigTable.
>> ... They call this "relaxed constraints".I'm not sure that economic reasons were the first. I believe (however,
>
> I think there are also direct economic reasons that make overbooking
> attractive, even if technology allowed otherwise.
might be wrong), that they found better use for technological limitation.
> However, you make a very valid point. Is there sufficient economicI did not mean that, but the point is valid.
> benefit in a consistent cloud database? There is a gap in the market,
> but is there a market in the gap?
There was an attempt (years 1996-1999) by Stonebraker to create database
system that would scale to thousands or tens of thousands hosts over the
WAN called Mariposa. The idea was that nodes must not be up-to-date all
the time. Instead, nodes would subscribe for update streams with
appropriate periodicity. To make system self-configurable and prevent
hosts from subscribing for the most active streams, each host would have
to pay for the stream in the appropriate currency. Also host were able
to propagate the updates that happen on them via subscribed upstreams
(AFAIK, read-write streams were more expensive). However, since nodes
should not be able to produce the currency themselves (and thus avoid
the inflation), nodes were supposed to "earn" currency from the clients
that execute queries on their nodes.
The project, AFAIK, never become more than research project sponsored by
ARPA. But maybe we just do not know - they know how to keep their
secrets. :)
Roman
P.S. When I was writing this email, I remembered another idea that was
floating in the air few years ago. It is about Leslie Lamport's PAXOS
distributed agreement algorithm. It has very nice story/fiction behind
it, but proved to be not trivial to implement. It should allow building
systems that would be able to make decisions also when some nodes are
offline without compromising the overall consistency. The idea was to
use this algorithm for distributed databases. Just made quick search in
Google for "paxos database" and found this PDF:
http://labs.google.com/papers/paxos_made_live.html - they use it in the
Chubby, another technology used by GFS and BigTable.