NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



couchdb: All content tagged as couchdb in NoSQL databases and polyglot persistence

Using GeoCouch for Serving-Up GeoJSON

Todd Jackson:

It took around 30 minutes for my 2.5 million records to load, which isn’t too bad considering it took about 20 minutes in PostGIS.  My PostGIS table is approximately 950MB in size, while my CouchBase database, with just the data is 3.7GB, so there is a fairly large difference there. […] While the size/time to create spatial indexes in CouchDB is much larger/longer than PostGIS, I think it is a platform that will improve over time.

CouchDB has other benefits such as the distributed architecture that allows it to scale out, as well as Couchbase having a mobile solution as well, which when combined with the master-master replication scheme could enable some compelling mobile solutions.

For this use case another advantage is that both data and the code (server and client side) are all JavaScript. No impedance mismatch.

Original title and link: Using GeoCouch for Serving-Up GeoJSON (NoSQL database©myNoSQL)


CouchDB Saga: Cloudant and Couchbase

The CouchDB saga continues. Klint Finley, reporting now for ServicesAngle, tells the different perspectives that Couchbase (the company resulted from the merger of Membase and CouchOne) and Cloudant (makers of scalable BigCouch based on CouchDB) have about CouchDB.


“We’re not the CouchDB company, we will never be the CouchDB company,” James Phillips, senior vice president of products at Couchbase, told me in an interview. Phillips explained that Couchbase is integrating replication and mobile technology from CouchDB into Membase Server (now known as Couchbase Server) but the company has no business interest in CouchDB (though some of its employees are still committed to the project).


Cloudant CEO Alan Hoffman who told me that Cloudant is still committed to the Apache CouchDB project. “If you look at the commits, I think you’ll see that our employees are doing a lot of the heavy lifting,” […] Hoffman said that he believes the project is in good shape. “The passion is through the roof. We’re firmly behind the community,” he said.

One thing I can tell from where I stand: both are wrong.

Original title and link: CouchDB Saga: Cloudant and Couchbase (NoSQL database©myNoSQL)


Apache CouchDB Is Alive and Kicking

We, the Apache CouchDB team, are writing to you today: do not worry, the project is alive and well.

no comment

Original title and link: Apache CouchDB Is Alive and Kicking (NoSQL database©myNoSQL)


Ubuntu One Drops CouchDB as Foundation of Data Sync

From the Ubuntu mailing list:

From the first days of Ubuntu One, before we were even in Ubuntu, we’ve had a structured data storage sync service based around CouchDB.

For the last three years we have worked with the company behind CouchDB to make it scale in the particular ways we need it to scale in our server environment. Our situation is rather unique, and we were unable to resolve some of the issues we came across. We were thus unable to make CouchDB scale up to the millions of users and databases we have in our datacentres, and furthermore we were unable to make it scale down to be a reasonable load on small client machines.

Because of this, we are turning off most of our CouchDB-related efforts. […]

For these same three years we have created and maintained desktopcouch, which is a desktop service (and related library) to access CouchDB more conveniently. Because we are no longer going to pursue CouchDB, we will no longer be developing desktopcouch;

CouchDB Twitter account’s only comment:

Reports of my death are greatly exaggerated.

I’m filing this under what happened to CouchDB popularity.

Original title and link: Ubuntu One Drops CouchDB as Foundation of Data Sync (NoSQL database©myNoSQL)


How to Implement an IMAP Server on Top of a CouchDB/NoSQL Data Store?

Interesting question on SO:

To summarize my objective here, I am really just looking for a simple, opensource method which allows me to create and maintain a (preferably noSQL db) backup/archieve of one/more remote IMAP email accounts on a per user basis and sync each individual users email accounts using a simple, low cost solution which easily scales out, consumes server resources in an efficient maner with the ADDED ABILITY that each user needs to be able to connect to his central email archive by simply addingba new imap account to his existing email client using an imap server, username and password provided through this archive server/setup.

This reminded me of a GSOC project to design and implement a distributed mailbox on top of Hadoop HDFS as part of the Apache James project. The project description can be found on this JIRA ticket and more details here:

We need to implement mailbox storage as a distributed system on top of Hadoop HDFS. The James mailbox API will be used. A first step is to design how to interact with Hadoop (native api, gora incubator at apache,…) and deal with specific performance questions related to mail loading/parsing in a distributed system (use map/reduce or not, use existing local lucene indexes for search,…). The second step is to implement the HDFS mailbox (maildir mailbox is similar because is stores mails as a file and can be an inspiration). A single James server will still be deployed because we don’t have any distributed UID generation.

According to the last comments on the ticket, this project was completed Ioan Eugen Stan under Eric Charles’ mentorship.

Original title and link: How to Implement an IMAP Server on Top of a CouchDB/NoSQL Data Store? (NoSQL database©myNoSQL)


Griffon and NoSQL Databases

Andres Almiray:

The following list enumerates all NoSQL options currently supported by Griffon via plugins:

  • BerkeleyDB
  • CouchDB
  • Memcached
  • Riak
  • Redis
  • Terrastore
  • Voldemort
  • Neo4j
  • Db4o
  • Neodatis

The first 7 are Key/Value stores. Neo4j is a Graph based database. The last two are object stores. All of them support multiple datasources, data bootstrap and a Java friendly API similar to the one shown earlier.

Griffon is a Groovy-based framework for developing desktop applications. While the coolness factor of Java-based desktop apps is close to zero, having some multi-platform management utilities for these NoSQL databases might be interesting.

Original title and link: Griffon and NoSQL Databases (NoSQL database©myNoSQL)


