[Zope-dev] how bad are per-request-write-transactions (fwd)

[Romain Slootmaekers]

On Wed, 17 Apr 2002, 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).
> 
> 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.
> 
> 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.
> 
> Finally, you store all your counters in a non-versioned storage.  Now 
> you have *no* bloat problem. :^)
> 
> Regarding performance, maybe his application isn't doing 50 
> requests/second and he'd be willing to trade the slight performance hit 
> and bloat for a decrease in system complexity.
> 
> All of the above has downsides as well.  My point, though, is that we 
> shouldn't automatically dismiss the zodb as inappropriate for *all* 
> high-write situations.  In fact, with Andreas and Matt Hamilton's 
> TextIndexNG, you might even be able to write to catalogued applications 
> at a faster rate than one document per minute. :^)
> 

for one web application, we use the ZODB as primary storage mechanism, 
and apart from the need for frequent packing, we are quite happy.
we did however have to modify the conflict resolution protocol for our
objects. 

We now have the luxury of not having to store your objects in base64
encoded sql blobs ;)

As far as performance is goes... performance is never an issue until it
becomes one. 99% of the time, I don't care. the 1 other % was solved
within a day.


Sloot.