Membase and CouchOne merged to form Couchbase
Membase, the company whose product is Membase and whose former company name is Northscale, has merged with CouchOne, the company whose product is CouchDB and whose former name is Couch.io. The result (product and company) will be called Couchbase. CouchDB inventor Damien Katz will join the Membase (now Couchbase) management team as CTO. Couchbase can reasonably be regarded as a document-oriented NoSQL DBMS, a product category I not coincidentally posted about yesterday.
In essence, Couchbase will be CouchDB with scale-out. Alternatively, Couchbase will be Membase with a richer programming interface. The Couchbase sweet spot is likely to be:
- Internet applications, especially ones that involve connectivity between a host and mobile devices.
- Delivery of data, content, and/or software across a network. (That’s a high-profile CouchDB use case today.)
- (Possibly) transactions for virtual goods that have no scarcity. (Once there’s actual inventory involved, the traditional relational database model starts looking pretty appealing.)
And now let’s go to the lists of bullet points.
Background to the Membase/CouchDB/Couchbase integration story:
- Membase is a key-value store with the memcached interface. Its strengths are memcached compatibility and performant scale-out. What it stores are in essence JSON documents.
- CouchDB is designed for ease of programming, and for built-in handling of occasionally-connected replication. (Not coincidentally, Damien Katz used to work on Lotus Notes.) CouchDB indexes individual data fields for reasonable query capability, although joins are problematic. What CouchDB stores are in essence JSON documents.
Highlights of how Membase works and is deployed today:
- Your API is Get/Set, just like in memcached.
- To a first approximation, Membase just persists memcached cache at every node. That said, it can certainly store more data per node than fits in cache.
- Most Membase installations are in Amazon EC2, where flash memory is not available. Most in-house Membase installations, however, use flash.
Business background on Couchbase predecessors:
- Membase raised $15 million, had 20 employees, and has a number of paying customers.
- CouchOne raised $2 million, had 16 employees, hadn’t focused much on traditional customer acquisition yet or on building an enterprise edition of the product, and had about 4 customers anyway …
- … except that CouchOne’s plans included CouchDB hosting, and there are around 4500 users of same in a free beta that’s on the verge of going non-free. Damien positions his hosting as being focused on high throughput and concurrency, while rival CouchDB host Cloudant is in his opinion more focused on big data.
- The apparent repositioning of CouchOne as being highly focused on mobile applications (with unreliable host connections) never really had time to take hold. Indeed …
- … Damien asserts that CouchDB has a lot more mission-critical enterprise deployments than MongoDB, whereas he concedes that MongoDB is doing great in a Ruby-centric market.
Happy talk around Membase/CouchDB/Couchbase product integration:
- Hey, both Membase and CouchDB talk JSON.
- Product strengths and weaknesses are synergistic. For example:
- Membase started with caching technology (memcached). CouchDB doesn’t yet make much use of cache.
- Membase’s back end is SQLite, used in a “dumb” way. CouchDB can presumably do everything the dumb implementation of SQLite can.
- Membase’s scale-out is designed for a single data center, with strict consistency. CouchDB’s is designed for wide-area networks, with eventual consistency. At least one big internet company likes the idea of strict consistency within data centers, but eventual consistency among them.
- The CouchDB interface takes the place of something Membase planned to build called Node Code, which was going to overcome the limitations of a simple key-value interface. Node Code development didn’t ever really get started, and indeed was deferred for a couple of months while CouchOne acquisition discussions were underway. However, Membase did build Node Code’s underpinnings, called the “TAP” interface.
- And on the operations side: Membase has been in Mountain View, right by the CalTrain. CouchOne has been in Oakland, but with a lot of at-home workers. One option is to move the Oakland office to a San Francisco location that, you guessed it, is also right by the CalTrain.
Other technical notes:
- The only current API to CouchDB is http/https. memcached protocols will be added to Couchbase.
- CouchDB has design documents. These are used to tell you how to do indexes. They’re built on the fly if they don’t already exist. Then there are Javascript functions that update the indexes as documents are added/updated.
- In particular, CouchDB has a geospatial index, in a true R-tree. Damien fondly thinks it already has most albeit not all the features of PostgreSQL GIS. I gather CouchDB geospatial will be straightforwardly integrated into Couchbase.
- There’s also a CouchDB add-on project for full-text indexing. Damien seems less confident of how that will be integrated into Couchbase.
Finally, I’m curious about the relative performance of Couchbase/Membase and Schooner Membrain when using flash memory. I would guess that the comparison favors Schooner, because of Schooner’s extensive focus on flash optimization. I would also guess that Schooner’s edge is small, because I’d think it would be less than Schooner’s advantage vs. alternative Flash uses on the MySQL side, and Schooner’s MySQL performance advantage seems to be less than 2X even when Schooner is doing the benchmarks.
Comments
2 Responses to “Membase and CouchOne merged to form Couchbase”
Leave a Reply
[…] the NoSQL Consolidation Wars begin: Membase and CouchOne merged to form Couchbase. In essence, Couchbase will be CouchDB with scale-out. Alternatively, Couchbase will be Membase […]
You ask a question about the performance of Membase versus Schooner Membrain when using flash memory. Schooner is faster as you suggest, but I think that the more interesting comparison is what happens with a data set that does not fit into the server’s DRAM? Schooner’s premise is that by cleverly exploiting, say, 1 TB of flash memory on a system with 64 GB of DRAM, you can avoid sharding and get very high performance from the full complement of flash. We have some benchmarks at http://www.schoonerinfotech.com/products/schooner_membrain showing Membase and Membrain.