Re: Distributed OODBMS
- From: Udo Schneider <Udo.Schneider@xxxxxxxxxxxxxx>
- Date: Wed, 31 May 2006 15:05:05 +0200
Chris Uppal wrote:
That's a /nasty/ set of requirements !Nobody said life would be easy :-)
Just a thought, but could you use some sort of broadcast protocol ? I'mI didn't really think about broadcasts yet .... maybe may notion of broadcast ist too much network oriented - thus limited to one segment. However (UDP-) multicast might be a good idea. However this would require reliable working UDP Sockets, non-unicast IP Address support in Dolphin and I would have to add a kind of stream layer (basically imitating TCP) above that .... sound like a lot of work ... but I think /any/ solution I have to choose will be "a lot of work".
imagining a scenario where every client has a more-or-less complete copy of the
database. When a client wants to ensure that it is working with the most
up-to-date version of <some data> or when it finds that it doesn't have the
data at all, then it sends a request to the server. The server /broadcasts/
its response, and all the clients listen for those broadcasts. When they see a
new version of <some data> on the wire they update their own copy whether they
need it (at that minute) or not. If something goes wrong so that they don't
get a complete copy from the broadcast, then they just don't update their local
copy (except, perhaps, to mark it "stale"). The server might also have some
sort of "push" broadcast of changes as they are made (or as a background task
to consume idle bandwidth), so that clients don't often have to check back with
the server to see whether their cached copy of <some data> is still current.
I recently came up with the idea of combining the rsync alghorithm with ditribution over bittorrent. I have both things in place (but don't ask for code quality :-) in Smalltalk. So the idea would be that the check which part of the file(s) needs to be updated will be done like rsync whereas the real distribution takes place using bittorent (reducing the bandwidth requirements for the master). But I think that's a) pretty heavy in terms of implementation, b) not very "Smalltalkish" and c) only deals with files which brings us to ...
How you layer that over, or under, an OODB is another problem ;-).... the question how to go from files to OODBs. I don't think that e.g. OmniBase would like to have it's file updated independently (if even possible of file locks are in place).
Another possibility -- if (some of) the clients are nearer in network terms toThat's what I thought as well in regards to BT.
each other than they are to the server, it /might/ be worth thinking about
P2P-style distribution of the data.
A last thought. Have you looked at the "Prevalence" concept / design-pattern ?Yes. I did. As far as I understood the concept it would be enough to distribute the serialized objects once (or perodically) and then only distribute the transaction log to the clients. I might have to look into that. However this as well would be a complete rewrite from scratch. But I think based on the answers I got it will be a complete rewrite anyway regardingless which way I'll choose :-(
If not then that might give you some ideas. See www.prevayler.org for a
description, and a Java implementation (which you would ignore, of course ;-)
You'd be using -- say -- Omnibase, instead of keeping everything in RAM, but
the basic idea seems as if it might be applicable, especially the Prevalence
approach to propagating changes.
Thanks for your help.
CU,
Udo
.
- Follow-Ups:
- Re: Distributed OODBMS
- From: Chris Uppal
- Re: Distributed OODBMS
- References:
- Re: Distributed OODBMS
- From: James Foster
- Re: Distributed OODBMS
- From: Eric Taylor
- Re: Distributed OODBMS
- From: Udo Schneider
- Re: Distributed OODBMS
- From: James Foster
- Re: Distributed OODBMS
- From: Udo Schneider
- Re: Distributed OODBMS
- From: Chris Uppal
- Re: Distributed OODBMS
- Prev by Date: Re: Distributed OODBMS
- Next by Date: Re: Distributed OODBMS
- Previous by thread: Re: Distributed OODBMS
- Next by thread: Re: Distributed OODBMS
- Index(es):
Relevant Pages
|