On Fri, Jun 18, 2010 at 05:08:31PM -0700, I. E. Smith-Heisters wrote: > > Thanks for the clarification. > > One of the several reasons we decided on Couch was the need for fast, > somewhat complex queries against the workitems store, which we > achieved through custom views. In this scenario, the couch storage is > vastly more performative than FsStorage, which appears to have to > iterate over all the workitems--bearable at first, but scales > terribly.
Hello Ian, I completely understand. If I had to had better indexes to FsStorage, I would have to write index management code and finally end up with a... database system. > This brings a few questions to mind. Were we perhaps using FsStorage > incorrectly? Is there a performative way to query for nested field > values in FsStorage? Like you say, the slowness doesn't matter much > given that our business process is human-based, except when we're > testing. Might you have some recommendations for testing against > CouchStorage more performatively? Maybe Ruote::CompositeStorage could help you : http://ruote.rubyforge.org/configuration.html#composite_storage You could have something that looks like : ---8<--- storage = Ruote::CompositeStorage.new( Ruote::FsStorage.new('ruote_work', opts'), 'workitems' => Ruote::Couch::CouchStorage.new( '127.0.0.1', 5984, opts.merge('couch_prefix' => 'test'))) --->8--- where only the workitems are stored in couch. Only the delivery of workitems to Couch would be relatively slow, but you could still benefit from CouchDB views. Best regards, -- John Mettraux - http://jmettraux.wordpress.com -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
