[Gsoc] ZODB-related project ideas

Martijn Pieters mj at zopatista.com
Sun Mar 23 08:58:08 EDT 2008


On Wed, Mar 19, 2008 at 10:55 PM, Dirceu Pereira Tiegs
<dirceutiegs at gmail.com> wrote:
>  = Improved replication for ZODB through ZEO Raid =
>
>  The ZEO RAID storage is a proxy storage that works like a RAID
>  controller by creating a redundant array of ZEO servers. The
>  redundancy is similar to RAID level 1 except that each ZEO server
>  keeps a complete copy of the database. This proposal aims to improve
>  gocept.zeoraid, fixing bugs, testing and implementing needed features.

I'd love to see a GSOC project tackling getting ZEO Raid ready for
production! Big +1 from me here.

>  = RelStorage support to Microsoft SQLServer =
>
>  RelStorage is a storage implementation for ZODB that stores pickles in
>  a relational database. This proposal aims to provide support for
>  Microsoft SQLServer in order to take advantage of it's replication and
>  deployment infrastructure.

Again, a big +1 from me.

Additionally, looking into refactoring backend implementations loading
so that they can be distributed separately? Just add the
relstorage-oracle egg to your buildout and everything works, kind of
thing. Last but not least, add blob storage support, where ZODB blobs
are stored in the relational database too.

>  = Allow limiting the size of ClientStorage's blob cache =
>
>  Currently the ClientStorage will grow the blob cache indefinitely. We
>  should allow some control about how large the cache may grow, e.g. by
>  making the ClientStorage support minimizing the blob cache. (Idea: LRU
>  principle via mstat access time and a size-based threshold) currently).
>
>   From https://blueprints.launchpad.net/zodb/+spec/limit-clienstorage-blob-cache

This is perhaps a bit small. Maybe this can be combined with the next
proposal, making both caching policies pluggable?

>  = An alternative object caching strategy for ZODB: object
>  classification =
<snip>
> This
>  proposal aims to modify the ZODB to allow different cache
>  implementations to be used, and implement a cache that performs an
>  object classification using a configurable strategy.

Quite ambitious, I'd say! But also something that can have a great
impact on larger sites, and I'd certainly welcome making the cache
policy pluggable.

-- 
Martijn Pieters


More information about the Gsoc mailing list