3 ms·

Why did you move from couch? I'm considering couch for a project, and am not especially knowledgeable in the space. Couch has worked fine for a low-load, mini

by dhimes 15y ago

Why did you move from couch? I'm considering couch for a project, and am not especially knowledgeable in the space. Couch has worked fine for a low-load, minimal-functioning prototype store (no replication needs, etc.). Its scary feature to me is dealing with compacting-- how and when to schedule it so a large db won't get bogged-down.

daleharvey 15y ago
Couch now has an inbuilt compaction deamon, so you can configure it to run automatically https://github.com/apache/couchdb/blob/trunk/etc/couchdb/default.ini.tpl.in#L197 https://github.com/apache/couchdb/blob/trunk/etc/couchdb/def...
- dhimes 15y ago
  What I haven't tested, though, is how long compaction takes- that is, how it scales with db size and whether more frequent compaction means closer to constant scaling. Once the prototype was up I started working on other parts of the system (and the business for that matter) and only half-paid-attention to the mailing list. The mailing list for couch is quite good, btw.
  - rdtsc 15y ago
    It is better to do it during downtime. You can basically provide scheduling rules such as 'compact when fragmentation % > X AND time-of-day window is Y'.
matthewcford 15y ago
At the time, I really liked the idea of couch doc versions, but considering that go away after compaction I was sad about that it didn't give me versioning for free. I think it just came down to preference, MongoDB has a nice way of doing quieres, without having to use views, also its a bit faster, although I've seen people speed up couch by using protocol buffers etc. Now that I havent been following couch for a while the fragmentation in between couch versions, doesn't help when evaluating if I should try it again.
- dhimes 15y ago
  I find that strange, also. It just seems like, either compact continuously (and don't make me worry about enormous dbs because of hidden files, and the trouble that can happen when it gets too large (> 1/2 disk space, so I understand)), or give easy access to the versions. I'd prefer the first, but from a user perspective (although maybe not a db-designer perspective), either-or makes sense. That's the fallout of eventual concurrency, though.

by dhimes 15y ago

daleharvey 15y ago

Couch now has an inbuilt compaction deamon, so you can configure it to run automatically https://github.com/apache/couchdb/blob/trunk/etc/couchdb/default.ini.tpl.in#L197 https://github.com/apache/couchdb/blob/trunk/etc/couchdb/def...

dhimes 15y ago
What I haven't tested, though, is how long compaction takes- that is, how it scales with db size and whether more frequent compaction means closer to constant scaling. Once the prototype was up I started working on other parts of the system (and the business for that matter) and only half-paid-attention to the mailing list. The mailing list for couch is quite good, btw.
- rdtsc 15y ago
  It is better to do it during downtime. You can basically provide scheduling rules such as 'compact when fragmentation % > X AND time-of-day window is Y'.

matthewcford 15y ago

At the time, I really liked the idea of couch doc versions, but considering that go away after compaction I was sad about that it didn't give me versioning for free. I think it just came down to preference, MongoDB has a nice way of doing quieres, without having to use views, also its a bit faster, although I've seen people speed up couch by using protocol buffers etc. Now that I havent been following couch for a while the fragmentation in between couch versions, doesn't help when evaluating if I should try it again.

dhimes 15y ago
I find that strange, also. It just seems like, either compact continuously (and don't make me worry about enormous dbs because of hidden files, and the trouble that can happen when it gets too large (> 1/2 disk space, so I understand)), or give easy access to the versions. I'd prefer the first, but from a user perspective (although maybe not a db-designer perspective), either-or makes sense. That's the fallout of eventual concurrency, though.