{"id":84,"date":"2007-12-22T03:30:37","date_gmt":"2007-12-22T08:30:37","guid":{"rendered":"http:\/\/www.visophyte.org\/blog\/2007\/12\/22\/adding-stews-hackish-destructive-accumulationreduction-to-couchdb\/"},"modified":"2009-04-01T08:28:24","modified_gmt":"2009-04-01T13:28:24","slug":"adding-stews-hackish-destructive-accumulationreduction-to-couchdb","status":"publish","type":"post","link":"https:\/\/www.visophyte.org\/blog\/2007\/12\/22\/adding-stews-hackish-destructive-accumulationreduction-to-couchdb\/","title":{"rendered":"Adding stews (hackish destructive accumulation\/reduction) to CouchDB"},"content":{"rendered":"

As all misguidedly-lazy programmers are wont to do, I decided that it would be easier to ‘enhance’ CouchDB<\/a> to meet my needs rather than to rewrite visotank to use SQLAlchemy. Also, I wanted to understand what CouchDB was doing under the hood with views and try my hand at some Erlang.<\/p>\n

\"This<\/p>\n

CouchDB as currently implemented maintains a lot of information for each mapped document. There is a B-tree associated with each View Group whose keys are Document Ids and whose Values are a list of {View Id, Actual-Key-You-Mapped-In-That-View} tuples for every key mapped from that document for every view in the view group. Next, each View has a B-tree associated with it whose keys are {Actual-Key-You-Mapped, Document Id} tuples and whose values are the Actual-Value-You-Mapped.<\/p>\n

This is all well and good, but is a poor fit for one of my key use-cases: reducing e-mail message traffic to date-binned summary statistics so I can render graphics. If I want the weekly-messages-sent count for a given ‘author’, map(message.author, blah)<\/em> will allow me to filter only to messages sent by that author, but no matter what blah<\/em> is, I will still get one per message.<\/p>\n

Long blog post short, I have implemented a hackish first-pass reduce\/accumulate solution to my problem. The idea is that ‘stews’ allow you to aggregate mapped data that shares the same key. I’m a little fuzzy on exactly what the definition of ‘reduce’ is in the map\/reduce papers (it’s been a while, if ever), so we’ll call this ‘accumulate’ (in the SICP\/Scheme sense). It is a hack because:<\/p>\n