On Wed, Apr 17, 2002 at 07:54:04AM -0400, Paul Everitt wrote:
I don't agree that high write is always forbidden. I think there are plenty of cases where this can work. It simply becomes unworkable much sooner than other data systems (e.g. a relational database or FS-based solution).
First of all, what the product does is, besides accounting the number of objects and their total size, measure traffic / number of hits. This way, zopehosters (like us) can measure the traffic generated by customers and optionally block further traffic.
For instance, think about bloat for a second. Let's be crazy and say it takes 100 bytes to store an integer representing a count. Let's say you write once a second. That's under 7Mb a day (per counter). Combined with hourly packing, that might be well within limits.
I'd still rather avoid such numbers
Let's take the next step and say that you can live with a little volatility in the data. You write an object that caches ten seconds worth of writes. Whenever a write comes in at the over-ten-second mark, you write the _v_ attribute to the persistent attribute. There's an order of magnitude improvement.
This sounds like a good solution. Actually, I only have to write to the persited attribute if the object is persisted itself (i.e. in setstate), until then, I'll just add the self._counter and self._v_counter, right?
Finally, you store all your counters in a non-versioned storage. Now you have *no* bloat problem. :^)
How would this work? (Wouldn't this be a solution for some of the HelpSystem issues as well?) Cheers, Ivo -- Drs. I.R. van der Wijk -=- Brouwersgracht 132 Amaze Internet Services V.O.F. 1013 HA Amsterdam, NL -=- Tel: +31-20-4688336 Linux/Web/Zope/SQL/MMBase Fax: +31-20-4688337 Network Solutions Web: http://www.amaze.nl/ Consultancy Email: ivo@amaze.nl -=-