> If you make a change to a single view in a design document, the database system will rebuild all indexes in that design document unconditionally,
That's a feature. If they don't usually change together put them in a separate design documents.
> and manage those documents yourself.
It's a document database. So managing documents yourself is kind of what you do. Isn't it?
> he data itself is stored in a single file per shard, opened in O_APPEND mode, effectively serializing all writes on the shard.
So have more shards? A lot of databases use append only mode. There is a reason for that. Having uses the db for a good number of years, it had never lost data. Even during power outages or brutal restarts. That's more than I can say about other databases.
> no shared memory for IPC,
Shared memory IPC doesn't magically solve problems but it is a minefield of bugs.
> use of mmap AFAICT.
Large blocks of allocated memory use malloc instead of brk so memory allocation uses mmap. For file IO mmap isn't a panacea either. If data is not there, reads will still go to the disk. If it uses regular reads through data should end up in the page cache
> kswapd active,
Hmm, seeing kswapd being active is not something I look forward on a production server. From what I remember I have seen page cache utilized correctly and that's what should matter. Not kswapd.
> Transactional behavior: no, aside from a single bulk write feature
bulk docks is not a transactional feature. The database is not CP database so it doesn't have transactional feature.
> But worst of all: every time it starts up, it tells me "it's time to relax". Nothing about this is relaxing.
Yeah that is silly never liked that. From what I remember it was a DB that was built when MySQL ruled the open source DB world and many of the current DBs were not there. It was actually pretty relaxing being able to insert regular json object in it, index them, have master to master replication (which most dbs still don't support), have a nice built in web dashboard to inspect and query documents.
> Or you can use a query language mostly similar to what MongoDB uses
Yes, provided you started on 2.0, as I specifically stated in a reply.
> That's a feature. If they don't usually change together put them in a separate design documents.
Unnecessary computation and I/O is not a feature. They should hash the views individually. A database that makes me do extra work to keep it from doing unnecessary work is not helpful.
> So managing documents yourself is kind of what you do. Isn't it?
This doesn't have anything to do with the unnecessary index rebuilds. CouchDB has all of the information it needs to avoid this unnecessary computation and I/O.
> So have more shards
More shards spending time serializing and deserializing JSON instead of doing useful work. Throwing shards at inefficient code might help, but it doesn't address the underlying problem.
> Shared memory IPC doesn't magically solve problems but it is a minefield of bugs.
Lots of database systems manage to use it just fine. You probably use one of them. And it does solve a problem: it avoids serializing and deserializing all of your data down a pipe.
> Large blocks of allocated memory use malloc instead of brk so memory allocation uses mmap.
Yes, with MAP_ANONYMOUS. I'm not talking about anonymous mappings.
> Hmm, seeing kswapd being active is not something I look forward on a production server.
For swap? Sure. For file-backed mmap pageout guided by madvise? I actually do. It means the VMM is being used for its intended purpose.
> bulk docks is not a transactional feature
It was an example of the one way to achieve an atomic write of multiple documents, which comes in very handy for any nontrivial application.
I'd honestly be fine with them just deprecating the entire external view server protocol – but as it stands now, it's a supported feature, the performance documentation in 5.2.5 of the manual is nonsensical, and it performs very very poorly due to excessive serialization/deserialization and inefficient IPC.
Or you can use a query language mostly similar to what MongoDB uses http://docs.couchdb.org/en/2.0.0/api/database/find.html
> If you make a change to a single view in a design document, the database system will rebuild all indexes in that design document unconditionally,
That's a feature. If they don't usually change together put them in a separate design documents.
> and manage those documents yourself.
It's a document database. So managing documents yourself is kind of what you do. Isn't it?
> he data itself is stored in a single file per shard, opened in O_APPEND mode, effectively serializing all writes on the shard.
So have more shards? A lot of databases use append only mode. There is a reason for that. Having uses the db for a good number of years, it had never lost data. Even during power outages or brutal restarts. That's more than I can say about other databases.
> no shared memory for IPC,
Shared memory IPC doesn't magically solve problems but it is a minefield of bugs.
> use of mmap AFAICT.
Large blocks of allocated memory use malloc instead of brk so memory allocation uses mmap. For file IO mmap isn't a panacea either. If data is not there, reads will still go to the disk. If it uses regular reads through data should end up in the page cache
> kswapd active,
Hmm, seeing kswapd being active is not something I look forward on a production server. From what I remember I have seen page cache utilized correctly and that's what should matter. Not kswapd.
> Transactional behavior: no, aside from a single bulk write feature
bulk docks is not a transactional feature. The database is not CP database so it doesn't have transactional feature.
> But worst of all: every time it starts up, it tells me "it's time to relax". Nothing about this is relaxing.
Yeah that is silly never liked that. From what I remember it was a DB that was built when MySQL ruled the open source DB world and many of the current DBs were not there. It was actually pretty relaxing being able to insert regular json object in it, index them, have master to master replication (which most dbs still don't support), have a nice built in web dashboard to inspect and query documents.