ingenthr

iQ allows developers to interact with the Couchbase database platform using natural language conversation, making database interactions more intuitive, efficient, and accessible. Developers can use Capella iQ within the Query Workbench in the Capella UI and within VS Code and JetBrains IDEs.

Trond Norbye and I were also pretty involved with the memcached project, both joined NorthScale and we're both still part of Couchbase. Trond in particular did a lot of work on the server and I did a lot of work with the java client and helping people.

Steve Yen was doing a lot and fixing bugs and wrote moxi, a memcached proxy that was very useful in the early days.

With the CouchOne merger, we moved a lot of the proxy topology independence into clients and added a lot more.

At least for Couchbase thus was replaced by N1QL: http://docs.couchbase.com/developer/n1ql-dp4/n1ql-intro.html

At least for Couchbase, this was replaced by N1QL

Thanks for the compliment! JChris started the Open Source page and I did some more clean up on it recently. I'd like to do more there soon.

By the way, on the source, it was never intended "dumping" style but just a bunch of stuff that had been slowly wired together. Yeah, we use repo and gerrit quite a bit. Check out review.couchbase.org sometime.

It's not so much that you need to use the memcached API. We've built a set of client libraries that give you a consistent API (check out couchbase.com/develop) though parts are done through memcached binary protocol (for speed) and parts are done through a RESTful interface inspired by CouchDB.

It wasn't about resource constraints; it that we felt going after distributed deployments and having the speed to keep up with application demands (mostly driven by CRUD) was important. That's what devs and ops people kept telling us they'd need.

It's not deliberate confusion. There was a lot of work to just getting the code out there, and we're now working on more and more docs.

Have a look at http://blog.northscale.com/northscale-blog/2010/07/what-exac... and http://dustin.github.com/2010/06/29/memcached-vbuckets.html for good technical content.

A couple of points. Some deployments do query from replicas already, but we can make this a bit better in the vbucket world. A second point is that moxi actually has functionality to non-coherently cache some items locally. Moving the cache closer to the application is always the best thing to do if you're willing to relax consistency. This is better than having it elsewhere in the cluster. The fastest network read is the one you don't actually have to do.

moxi does this with a key prefix and a timeout per item (even 1 second makes a big difference for hot data), then fetching it from the authoritative server.

We've not really exploited this moxi functionality in membase deployments yet, but it's been there in moxi for a year now and could be easily turned on if we had a deployment which needed it.

Having said all of that, with membase (as with memcached) the limit you'll hit first for an item you're fetching is network throughput. It's not that common to be fetching a few items so much that you overrun network. Even if you do, then the answer is simple: add a few more nodes.

Very cool, and very readable stuff!