Hi, Probably a dumb question: I know ZODB stores everything in an Object table. So, this table probably has a fixed length primary key. To maintain this, let us say there should be a counter which tracks the number of records in the table. The question is, is there any limit to this? Like Zope can hold 1million objects? Again, if that's the case and if packing does not re-assign the object id's, this 1million is superfluous because the OID for deleted objects are not reclaimed. I'm an RDBMS guy - hence this doubt. Example: Add an object A - its internal zope id is 1234 Add another object B - its internal id is 1235 Add C - internally it is 1236 Delete B. Pack it. Does it look like A - internal 1234 C - internal 1235 I know, crazy question. But we have a site which has objects added and deleted and packed at a fairly regular rate (users - lot of non-technical ones - are very much used to deleting things and adding new/fixed stuff, instead of trying to fix things to wrong ones!). I'm getting some concerns about this size now. Thanks V.Satheesh Babu Web Technologies Group, (703)-841-5348 sbabu@tnc.org The Nature Conservancy http://www.tnc.org http://vsbabu.csoft.net/ "The man who smiles when things go wrong has thought of someone to blame it on." --- Jone's Law
sbabu@tnc.org wrote:
Probably a dumb question: I know ZODB stores everything in an Object table. So, this table probably has a fixed length primary key. To maintain this, let us say there should be a counter which tracks the number of records in the table.
The question is, is there any limit to this? Like Zope can hold 1million objects?
First, the theoretical limitations: Currently an OID for FileStorage is 64 bits. You might have a problem if you could create 1 billion objects per second continuously over 544 years. But FileStorage is not the only way to store objects. Using existing alternate storage implementations, you can use Oracle or even create one file per object. Now the practical limitations: some operating systems, like Linux 2.2.x, are limited to 2 GB files. FileStorage has run into this. But the Linux kernel version 2.4.x has lifted this limitation. But it probably isn't wise to rely on FileStorage for many GB of data. You'd want to use OracleStorage or the developing BerkeleyStorage. Shane
On Thu, 15 Feb 2001, Shane Hathaway wrote:
First, the theoretical limitations: Currently an OID for FileStorage is 64 bits. You might have a problem if you could create 1 billion objects per second continuously over 544 years.
Damn, this means that ZODB can't handle that cataloging-every-molecule-in-the-universe project I've been thinking about. Gonna have to go with Oracle. -Michel
sbabu@tnc.org wrote:
Hi,
Probably a dumb question: I know ZODB stores everything in an Object table. So, this table probably has a fixed length primary key. To maintain this, let us say there should be a counter which tracks the number of records in the table.
The question is, is there any limit to this? Like Zope can hold 1million objects?
Zope's OID uses 64-bit integers; by my calculations, that would cause a really high-write site to run out of OIDs sometime after the heat-death of the universe :) Tres. -- =============================================================== Tres Seaver tseaver@digicool.com Digital Creations "Zope Dealers" http://www.zope.org
participants (4)
-
Michel Pelletier -
sbabu＠tnc.org -
Shane Hathaway -
Tres Seaver