Kanapes IDE: an IDE for CouchDB

Kanapes IDE is a Windows-only IDE for manipulating data and design documents stored in CouchDB. Basically it offers access to create/modify/delete design document functions like views and lists. And it plans to add support for CouchDB instance configuration. As far as I can tell, Kanapes IDE, even if in early stages, has been well received by the community.

I’ve asked its creator what advantage has Kanapes IDE over Futon:

Have you tried to write a list function few kilobytes long in Futon? :)

Original title and link: Kanapes IDE: an IDE for CouchDB (NoSQL database©myNoSQL)

What Happened to CouchDB’s Popularity?

Top answer:

A lot of this is the result of the confusion in the community, there is the CouchDB Apache project, then the CouchBase work and their own “Single Server” releases that don’t necessarily map 1:1 to the Apache versions.

Then there is the CouchBase “Couch Server” offering which, from what little I can tell, is membase + CouchDB and their CouchDB build, according to their docs, isn’t 100% 1:1 with the Apache CouchDB builds (some differences about protocol or something).

Then you have no officially maintained libraries for the different platforms which was a turn off to me the first time I cracked that egg open.

Then you have CouchBase wanting to focus Couch on the mobile-cloud story since they are the only NoSQL solution doing that , with native builds for some of the mobile platforms.

Then you have BigCouch and IrisCouch and a slew of other things I can’t figure out where they fit in.

Ultimately when you enter the eco system and start digging, it is hard to figure out exactly what “CouchDB” is, where to grab binaries for your platform from and drivers for your platform. As wavephorm pointed out, you can figure it all out with some reading and digging, but you have to persist.

It’s not like Mongo, you don’t just head to the official site, grab the official binary and install the official driver.

I’d also point out that CouchDB’s biggest feature, the must-have feature no other NoSQL repo besides RavenDB replicates, is the master-master replication. If you don’t need that, your barrier to entry with the other NoSQL solutions is much easier/straight forward.

I hope at some point the CouchDB community focuses their efforts on barriers to entries and figures out a common message for beginners they can communicate, and from there introduce the customizations for the people that need them (mobile Couch, BigCouch, etc.)

If only they would have listened to what I’ve been saying all this time.

Original title and link: What Happened to CouchDB’s Popularity? (NoSQL database©myNoSQL)

What the Heck Are Document Databases?

Julie Lerman in an article offering an overview of 3 document databases (CouchDB, MongoDB, RavenDB):

In my research, I’ve heard a MongoDB expert say that the product’s primary concern is performance. A CouchDB expert pointed to simplicity and reliability (“we want to be the Honda Accord of databases”). And Ayende Rahien, creator of RavenDB, said RavenDB aims for “fast writes, fast reads and world peace.” Each of these document databases has even more to offer than what these sound bites suggest.

With the exception of a few twists (which I’ll point out in this article), these databases provide their data most commonly through HTTP, store their data as JavaScript Object Notation (JSON) documents and provide APIs in multiple languages. The overall concerns are simplicity, speed and scalability. Equally important is that all three are open source projects.

Original title and link: What the Heck Are Document Databases? (NoSQL database©myNoSQL)


CouchDB Through the Eyes of a .NET Developer

Marcin Budny:

CouchDB seems to be a solid piece of software used by really big players and what’s more – it’s free. It’s well developed community guarantees that you will get the support and tools you need to build your great apps. Yet, lack of transaction support will make your life harder.

Original title and link: CouchDB Through the Eyes of a .NET Developer (NoSQL database©myNoSQL)


Should I Use MongoDB or CouchDB?

Not a direct comparison of MongoDB and CouchDB, but a list of what Riyad Kalla considered important aspects of each of these solutions.

There is one bullet point that sounds a bit off:

Read Performance - Mongo employs a custom binary protocol (and format) providing at least a magnitude times faster reads than CouchDB at the moment. There is work in the CouchDB community to try and add a binary format support in addition to JSON, but it will still be communicated over HTTP.

I’d venture to say that the “at least one magnitute faster” should happen only when reads in MongoDB are not touching the disk. Otherwise, I’d like to see some data showing how the over-the-wire MongoDB custom protocol and BSON provides 10 times better results than HTTP and JSON.

Riyad Kalla also added a section about Redis and how he finds it useful in most cases in a caching capacity or queue capacity.

Original title and link: Should I Use MongoDB or CouchDB? (NoSQL database©myNoSQL)


Resolving Some CouchDB-Record Inconsistencies in Scala

Aleksa Vukotic:

While the REST interface to Documents and Views in Couch does not require a rich mapping layer (as opposed to the richness of SQL ORM frameworks), I still found it cumbersome to work directly with HTTP all the time in order to store/query my model objects to/from CouchDB.

Currently the Lift-Record framework has a Record implementation for relational databases (Squeryl), as well as Mongo-Record and CouchDB-Record implementations which gained prominence with recent increased interest in NoSQL storage. While the CouchDB-Record implementation is not complete, it has enough features to make it useful when working with CouchDB and Lift. Using CouchDB-Record I could easily map my domain model to the underlying database, and abstract the HTTP layer when I wanted to. The CouchDB-Record implementation did not offer everything that you might expect from a typical O(R)M framework - specifically there are some missing features such as associations mapping, lazy loading, caching.

Two remarks:

  1. When building your next tool or product never ignore the power of habits
  2. How much less time would be spend hacking (and writing about) CouchDB libraries, if there would be a set of official or at least officially-backed CouchDB drivers and libraries.

Original title and link: Resolving Some CouchDB-Record Inconsistencies in Scala (NoSQL database©myNoSQL)