Couchbase Data Sources for XPages

  • Jun 16, 2013

The other day, I attended a Couchbase Developer Day in Philly. If you're not familiar with Couchbase, it's one of the young crop of NoSQL databases, and more specifically a document database and a conceptual cousin to Domino by way of Damien Katz. It's this similarity that makes it so interesting to me - Couchbase's still-living predecessor CouchDB started life as Notes built from the ground up for the web and the heritage is clear. Couchbase itself ends up being like if you melted down the cores of NSF/NIF and poured the result on top of a speedy key-value store.

That all makes Couchbase a perfect candidate for some XPage tinkering. Ignoring the foundational key-value aspects of Couchbase, the JSON document storage and views in 2.0 make for perfect analogues to the Domino data sources in XPages. To wit:

<xp:this.data>
    <cb:couchbaseView var="beersView" connectionName="couchbasePelias"
        designDoc="beer" viewName="by_name" />
    <cb:couchbaseDocument var="beer" connectionName="couchbasePelias"
        documentId="${param.documentId}"/>
</xp:this.data>

I've set up a demo app on one of my test servers (don't be surprised if that link is periodically unavailable). It demonstrates one of the views in the beer sample database that comes with Couchbase (it's like fakenames.nsf, but more intoxicating), with each row providing a link to edit the document in the DB, though editing is disabled for Anonymous users. The app also contains pages to show the applicable Java classes and support elements. The sources are nowhere near complete works - the view source lacks any knowledge of keys, grouping, etc., while the document source doesn't allow for the creation of new documents, nor is there any representation of non-document values.

Pretty much every concept you work with in Couchbase has a corresponding concept in Domino, but with a bit of slant, like a different dialect (for example, they call it a Royale with Cheese). A table may suit this explanation best:

 

Domino Couchbase Notes
Server Node + Cluster Couchbase has a strong focus on splitting up the job of housing databases into many servers for reliability and scalability reasons. Where Domino's clustering is RAID 1, Couchbase's is more like RAID 5.
Replication XDCR Unlike Domino's replication, Couchbase uses a set of rules to determine which of two conflicting documents lives and which dies unceremoniously.
Database Bucket The Couchbase name is a bit more evocative.
View Design Doc + View Unlike Domino1, Couchbase stores multiple views per design document, and it appears to be a sort of arbitrary art to decide how you want to split your views up among multiple design documents.

 

I'm tempted to find an excuse to build something using Couchbase as a back-end, just to see how its performance stacks up. It seems like my years of built-up NSF habits would serve me well, as many of the programming models and tradeoffs are similar, except that Couchbase views are probably consistently fast without having to cheat.

If I come back to the data sources, I'll probably flesh them out to support creating new documents, properly handle dynamically-computed properties, provide some control over view parameters (maybe including the geoboxing stuff built in), support Couchbase's document-save-conflict detection, and add a data source for basic key/value pairs. And if I do, that could provide a good excuse for me to package them up as a proper OSGi plugin, which I've so far avoided bothering with. We shall see.

1. This is a lie. The Couchbase way is actually very similar to Domino: Domino view design notes contain one or more collations, which correspond to the main index and any click-to-sort column directions. However, each of Couchbase's views inside its design document can produce wildly different data, not just resorts of the same selection, and so the fact that they're similar technically isn't very useful.

5 Comments
Jun 18, 2013
Tim Tripcony

"Royale with Cheese..."

"I know, baby, you dig it the most."

I'm busy as hell at the moment, but if you put this stuff up on Github, don't be surprised to get some pull requests from me eventually. Wink

Jun 18, 2013
Keith Strickland

Good read.... I totally enjoy messing with alternative databases and building datasources to them. We've been messing with Graph Databases of late and they meet pretty much the same model of key/value pairs with the exception between a document db being relationships between those key/value pairs. 

But ditto on Tim's comment that if you put it on Github don't be surprised if I pitch in also.

Jun 18, 2013
Damien Katz

Glad to hear from a Notes/Domino guy! XPages is some cool technology, nice to hear someone doing some work with it and Couchbase.

Let me know if you have any questions or feedback to make the product better!

Aug 2, 2013
James Brush

Has anyone cobbled together some mechanism using IBM Enterprise Integrator and/or other tools to support simple data transfer between a Domino NSF database and a Couchbase server?  How about between MS SQL 2008 running on a Windows server and Couchbase running on a Linux server?

Aug 2, 2013
Jesse Gallagher

I have not, though a Domino -> Couchbase transfer would be pretty straightforward up to a point. I can think of a couple sticking points: DateTimes (you'd have to roll your own type, or find an appropriate Java library to cover the edge cases), rich text (if you do it from an XSP environment, you could do the RT->HTML conversion without calling down to C), and large attachments. I believe Couchbase is limited to 10MB per document, so it's not suitable as an attachment store - you'd have to figure out a different way to handle that.

Still, in a normal case, it'd be very easy - just use the UNID of the Domino doc as the key for Couchbase and it'd be a simple map copy (especially with the OpenNTF Domino API).

Post New Comment