[Zope-dev] Re: Alternative Storages: (was RelationalStorage (was LocalFS))

Jason Spisak 444@hiretechs.com
Wed, 03 May 2000 23:16:50 GMT


Jimmie:

> This was on the Zope list and I've move this to Zope-dev as I feel it is
> more appropriate.

I agree.

> 
> I have been making notes to myself for awhile with ideas about things I
> would like to explore with Zope Storages when I am able. I have not
> posted any of them since talk is cheap.

That never stopped me.

> 
> I'll also post this to the ZODB zwiki after I see what's left standing
> after analysis. :)
> 
> As far as usage is concerned I generally like the ZODB best because it
> is reasonably transparent to the building of a web app with Zope.

I agree.

> However there are areas in which it does not currently excel that which
> if your site requires these skills then alternatives must be used. A
> couple of areas are data size and heavy writes.

Yes.

> 
> Some people use an RDBMS to solve these issues. While this will work it
> does expect more from the developer. Some do not have the skills or the
> tools. Even if one does it still requires leaving the transparency of
> developing with the ZODB.
> 

Which works for those with RDBMS experience or existing installations, but
not for others.

> Multiple file storage for the ZODB has been proposed as a solution and
> there are 2 proposals currently on the ZODB ZWiki. I will add another.
> 
> Class/Object based db files.

Maybe we are talking about the same thing here.  Are you talking a db (like
Berkeley) implementation of the MultipleFileStorage?

> 
> Each class gets it's own db file. This could be similar to the current
> ZODB file except specific to a class. As objects are created they are
> appended to the db file for their class. This could be somewhat
> analogous to tables in an RDBMS.
> 
> Advantages would be spreading out the data space over multiple files
> which would help with some oses. Also I think that each class has
> different characteristics which would be able to be managed better if
> separate.
> 

<snip Examples>

> This could be implemented with some support classes which have to be
> inherited from to create a class.db file. Any class not so doing would
> go into the standard ZODB.

I think this is a terrific way to integrate it.

> This could help provide desired management
> features for the characteristics of each. It would be nice if in the
> management you could set the path to the file. 

I am wondering about keeping it OS/single file-system non-specific.  Will
this kind of thing work for the Global File System and /or distributed file
systems?  Probably.

>This would allow for
> multiple disks or partitions for data storage. This too would help with
> backups and such.
> 
> Just a few ideas. 

A few good ones.

All my best,

Jason Spisak
CIO
HireTechs.com
6151 West Century Boulevard
Suite 900
Los Angeles, CA 90045
P. 310.665.3444
F. 310.665.3544

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.