4 ms·
As a long-time CouchDB user, I'm going to assume that by "weird failure modes", you mean "conflicts". There are some awesome aspects to using CouchDB, but gett
by smoyer 11y ago
As a long-time CouchDB user, I'm going to assume that by "weird failure modes", you mean "conflicts". There are some awesome aspects to using CouchDB, but getting used to conflicts certainly took some time. In short, your application needs to include the code to resolve problems that arise due to network partitions or concurrent writes to different nodes. On the other hand, it's a really stable platform and the write-only database files worked really well (we lost zero data in over 5 years of operation ... even with tests that included powering down a node while in use).
But ... I also believe that CockroachDB is going to be the project to finally solve these problems and it's got an SQL interface! I'm waiting for SQL joins, and then I suspect I'll be moving at least some of my clustered PostgreSQL instances to CockroachDB.
- LoSboccacc 11y agono I mean things like this: http://docs.couchdb.org/en/stable/cluster/nodes.html#removing-a-node http://docs.couchdb.org/en/stable/cluster/nodes.html#removin... http://docs.couchdb.org/en/stable/cluster/sharding.html#moving http://docs.couchdb.org/en/stable/cluster/sharding.html#movi... http://docs.couchdb.org/en/stable/cluster/sharding.html#reshard-no-preshard http://docs.couchdb.org/en/stable/cluster/sharding.html#resh... sharding needs to be taken care manually, there is nowhere on the docs handling what happens in the event of a failover and no how to replace a failed populated node with an empty one so that the cluster can recover. those are quite big concerns if sharding with a replica set for fault tolerance is the main objective.