Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Morten W. Petersen
Hedley Roos skrev: > I've followed this thread with interest since I have a Zope site with > tens of millions of entries in BTrees. It scales well, but it requires > many tricks to make it work. > > Roche Compaan wrote these great pieces on ZODB, Data.fs size and > scalability at > http://www.upfr

Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Peter Bengtsson
For huge inserts like that, have you looked at the more modern alternatives such as Tokyo Cabinet or MongoDB? I heard about an experiment to transfer 20 million text blobs into a Tokyo Cabinet. The first 10 million inserts were superfast but after that it started to take up to a second to insert ea

Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Lennart Regebro
On Mon, Apr 27, 2009 at 17:57, Morten W. Petersen wrote: > OK.  Well, I'm concerned about how much a database would grow.  I'm thinking > if > I use one BTree for all the entries, would the database grow just a little > or a lot when > you start getting into the millions of entries when inserting

Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Hedley Roos
I've followed this thread with interest since I have a Zope site with tens of millions of entries in BTrees. It scales well, but it requires many tricks to make it work. Roche Compaan wrote these great pieces on ZODB, Data.fs size and scalability at http://www.upfrontsystems.co.za/Members/roche/w

Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Morten W. Petersen
Peter Bengtsson skrev: > From experience I find that BTrees are very fast to write to and pick > out items from. Even in the millions. (Never gone into the tens of > millions or further) > Also, when it comes to browsing stuff I find SQL faster and easier to > work with. An added advantage of a RDB

Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Morten W. Petersen
Lennart Regebro skrev: > On Sat, Apr 25, 2009 at 13:24, Morten W. Petersen > wrote: > >> So far, I've been contemplating disabling undo (if that's possible), >> > > I doubt that it would make a difference. The Undo functionality comes > out of the database being logging, and changing that

Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Morten W. Petersen
> I suggest you experiment a bit. Create 100 million objects, and do > some of the actions you are planning to do on them. > Right. I'm thinking of taking the time to try a simple SQL based implementation, as well as one in ZODB. I need to learn more about high-speed Zope programming as we

Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-27 Thread Peter Bengtsson
>From experience I find that BTrees are very fast to write to and pick out items from. Even in the millions. (Never gone into the tens of millions or further) Also, when it comes to browsing stuff I find SQL faster and easier to work with. An added advantage of a RDBMS is that you get the indexing

Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-26 Thread Lennart Regebro
On Sat, Apr 25, 2009 at 13:24, Morten W. Petersen wrote: > So far, I've been contemplating disabling undo (if that's possible), I doubt that it would make a difference. The Undo functionality comes out of the database being logging, and changing that would mean pretty much a complete rewrite. >

Re: [Zope] Building a fast, scalable yet small Zope application

2009-04-25 Thread Andreas Jung
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 25.04.2009 um 13:24 schrieb Morten W. Petersen: > Hi, > > I'm considering building a large scale, but small in features site. > It > will contain > lots of small objects (millions, tens of millions, hundreds of > millions) > of objects, > whe

[Zope] Building a fast, scalable yet small Zope application

2009-04-25 Thread Morten W. Petersen
Hi, I'm considering building a large scale, but small in features site. It will contain lots of small objects (millions, tens of millions, hundreds of millions) of objects, where each object has a couple of strings and maybe some other light attributes. So far, I've been contemplating disabli