[ZODB-Dev] High Write Applications

[Shane Hathaway]

Phillip J. Eby wrote:
> Certainly, logging only modifications would allow BTree pages to be 
> bigger, while reducing write transaction size.  Note, however, that it's 
> not very compatible with ZEO, as I understand it.  ZEO deals with raw 
> uninterpreted pickles, not objects.  So, when loading an object, it 
> would be necessary to "replay" the diffs since the last snapshot.  This 
> is a pretty significant change to everything from protocols, to the 
> objects that need to understand how to make and apply diffs.
> 
> The reason this approach works so well in prevalence is that command 
> objects are high-level business objects - think of them as individual 
> web REQUEST instances, pared down to just the data needed to execute 
> that transaction.  The actual changes to the database (including 
> indexes) are likely to be much greater than the amount of data supplied 
> in the request.  So, the more you drill this down to individual object 
> modifications, the less benefit you receive compared to logging the 
> top-level command.  But, the transformation of the command into the 
> modifications is a function of the objects' code, so this can't be 
> shoved into a "dumb" storage back-end.  RDBMSes also tend to have 
> smaller logs, because their data structures are simpler, more regular, 
> and carry less internal metadata.

Right.  I'm suggesting we make the back-end smarter.  ZCatalogs are the 
best candidate for this.  When you call catalog_object() or 
uncatalog_object(), the client would create a command object, add it to 
the transaction queue, and execute that command locally without sending 
change events to the transaction.  Upon commit, the ZEO server would 
receive that command object, execute (replay) it, and store object 
states that are potentially different from what the client saw.

This would benefit operations that touch many objects.  Hot spots could 
be moved into the storage server.

The main risk is that the ZEO server, now smarter, also has a much 
greater chance of crashing or stalling on user code.  (The 
application-level conflict resolution feature introduced that risk to a 
lesser degree.)  I wonder if we'd have to split the storage server into 
two processes, one of which we can feel free to restart on a whim.

Shane