
CouchDB 2.0 - k__
https://blog.couchdb.org/2016/09/20/2-0/
======
matt4077
Yet another product blog that doesn't manage to prominently link to the
product.

If you want to make my life a tiny bit easier:

\- blog.<project>.org needs a link to <project>.org because half of you
visitors want to read the "it" before they read the "news".

\- github.com/<you>/<Transmogrifier>For<ThatProject> should have a link to
<ThatProject> in the description or the readme's first paragraph. I often come
across interesting plugins without knowing anything about projects' they are
for.

(and yes, I know there are actual problems in the world. But these are easy to
solve)

~~~
SkyMarshal
Why is this the top post

------
k__
TL;DR

\- Clustering
[https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture...](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/)

\- New Query Language [https://blog.couchdb.org/2016/08/03/feature-mango-
query/](https://blog.couchdb.org/2016/08/03/feature-mango-query/)

\- New Admin Interface (written in React)
[https://blog.couchdb.org/2016/07/27/fauxton-the-new-
couchdb-...](https://blog.couchdb.org/2016/07/27/fauxton-the-new-couchdb-
dashboard/)

~~~
cbHXBY1D
Also, 2.0 is the unification of BigCouch (Cloudant's work) with the old single
node CouchDB.

------
fiatjaf
As an low-profile developer who's been using CouchDB for a long time, some
weeks ago I've written some quick personal opinions on what CouchDB has
become: [http://fiatjaf.on.flowi.es/about-
couchdb/](http://fiatjaf.on.flowi.es/about-couchdb/)

~~~
pokstad
My thoughts exactly. I'm not sure who CouchDB is supposed to be for anymore.
The original developers who fell in love with it are moving on. Who is the
audience for 2.0? Who does IBM hope to reach with Cloudant?

BTW, you are spot on about continuous replication. Try using continuous
replication on Cloudant and you will end up with a fat bill.

~~~
willholley
There are a lot of use cases, particularly around multi-region/DC master-
master replication, where CouchDB/Cloudant is a great fit. IBM also offers
MongoDB, RethinkDB, Postgres as managed services and the MVCC/conflict model
in Couch is still a standout feature. The other use case I see a lot of is
offline-capable apps backed by Couch replication-compatible datastores
(PouchDB, Cloudant Sync, Couchbase Lite).

Cloudant recently changed its pricing structure [1] (via IBM Bluemix) which
should significantly reduce the cost of continuous replication - that may be
worth a look if the current model is problematic.

[1] [https://developer.ibm.com/bluemix/2016/07/26/cloudant-
public...](https://developer.ibm.com/bluemix/2016/07/26/cloudant-public-
improved-pricing-model/)

~~~
pokstad
Interesting, this came out in July and Cloudant still hasn't updated their
pricing structure on their site.

------
SEJeff
Sad to _not_ see Jepsen tests ran on this at least by the developers when
releasing a new clustering piece.

The folks working on cockroachdb recently did this[1] and it was a good read.

[1] [https://www.cockroachlabs.com/blog/diy-jepsen-testing-
cockro...](https://www.cockroachlabs.com/blog/diy-jepsen-testing-cockroachdb/)

~~~
robinson_k
CouchDB is eventually consistent and does not guarantee consistency. Would a
Jepsen test make sense?

~~~
SEJeff
Yes. Eventual consistent doesn't mean inconsistent, but eventually it will be.
That means under a network partition (P of th CAP Theorem) things should
converge after the network converges. This is precisely the type of semantic
that Aphyr wrote Jepsen for. See his testing of Cassandra (eventually
consistent) or the CockroachDB team (eventually consistent) or Risk
(eventually consistent) running Jespsen to prove things work as expected.

~~~
SEJeff
And by Risk I meant Riak but didn't notice it in time to edit the comment
(sorry).

------
marknadal
Congrats to the CouchDB team! I remember playing around with writing a NodeJS
driver for it all the way back in 2011. Sadly, I decided to use and make a
driver for MongoDB instead simply because it was easier at the time. Despite
that choice, I have always admired CouchDB for pushing the frontiers on stuff
like Offline-First with PouchDB way ahead of its time (and also what inspired
me a little bit for our Open Source Firebase alternative
[http://gun.js.org/](http://gun.js.org/) ).

I am particularly really excited to see the announcement of the Mango query
language, since querying Couch was one of lesser-easy things to do back then.
I'm also very excited to hear about performance improvements, as this has been
particularly interesting to me as I've been tracking various system's
performance as I have worked on our own (Mongo with Wired Tiger, Cassandra,
Redis, and even Chrome V8 engine as we have built towards 30M+ ops/sec, see
[https://github.com/amark/gun/wiki/100000-ops-sec-in-
IE6-on-2...](https://github.com/amark/gun/wiki/100000-ops-sec-in-IE6-on-2GB-
Atom-CPU) ). However clicking through on the performance links didn't lead to
any numbers or benchmarks. I would love to see that!

Really happy that Couch is on the homepage of Hacker News. I really feel like
they made lots of correct decisions that got passed over by the NoSQL craze,
and have lately not been receiving the type of attention as it should compared
to (what I biasly think) unfavorable but hyped up Master-Slave systems. People
should really check into Couch's Master-Master replication!

------
eriknstr
Just installed it on FreeBSD 10.3.

Fetched and unpacked the source tarball, then did mostly what the
INSTALL.Unix.md said to do;

    
    
      sudo pkg install erlang icu spidermonkey185 gmake gcc curl help2man py27-sphinx
    
      ./configure
    
      gmake release
    
      sudo pw useradd couchdb -u 5984 -c "CouchDB Administrator" -L daemon -s /usr/local/bin/bash
    
      sudo cp -R rel/couchdb /home/couchdb
    
      sudo chown -R couchdb:couchdb /home/couchdb
    
      sudo find /home/couchdb -type d -exec chmod 0770 {} \;
    
      sudo find /home/couchdb/etc/ -type f -exec chmod 0644 {} \;
    

Note how I set the uid to 5984 ;)

Unfortunately, when I try to actually run it...

    
    
      sudo -i -u couchdb ~couchdb/bin/couchdb
    

...I'm just getting messages like:

    
    
      [error] 2016-09-20T23:57:55.321596Z couchdb@localhost emulator -------- 
      Error in process <0.547.0> on node couchdb@localhost with exit value:
    
      {database_does_not_exist,[{mem3_shards,load_shards_from_db,"_users",
      [{file,"src/mem3_shards.erl"},{line,327}]},{mem3_shards,load_shards_from_disk,1,
      [{file,"src/mem3_shards.erl"},{line,315}]},{mem3_shards,load_shards_from_disk,2,
      [{file,"src/mem3_shards.erl"},{line,331}]},{mem3_shards,for_docid,3,
      [{file,"src/mem3_shards.erl"},{line,87}]},{fabric_doc_open,go,3,
      [{file,"src/fabric_doc_open.erl"},{line,38}]},
      {chttpd_auth_cache,ensure_auth_ddoc_exists,2,
      [{file,"src/chttpd_auth_cache.erl"},{line,187}]},
      {chttpd_auth_cache,listen_for_changes,1,
      [{file,"src/chttpd_auth_cache.erl"},{line,134}]}]}
    
      [notice] 2016-09-20T23:57:55.321650Z couchdb@localhost <0.323.0> -------- 
      chttpd_auth_cache changes listener died database_does_not_exist at 
      mem3_shards:load_shards_from_db/6(line:327) <= mem3_shards:load_shards_from_disk/1(line:315) <= 
      mem3_shards:load_shards_from_disk/2(line:331) <= mem3_shards:for_docid/3(line:87) <= 
      fabric_doc_open:go/3(line:38) <= chttpd_auth_cache:ensure_auth_ddoc_exists/2(line:187) <= 
      chttpd_auth_cache:listen_for_changes/1(line:134)

~~~
chrisfosterelli
The new clustered instance doesn't autocreate the system tables. It used to do
this in 1.x, but no longer does.

You'll have to create these tables:

* _global_changes

* _metadata

* _replicator

* _users

It's a bit of a pain!

~~~
janl
The admin interface has a convenient “Setup” menu point that does all this for
you :)

~~~
eriknstr
Thank you both. I assumed that the messages indicated critical error which
would mean that CouchDB was not in a running state but indeed the system is
running and the admin interface is reachable at 127.0.0.1:5984/_utils/ where
the setup can be completed.

~~~
janl
It didn't make the cut for 2.0.0, but we definitely should have a nice message
there on the command line. Sorry about that! :)

~~~
eriknstr
No worries. Deciding it was time to play with CouchDB once again, I just spent
the last few hours moving a little side-project I'm working on over from
PostgreSQL to CouchDB 2.0. I liked CouchDB last time I tried it but then
forgot about it for a while, and aside from that little bit of confusion,
CouchDB 2.0 has held up to your motto -- "time to relax!".

Well, "moving over" might be a slight exaggeration seeing as how my little
project is in such early inception that all I had prior to switching it over
to CouchDB 2.0 was a few SQL-files defining the schema of various tables, as
well as a couple of other SQL-files with queries to run and a bit of sample
data. But anyway, the point still stands that said little project is now using
CouchDB.

------
nowprovision
A fews things I wanted out of CouchDB years back: \- faster bulk indexing \-
space reduction, I think a simple couchdb to psql json was 1/10th of size \-
ES6 or even ES5 - * its been a few years since I last looked but I remember
you had to tread carefully - Object.keys maybe was one?

When I started with CouchDB it wrong choice for so many reasons, client had
<30gb of data, couchdb was cooler than node.js, and I was frustrated with SQL
Server. In hindsight sticking with SQL Server or Postgresql would of been
better - older/wiser today.

~~~
janl
> \- faster bulk indexing

With clustering you now get that. By way of “oversharding” even on a single
node. Speed up is linear with number of shards / CPUs

> \- space reduction,

2.0 has the better compaction format. There are still ways to improve, but we
are getting there.

> \- ES6 or even ES5

Our custom wrapper around Spidermonkey 185 is getting long in the tooth. It
didn’t make it into 2.0, but we are well aware that this needs updating.

Anyway, sounds like we got there in the end ;)

------
drhayes9
I love Couch and I feel totally relaxed. What are people building with it?

A spiffy log package was the first thing I thought of and indeed that's one
idea listed on this page:
[http://docs.couchdb.org/en/2.0.0/intro/why.html](http://docs.couchdb.org/en/2.0.0/intro/why.html)

But I think the "logging" case is hard to argue vs. "manually" grepping (or
ag-ing using the silver searcher) over in-place log files and
aggregating/rendering dashboards via static files.

~~~
teddyc
I used it to store user-uploaded images in a photo contest website years ago.
It was a happy medium between storing images directly on the filesystem or as
a blob/binary in a relational database. The image requests were AJAX, so I
could include the clients screen dimension in the request. My app would resize
on the fly if necessary, store resized image to CouchDB, and redirect the
image request to CouchDB, which was publicly readable.

Another good use case I had was for JSONP request for an auto-complete input
field on a webpage. Again, the database was publicly readable.

I have also used it to aggregate data for graphs. The data changed daily, so
the ability to cache the results of a view until the data changed was nice.
But the first request of data each day still took a while. I don't think I got
a performance boost in this case, but I did get free caching.

All my other uses of CouchDB were mostly for fun and could've been implemented
in traditional SQL.

------
eriknstr
I bought the first edition of an O'Reilly book called _CouchDB: The Definitive
Guide_ a few years back.

Looking at the online draft version of the book, the tour chapter [0] still
has version 0.10.1 in the example.

I wonder if there will be a second edition of the book covering mango,
clustering and the new admin interface.

[0]:
[http://guide.couchdb.org/draft/tour.html](http://guide.couchdb.org/draft/tour.html)

~~~
pokstad
That was a great book that got me into CouchDB. I think the original authors
of that book, primarily Damien Katz and J. Chris Anderson, left for Couchbase.
Today's CouchDB has different motives than the one that book was written for.
Couch Apps are no longer the killer feature.

~~~
janl
The book definitely needs an update.

Just a heads up, Damien didn’t work on that.

------
qwertyuiop924
I'm actually really excited for this. There seem to be a lot of new,
interesting, and useful features, and I'm already a huge fan of the couch
model.

------
bdcravens
> The second major feature is the declarative query language “Mango”.

Nice name :-)

~~~
Direct
I wonder if the design is based on some of the solid research that went into
MangoDB[0].

[0]: [https://github.com/dcramer/mangodb](https://github.com/dcramer/mangodb)

~~~
k__
They wrote something about it being the old codename for the cloudant query
language on which they based it.

------
hiphipjorge
The UI looks pretty awesome. Kind of see the RethinkDB influence in shipping
with a web admin, and it's great that where things are heading.

~~~
chromakode
Couch did it first!

------
m_mueller
So, as a CouchDB 1.x user, where to go next? CouchDB 2.x or Couchbase?

~~~
rdtsc
CouchDB 2.0 is a direct descendant of CouchDB 1.x. The API is 99% compatible,
same community working on it, you can replicate between them and so on.

I haven't used Couchbase, but I understand besides the "Couch" prefix and that
CouchDB's original author working there for a few years, it doesn't have much
in common with CouchDB project.

~~~
m_mueller
Well Couchbase Lite is largely compatible as far as I can attest. Not sure how
it is with Couchbase proper, but I was under the assumption that it is API
compatible to CBL.

------
mehh
So its taken about 3 years to get from the alpha to release .. meh!

Whilst I really like couch I'm just not convinced on using it in production
due to its glacial pace.

------
maxpert
Good to see v2.0 took them quite long but hey better late then never.

------
Kristine1975
The first thing I think upon hearing CouchDB is "perform like a pr0n star"...

------
desireco42
I remember CouchDB when it was initially released, it was one of the most
promising and innovative DB's around. It's a shame it didn't live up to the
hype.

~~~
patwolf
I wouldn't say that it didn't live up to the hype. I think it just has a
steeper learning curve than a lot of other NoSQL databases and is often
overlooked.

MongoDB makes a lot of sense to folks already familiar with relational
databases. Collections are like tables, documents are like rows, and it's easy
to use document IDs to establish relations and perform queries like you would
in a relational database. There are a lot of problems with using it like a
RDBMS, but still a developer with zero knowledge of MongoDB can become
productive with it very quickly.

When learning CouchDB, the first WTF moment is when you realize there are no
tables and that all the documents regardless of the type of data they contain
go in the same place. Eventually you learn that you can add a type field to
the documents to distinguish between them, which does feel hackish. The next
WTF moment is when you want to query the data and realize you have to use map-
reduce to do what would seem trivial in any other database. The early version
of the admin tool definitely didn't make this easy since it required writing a
JavaScript function and escaping it so that it could be stored as a single-
line JSON string. It also didn't help that the map-reduce code was stored in
special documents that used magical document IDs to distinguish them from
other documents, which again feels hackish but makes sense eventually.

That said, I am a big fan of CouchDB, and I hope that with the query language
and new UI in 2.0 that CouchDB will earn the respect it deserves.

~~~
desireco42
Yeah MongoDB kind of dumbed down whole 'rethinking db' attempt. Compared to
how much attention and developers others much simpler db's got, CouchDB
definitely didn't get as much as it should and could.

I am looking forward to see new features for sure.

------
wildchild
Useless abandonware.

