Adventures into CouchDB and Rails

September 4, 2009

Getting ready for CouchDB 0.10

Filed under: CouchDB — zdzolton @ 2:59 am

I’ve setup a local copy of CouchDB, from the 0.10 branch, just to see if my application code could handle its awesome powers. Here are my two big takeaways:

Turn on delayed commits

CouchDB 0.10 now defaults to disabling delayed commits, which in your production environment is a great trade of data consistency for write speed. However ensuring all those bits get flushed out to disk can be quite slow. For example, before turning on delayed commits my slowest unit test took over 12 seconds (ouch!), but after it got down to 3.4 seconds. Moreover, the whole test suite went from over 400 seconds (eek!) down to 90 seconds, after turning that option on.

So make sure to put this into your local.ini for your workstations:

[couchdb]
delayed_commits = true

Review your usage of reduce=false

In CouchDB 0.9 one could always specify reduce=false in view queries—even for views that don’t actually define a reduce function. This will now be considered an invalid query, and CouchDB will respond a 400 HTTP status code. I’m not sure I think it necessary to be so strict here, but all you do is review your database queries to make sure you’re passing reduce=false in erroneously.

I think we’re ready!

Other than this, it took very little to prepare my application for CouchDB 0.10—and I’m pretty excited for the _changes API and no downtime deployment of views!

Advertisements

May 4, 2009

Quick Tip: CouchDB with Lucene Search

Filed under: CouchDB — Tags: , , , — zdzolton @ 4:13 pm

So, I’m still loving Bob Newson’s CouchDB-Lucene external integration.

Here’s a quick way to monkey-patch on a search method:

CouchRest::Database.class_eval do 
  def search query, options={} 
    CouchRest.get "#{@uri}/_fti?#{options.merge(:q => query).to_query}" 
  end 
end 

When Upgrading CouchDB at Some Point…

Filed under: CouchDB — Tags: , , — zdzolton @ 3:15 pm

Versioning with Mac Ports can kinda suck, and new CouchDB versions are often incompatible with the old version’s data files.

Idea: Use CouchDBX, during incompatible upgrades, as a holding pen for your local data!

  1. Download CouchDBX
  2. Replicate from your Mac Ports-installed databases to
  3. Delete “old” databases from your Mac Ports-installed CouchDB
  4. Upgrade your Mac Ports-installed CouchDB to some new, binary-incompatible version
  5. Re-create the databases in the newly-upgraded CouchDB installation
  6. Replicate from your CouchDBX databases to the Mac Ports-installed CouchDB
  7. Enjoy! Or, Profit! (You choose…)

See?! That was so bad, was it?

May 1, 2009

Computational Evangelism

Filed under: CouchDB — zdzolton @ 4:17 pm

Using CouchDB, or any relatively new open source software, requires much work and dedication.
Here I present my list of my favorite reasons to use CouchDB:

It’s Made of the Web

  • All database operations are through REST verbs—a browser or CURL are all you need to get started!
  • Etags mean documents and views are ready for caching
  • JSON representation of all data means no-brainer mapping to programming language constructs
  • JavaScript for all scripting duties means no context swaps

Map-Reduce Indexing

  • Map-reduce functions are side-effect free, and easy to reason about using imperative OR functional techniques
  • View indexes execute explicitly, whereas SQL gurus use voodoo to change queries, hoping that the query planner decides to use the correct index
  • Functional JavaScript programming techniques can succinctly express map-reduce logic
  • It’s the algorithm that powers Google!

The Meek Shall Inherit the Earth(‘s Data)

  • Schema-less database removes impediments to change
  • Flat key-value storage is easy to reason about
  • UUIDs, instead of sequence IDs, means any two databases can replicate documents
  • Seriously easy replication: Push/Pull == POST/GET
  • AJAX-only CouchApps + Easy replication == open source apps + viral databases

Of course, swapping your SQL brain out, for a Map-Reduce one, takes a bit of time. In my opinion, however, CouchDB’s feature set, maps better to the requirements for many up-and-coming websites.

March 13, 2009

Behavioral Patterns

Filed under: CouchDB — Tags: , , — zdzolton @ 12:11 am

I’ve just read Sebastian Bergmann’s explanation of Objection-Relational Behavioral patterns, where he questions whether they are still useful for CouchDB. Hmm… Maybe I’m not getting something, but I feel these Object-Relational patterns are still a good match for CouchDB.

In particular, Unit of Work would be a great candidate, since the CouchDB doesn’t provide any transactional guarantees, not to mention that a CouchDB application is responsible for dealing with conflicts using domain-specific logic.

Lazy-loading “has_many” child objects seems to me necessary for performance, given that retrieving an entire object graph often takes more than one query for CouchDB anyways. I’d like to see CouchSurfer take it’s cue from how DataMapper does it.

Finally, implementing an Identity Map should be dead-simple given CouchDB’s flat ID space, with minor complexity of keeping the document GETs, by ID or from a view query, in sync. Moreover, I think it could probably be done at the level of CouchRest, so that all persistence libraries built atop it (and yes, there are already many) can reap the benefits.

I think the real problem will be getting people to stop using the word “Relational” —since we’re not talking about RDBMS’s here!

Create a free website or blog at WordPress.com.