RE: [Zope] ZODB replication on a per-object basis?
Interbase does replication. I haven't really figured out how it will work with Zope and one will have to store Zope objects in Interbase for proper replication. It may be worth investigating. Roché Compaan
From: "Brad Clements" <bkc@murkworks.com> Organization: MurkWorks, Incorporated. To: zope@zope.org Date: Tue, 9 May 2000 17:14:24 -0500 Subject: [Zope] ZODB replication on a per-object basis? Reply-to: bkc@murkworks.com
I have a project in mind where I'd like to have 2 or more Zope installations selectively replicate other Zope server's objects (a sub-set of objects).
I've looked at the write-up for ZEO, and that doesn't really seem to fit the bill.
Imagine a master Zope site running some application, perhaps ZDiscussions, Wiki or Confera (just an example). Suppose that dial-up users want to sync their copies with the master server on a periodic basis, but not sync the entire zope site. (say, a list of folders and subfolders, and meta types).
Now suppose that these client-copies also have data to contribute, that needs to be sync'd back to the master. Disregard the issue of two clients changing the same object.. I'm thinking about general replication of a subset of objects in folders from one system to another...
The Coda file system has a disconnected mode.. If I had a Code-FS implementation, this might work except that I'd be missing meta info.
Has anyone thought about this problem?
I also need to tackle the same issue for database replication.. Replicating changed rows between systems to keep them in sync. That's another story.
Thoughts?
Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
On 11 May 2000, at 6:39, RC Compaan wrote:
Interbase does replication. I haven't really figured out how it will work with Zope and one will have to store Zope objects in Interbase for proper replication. It may be worth investigating.
I'm looking at the CODA file system as a possible solution. Writing a Storage Manager that talks directly to the Coda Venus cache process. However I need a way to "callback" into Zope to have it invalid its internal cache of objects, forcing them to be re-read from the storage manager. Any ideas where I should look for that functionality in Zope? For more Coda info, see http://www.coda.cs.cmu.edu PS. A distributed Zope system could be Python's CPAN.... Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
On Thu, May 11, 2000 at 09:03:22AM -0500, Brad Clements wrote:
However I need a way to "callback" into Zope to have it invalid its internal cache of objects, forcing them to be re-read from the storage manager.
To put it simply, ZEO :) -Petru
On 11 May 2000, at 16:22, Petru Paler wrote:
On Thu, May 11, 2000 at 09:03:22AM -0500, Brad Clements wrote:
However I need a way to "callback" into Zope to have it invalid its internal cache of objects, forcing them to be re-read from the storage manager.
To put it simply, ZEO :)
-Petru
No, I don't think so.
The pieces of ZEO discussed so far address scalability. For complete reliability, though, the data in the ZSS must be redundant. That is, the single point of failure cannot be simply shifted from the Zope process to the ZSS. The second level of the ZEO architecture eliminates the ZSS as the failure point by mirroring the object data between storage servers and allowing failover of one ZSS process to another. Scaling the Zope Storage Server will be the second phase of the ZEO work
Based on this, it appears that ZSS does not replicate at this time. Also, the fact sheet says that Zope still caches objects in memory, but doesn't mention how a replicated ZSS can invalidate the cache of a running Zope process. Invalidation is needed when another Zope process has changed an object.. That changed object needs to be pushed out to running Zope processes .. I imagine that some objects (like /index_html) are pretty much permanently cached in memory since they're hit so often. Also, folder objects that are cached won't see new child objects from other zope processes until that folder is flushed and reloaded. At least, this is what I'm assuming.. Someone correct me. -- I'm looking for wide area replication .. like how you might implement a CPAN for Python based on Zope. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
On Thu, May 11, 2000 at 09:29:31AM -0500, Brad Clements wrote:
The pieces of ZEO discussed so far address scalability. For complete reliability, though, the data in the ZSS must be redundant. That is, the single point of failure cannot be simply shifted from the Zope process to the ZSS. The second level of the ZEO architecture eliminates the ZSS as the failure point by mirroring the object data between storage servers and allowing failover of one ZSS process to another. Scaling the Zope Storage Server will be the second phase of the ZEO work
Based on this, it appears that ZSS does not replicate at this time.
You're right, but notice the "at this time". Once it will be made open source I'm pretty sure that someone will complete it.
Also, the fact sheet says that Zope still caches objects in memory, but doesn't mention how a replicated ZSS can invalidate the cache of a running Zope process.
Invalidation is needed when another Zope process has changed an object.. That changed object needs to be pushed out to running Zope processes .. I imagine that some objects (like /index_html) are pretty much permanently cached in memory since they're hit so often.
ZEO _does_ invalidation. Otherwise it would be useless.
I'm looking for wide area replication .. like how you might implement a CPAN for Python based on Zope.
You want to do this too ? :) ZEO in its current form perfectly fits the bill, because you _need_ a centralized site which the mirrors replicate. -Petru
On 11 May 2000, at 16:36, Petru Paler wrote:
On Thu, May 11, 2000 at 09:29:31AM -0500, Brad Clements wrote:
Based on this, it appears that ZSS does not replicate at this time.
You're right, but notice the "at this time". Once it will be made open source I'm pretty sure that someone will complete it.
Who is someone? Shouldn't that be us?
ZEO _does_ invalidation. Otherwise it would be useless.
I saw no mention of how CS invalidates Zope's internal cache based on asynchronous information from ZSS.
I'm looking for wide area replication .. like how you might implement a CPAN for Python based on Zope.
You want to do this too ? :) ZEO in its current form perfectly fits the bill, because you _need_ a centralized site which the mirrors replicate.
I disagree. I think the performance would be bad. CS/ZSS is just an RPC implementation of FileStorage (it seems). Therefore when Zope needs an object that is not in the in-memory cache, CS has to execute an RPC call across the Internet to the master copy -- slow.. Since the in memory cache has a limited size (I assume) and/or times out old objects (I assume), statistically you're going to get hit with this delay on the larger objects (Python packages) whenever you download. If you use a distributed file system instead, you don't have this problem. Each site can either be a replicating server.. or in the case of Coda, each remote site can enable "file hoarding" in their client to keep local copies of all objects (files) .. You definately want local copies of all the data. But these copies need to be automatically updated from "the master" (in this application there is one master, but in Coda that does *not* have to be the case). We could do a poor-man's job at this now by running both an FTP server and a Zope server pointing to those FTPable files. The FTP server can mount a distributed file system (afs, coda)... Then nightly just export the Zope database and replicate that to all the clients. But this isn't quite what I want... Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
On Thu, May 11, 2000 at 09:44:27AM -0500, Brad Clements wrote:
Based on this, it appears that ZSS does not replicate at this time.
You're right, but notice the "at this time". Once it will be made open source I'm pretty sure that someone will complete it.
Who is someone? Shouldn't that be us?
I didn't mentioned who :)
ZEO _does_ invalidation. Otherwise it would be useless.
I saw no mention of how CS invalidates Zope's internal cache based on asynchronous information from ZSS.
I am pretty sure this is done. If you are not convinced, look at the last week's CVS commits and see how special ZEO hooks are merged into Zope.
You want to do this too ? :) ZEO in its current form perfectly fits the bill, because you _need_ a centralized site which the mirrors replicate.
I disagree. I think the performance would be bad.
CS/ZSS is just an RPC implementation of FileStorage (it seems). Therefore when Zope needs an object that is not in the in-memory cache, CS has to execute an RPC call across the Internet to the master copy -- slow..
Since the in memory cache has a limited size (I assume) and/or times out old objects (I assume), statistically you're going to get hit with this delay on the larger objects (Python packages) whenever you download.
I agree with you, but the local cache is very big (disk based I think -- anyone from DC care to comment ?). ZEO is aggresively optimized for the many-read, less-write case. The only expensive operations are writes, which must cause invalidation of all the caches (though I hope it only invalidates the changed OID and not the whole cache; I haven't seen the ZEO source yet so I can't assume more).
If you use a distributed file system instead, you don't have this problem. Each site can either be a replicating server.. or in the case of Coda, each remote site can enable "file hoarding" in their client to keep local copies of all objects (files) ..
You definately want local copies of all the data. But these copies need to be automatically updated from "the master" (in this application there is one master, but in Coda that does *not* have to be the case).
We could do a poor-man's job at this now by running both an FTP server and a Zope server pointing to those FTPable files. The FTP server can mount a distributed file system (afs, coda)... Then nightly just export the Zope database and replicate that to all the clients.
But this isn't quite what I want...
Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
-Petru
participants (3)
-
Brad Clements -
Petru Paler -
RC Compaan