ALL COVERED TOPICS

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

NAVIGATE MAIN CATEGORIES

Close

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

Here Is Why in Cassandra vs. HBase, Riak, CouchDB, MongoDB, It's Cassandra FTW

Brian ONeill:

Now, since choosing Cassandra, I can say there are a few other really important less tangible considerations. The first, is the code base. Cassandra has an extremely clean and well maintained code base. Jonathan and team do a fantastic job managing the community and the code. As we adopted NoSQL, the ability to extend the code-base and incorporate our own features has proven invaluable. (e.g. triggers, a REST interface, and server-side wide-row indexing)

Secondly, the community is phenomenal. That results in timely support, and solid releases on a regular schedule. They do a great job prioritizing features, accepting contributions, and cranking out features. (They are now releasing ~quarterly) We’ve all probably been part of other open source projects where the leadership is lacking, and features and releases are unpredictable, which makes your own release planning difficult. Kudos to the Cassandra team.

Everything sounds reasonable except for Riak being the “new kid on the block” and not finding support for it. Basho, where were you hidding?

Original title and link: Here Is Why in Cassandra vs. HBase, Riak, CouchDB, MongoDB, It’s Cassandra FTW (NoSQL database©myNoSQL)

via: http://brianoneill.blogspot.com/2012/04/cassandra-vs-couchdb-mongodb-riak-hbase.html


NoSQL Databases Adoption in Numbers

Source of data is Jaspersoft NoSQL connectors downloads. RedMonk published a graphic and an analysis and Klint Finley followed up with job trends:

NoSQL databases adoption

Couple of things I don’t see mentioned in the RedMonk post:

  1. if and how data has been normalized based on each connector availability

    According to the post data has been collected between Jan.2011-Mar.2012 and I think that not all connectors have been available since the beginning of the period.

  2. if and how marketing pushes for each connectors have been weighed in

    Announcing the Hadoop connector at an event with 2000 attendees or the MongoDB connector at an event with 800 attendeed could definitely influence the results (nb: keep in mind that the largest number is less than 7000, thus 200-500 downloads triggered by such an event have a significant impact)

  3. Redis and VoltDB are mostly OLTP only databases

Original title and link: NoSQL Databases Adoption in Numbers (NoSQL database©myNoSQL)


Which NoSQL Databases Are Robust to Net-Splits?

Answered on Quora:

  • Dynamo (key-value)
  • Voldemort (key-value)
  • Tokyo Cabinet (key-value)
  • KAI (key-value)
  • Cassandra (column-oriented/tabular)
  • CouchDB (document-oriented)
  • SimpleDB (document-oriented)
  • Riak (document-oriented)

A couple of clarifications to the list above:

  1. Dynamo has never been available to the public. On the other hand DynamoDB is not exactly Dynamo
  2. Tokyo Cabinet is not a distributed database so it shouldn’t be in this list
  3. CouchDB isn’t a distributed database either, but one could argue that with its peer-to-peer replication it sits right at the border. On the other hand there’s BigCouch.

Original title and link: Which NoSQL Databases Are Robust to Net-Splits? (NoSQL database©myNoSQL)


NoSQL Hosting Services

Michael Hausenblas put together a list of hosted NoSQL solutions including Amazon DynamoDB and SimpleDB, Google App Engine, Riak, Cassandra, CouchDB, MongoDB, Neo4j, and OrientDB. If you go through my posts on NoSQL hosting , you’ll find a couple more.

Original title and link: NoSQL Hosting Services (NoSQL database©myNoSQL)

via: http://webofdata.wordpress.com/2012/03/18/hosted-nosql/


How to Make CouchDB (Feel) Faster

A couple of tips and tricks from Martin ‘MC’ Brown that could help improve the CouchDB performance1:

Within CouchDB, there is a one-to-one relationship between the design documents that you create, and the indexes that are produced in the process.

Plus using stale views, updating views after and using the _changes feed.


  1. Or at least the perceived performance. 

Original title and link: How to Make CouchDB (Feel) Faster (NoSQL database©myNoSQL)

via: http://blog.safaribooksonline.com/2012/03/14/improving-couchdb-performance/


CouchDB in Node Package Manager Exposed Password Hashes

The security alert:

  • Your password wasn’t leaked, but the hash was. Still not great.
  • It’s fixed now.

The root problem?

To do login, npm uses the /_users database in couchdb. By default, CouchDB prior to version 1.2.0 makes this database world-readable.

Yet another problem

Latest stable CouchDB release is 1.1.1. And you’ll probably find some more nasty comments in the Hacker News thread.

Workaround

Captured by Klint Finley from Jan Lehnardt:

For those not ready to upgrade to 1.2.0 CouchDB developer Jan Lehnardt suggests restricting access to /_users with a proxy.

