On Mon, 15 Jan 2001, Michael Bernstein wrote:
> as Squishdot). Adding a dependency on an RDBMS or requiring
> additional setup on the server's FS seems a step in the
> wrong direction.
> So the question remains: Will either approach (within the
> ZODB) allow me to scale the application to hundreds of
> thousands (or even millions) of objects indexed in a
> ZCatalog?
> I know that the ZCatalog/ObjectManager approach used by
> Squishdot will scale to over 9,000 objects (the number of
> postings to date at technocrat.net), So I'm reasonably
> certain that my proposed ZCatalog/BTree Folder approach will
> be at least as scalable. I'm slightly less confident about
> the Specialist/Rack approach, because I don't know of any
> sites that have used them to store that many objects in the
> ZODB, but only slightly.

My understanding is that the point of ZPatterns is to hide
the data storage implementation from the application.  You refer
to this in another post.  The point being that you can *change your
mind* later, with minimal disruption to your application.  Not
only that, but people who *use* your product can make their
own decision about where to store the data.  So by using ZPatterns
you would have a product that could be installed without
any addons other than ZPatterns itself, and yet let the users
of your product use an RDBMs if that works better for them.

In addition, it seems to me that your comments about ZCatalog+BTree
apply equally well to ZPatterns, since you can use the Catalog
to index stuff stored in a rack through the use of appropriate
triggers, and it is my understanding that the default in-ZODB
rack storage uses BTree internally.

So overall I'd think going with ZPatterns would be the right
decision.  It gives you and others using your code the
maximum flexability.

Unfortunately I don't have much input on your question about
real-life scalability...the most I've done is stored 60000 small objects
in a hierarchy of zope folders, indexed by the catalog, with
no perceptable slowdown in search or retrieval speed.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to