On 28 August 2012 06:34, Iain Duncan <[email protected]> wrote: > I expect this project will be doing a *lot* of writes. IE, maybe even all > hits do some minor mutation. On the other hand, I have a hunch that the > architecture could wind up being really clean in zodb as it's going to be a > lot of object modelling (some non-realtime simulation related stuff) And I > think transactions will be important, it will be all screwed up if there's > any kind integrity jiggery pokery in the object model.
The ZODB is not optimized for this use-case. There's a couple of reasons for this: 1. You'll get B-tree conflicts that can't be resolved on the server. 2. You'll need to load non-current object data too frequently, which is expensive. 3. There's a global commit lock (primarily to establish order) which incurs some latency. You'll probable fare better with PostgreSQL because it's got knobs you can tune and native support for concurrent B-trees. \malthe -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