Conclusions

  1. Klint Finley:

    The good news of course is that the CouchDB is changing this default behavior. The bad news is that it took this long for the problem with NPM to be noticed and fixed.

  2. Me: the very bad news is that security is still an after-thought for many NoSQL databases.

Original title and link: CouchDB in Node Package Manager Exposed Password Hashes (NoSQL database©myNoSQL)


A Question About NoSQL Managed Hosting

It’s impossible to always have the right answers to all the questions. So this time I’ll have to ask you all: why only some NoSQL databases are present in managed hosting offers?

The first wave of NoSQL managed hosting services brought MongoDB, CouchDB, and some Redis. The second wave brought some more MongoDB, CouchDB, and just a bit more of Redis. It was only the third wave that brought some managed services for graph databases: Neo4j and OrientDB. Plus the first proposal for Cassandra managed hosting.

The first answer that comes to mind when thinking about NoSQL managed services is adoption. If a product is not in wide use then the chances for a company to run a profitable hosting business are very low. But I have the feeling that this is not the only or the complete answer.

Please chime in and share your thoughts.

Original title and link: A Question About NoSQL Managed Hosting (NoSQL database©myNoSQL)


Tropo and CouchDB: SMS Voting App in 10 Minutes

Mark Headd:

By pairing Tropo with CouchDB and a CouchApp running in IrisiCouch, you can have an SMS and phone voting app running entirely in the cloud in about 10 minutes. It should actually take you longer to write up the categories for your voting app than it should to deploy this solution.

Code available on GitHub.

Original title and link: Tropo and CouchDB: SMS Voting App in 10 Minutes (NoSQL database©myNoSQL)

via: http://blog.tropo.com/2012/02/08/sms-voting-app-in-10-minutes-with-tropo-and-couchdb/


A Plan for Apache CouchDB: Putting the Apache Back Into CouchDB

Dave Cottlehuber has a great plan for the Apache CouchDB community to restore confidence and increase mind-share in order to fulfil a great goal:

I’d like to see CouchDB as being the enabler in open data, in breaking open the web for joe & jane user, and enabling interoperability of large data sets especially in research and for government. And an independent replication protocol, with a reference implementation, well supported and documented, is critical to that end - even if the back end isn’t actually CouchDB.

I’ve lost track of how many times I wrote that CouchDB needs clarity in positioning and just a bit of an ecosystem (that includes at least good documentation and a set of recommended libraries and tools).

Original title and link: A Plan for Apache CouchDB: Putting the Apache Back Into CouchDB (NoSQL database©myNoSQL)

via: http://muse.net.nz/blog/2012/02/04/putting-the-apache-back-into-couchdb/


Fulltext search your CouchDB in Ruby

When having to choose what library to use for full text indexing of CouchDB data for a Ruby application, Taylor Luk looked at from Sphinx, Lucene, Ferret, Xapian and decided to go with Xapian with Xapit . Besides the fact that Xapian with Xapit offers a clean interface and customization of the indexing process, there seem to be quite a few important limitations:

  • Xapit is still under active development
  • You need to trigger Index update manually
  • It doesn’t Incremental index update at the moment

I know some are afraid of managing a Java stack, but in the land of indexing, Lucene, Solr, ElasticSearch, IndexTank are the most powerful tools.

Original title and link: Fulltext search your CouchDB in Ruby (NoSQL database©myNoSQL)

via: http://taylorluk.com/post/17255656638/fulltext-search-your-couchdb-in-ruby


Getting off the CouchDB... or Lessons Learned while Experimenting in Production

The move to CouchDB went well. Pages in our web application that would occasionally time out were now loading in a couple of seconds. And, our MySQL database was much, much happier. We liked CouchDB so much that we started planning a feature that would make heavy use of CouchDB’s schema-less nature.

And that’s when the wheels came off.

Word of caution: this is not the “CouchDB sucks so we went with MongoDB” type of post. It’s more of “we thought CouchDB can solve one of our problems, but then got confused and thought it can solve world hunger. So we decided to throw a bunch of data to it to see if it sticks. Surprise! It didn’t.”

Just to be clear, I’m not defending CouchDB and everything John Wood writes about it is correct. It’s just that experimenting with CouchDB in a non-production environment or at least reading myNoSQL would have already offered all those answers.

Original title and link: Getting off the CouchDB… or Lessons Learned while Experimenting in Production (NoSQL database©myNoSQL)

via: http://blog.signalhq.com/2012/01/24/getting-off-the-couchdb/


History of Couch Projects

Just in case you thought someone made up the whole thing about the status of CouchDB being confusing:

History of Couch Projects

Found in Koji Kawamura‘s Introduction of CouchDB JP slides .

On the other hand I’m still trying to figure out if things in CouchDB land were more confusing than the various Hadoop versions out there. If you compare the two genealogy trees you’ll notice a reversed pattern.

Original title and link: History of Couch Projects (NoSQL database©myNoSQL)