Live data from Hacker News

CouchDB 3.0

blog.couchdb.org

121–130 of 161 posts

Re: CouchDB 3.0

#121
CouchDB is good. Yes. I still dream of the day when the cluster will balance shards automatically and recover better from losing and replacing nodes. :D

Re: CouchDB 3.0

#122

I haven't used CouchDB in years. I just downloaded and installed it. Interesting that there are no apparent links to client libraries in different languages. Perhaps most people just use the HTTP API Reference and roll their own.

In Ruby there is a CouchRest gem, which I've used, but to be honest a REST interface that talks JSON is so easy to use that I've often thought we'd be better off without anything specific.

Re: CouchDB 3.0

#123
post #117

I once read that the right way to use CouchDB is for every user to have its own database. However, how does this work with BI? Or with public data that should be known by all users? Do I create a single centralized DB just for that kind of data? Maybe aggregate data from all users' DBs? Genuinely curious.

For public data, you can try to partition it in such a way that writes can be merged without any potential conflicts. E.g. a user's posts are in a separate partition.

I have never done this with CouchDB, but the technique is described in Martin Kleppman's __Designing Data Intensive Applications__.

Re: CouchDB 3.0

#124

Earlier quoted context omitted.

I mean your CouchDB instance itself is represented by a host and port and your application's data could be stored there and a native HTTP-based API to access said data . This is contrasted to most where you would need a driver and it's accessible only in the "back-end".

> itself is represented by a host and port and your application's data could be stored there All databases are represented by a host and a port. I think you mean CouchDB offers a HTTP-based API that allows queries to be run without requiring a database-specific library and that because it's HTTP, it can be accessed via a browser.

That was my point exactly. Http API us very cool but very far from being unique to couchdb (see InfluxDB, ClickHouse, Prometheus, etc.)

Re: CouchDB 3.0

#125
post #75

Earlier quoted context omitted.

I don't think couchbase has couchdb in mind for the mobile client anymore

Correct. The newest version of CouchBase mobile no longer supports CouchDB as a replication target. It can still be accomplish with the CouchBase Sync Gateway, but get complicated quickly.

I evaluated Couchbase mobile about a year ago and found although it worked well once setup there was a lot of overhead and the docs seemed a little all over the place and the fact that you can't also use the same DB on the web anymore with PouchDB meant I ultimately dropped it. It's a shame because there isn't really anything open source / self hosted like it for mobile.

Re: CouchDB 3.0

#126
post #12

At this point why would you use CouchDB over something like MongoDB? Seriously asking... Over the past 5 years MongoDB has gotten a great storage engine, transactions, distributed transactions, multi master replication, first class change streams and is very very solid as a foundational piece of infrastructure you can rely on while CouchDB has languished. I can’t imagine reaching for it in my tool belt when I need a…

MongoDB has _suspiciously_ amazing SEO and marketing. CouchDB's by contrast is awful. As silly as that sounds as a reason to choose CouchDB it demonstrates where the respective company's priorities lie.

Similar story with RethinkDB which was actually a really nice database. I know it's not dead but I can't imagine starting a new project with it.

Re: CouchDB 3.0

#127
post #98

Earlier quoted context omitted.

It’s trivial to limit number of created documents in postgres, couchdb or application server though validation, I’m talking about updating document not creating new. In posgres if I update 1mb document used space will not always grow. In couch db situation is different. In case of relation db you have application server with custom logic and validations, couchdb from other side is accessible from outsize. My idea tha…

Is it trivial? Let’s say you have a back end and an app that lets you post comments, like this site. How do you stop someone from spamming comments? Each comment is represented by a row in a table so the space will grow.

If you need to limit the number of items it is trivial. You need to write something like `has_many :things, :before_add => :limit_things` in app server or create constraint in sql.

Spam prevention is not trivial but mostly solved problem. You can find a lot of articles about this topic.

But creating secure couchdb looks like very non-trivial.

Re: CouchDB 3.0

#128
post #98

Earlier quoted context omitted.

It’s trivial to limit number of created documents in postgres, couchdb or application server though validation, I’m talking about updating document not creating new. In posgres if I update 1mb document used space will not always grow. In couch db situation is different. In case of relation db you have application server with custom logic and validations, couchdb from other side is accessible from outsize. My idea tha…

> It’s trivial to limit number of created documents in postgres, couchdb or application server though validation, I’m talking about updating document not creating new. In posgres if I update 1mb document used space will not always grow. In couch db situation is different. In case of relation db you have application server with custom logic and validations, couchdb from other side is accessible from outsize. It is? It…

Couch is not equivalent to mongo or relational because it accessible to clients if we want synchronisation. Securing app server is manageable problem and there is huge number of resources how to do it correctly.

In case of couch I've not seen any secure open-source example.

I'm not focused on DOS attacks, I'm just proposing different attack vectors.

Re: CouchDB 3.0

#129
post #12

At this point why would you use CouchDB over something like MongoDB? Seriously asking... Over the past 5 years MongoDB has gotten a great storage engine, transactions, distributed transactions, multi master replication, first class change streams and is very very solid as a foundational piece of infrastructure you can rely on while CouchDB has languished. I can’t imagine reaching for it in my tool belt when I need a…

The main reason most people use CouchDB is because of the HTTP API and offline support with Couchbase Mobile and PouchDB. Doesn't CouchDB have most of those things already from 2.3?

MongoDB recently bought Realm which is an amazing mobile database with first class replication, so if I was starting a new project that also needs mobile I would definitely go with MongoDB.

Re: CouchDB 3.0

#130
post #55

CouchDB is awesome, full stop. While it's missing some popularity from MongoDB and having wide adoption of things like mongoose in lots of open source CMS-type projects, it wins for the (i believe) unique take on map / reduce and writing custom javascript view functions that run on every document, letting you really customize the way you can query slice and access parts of your data... Example: I'm building a documen…

>CouchDB is awesome, full stop. The problem I had with CouchDB is integrating it into a framework like Rails. CouchDB on its own does so much cool stuff. The "free" HTTP API and client replication via PouchDB are the two huge ones. But it just wasn't smooth enough to get the data out, use it where I wanted, and then save it back.

Check out https://github.com/langalex/couch_potato/
Post reply on HN