3 ms·

Thanks; #1 can be a problem for large collections...due to the extra space. I think I've seen some pre-rolled abstraction layers for this, but never used a open

by ukd1 14y ago

Thanks; #1 can be a problem for large collections...due to the extra space. I think I've seen some pre-rolled abstraction layers for this, but never used a open-source one myself. #2 - usually the journal should be pretty quick to allocate - I've not experienced this problem directly myself. I'll add some extra bits to the bottom of the post with your notes.

scubaguy 14y ago
Spring Data - MongoDB's ORM provides a nice way of doing this.
- alpb 14y ago
  I prefer Morphia as ORM for MongoDB. Actively developed and maintained, less seems like enterprise http://code.google.com/p/morphia/ http://code.google.com/p/morphia/
rogerbinns 14y ago
There is a ticket for compression of both keys and values https://jira.mongodb.org/browse/SERVER-164 https://jira.mongodb.org/browse/SERVER-164 The Mongo team seem somewhat reluctant to implement it.
- codewright 14y ago
  It's probably not a clear win in most use-cases.
  - rogerbinns 14y ago
    Reducing the working set is a big win. Mongo's behaviour when the working set is larger than RAM is really bad- https://jira.mongodb.org/browse/SERVER-574 https://jira.mongodb.org/browse/SERVER-574 Compression could have drawbacks on documents that get updated frequently. But it will be extremely useful on documents that get created and rarely/never change, coincidentally what I mostly have. It would also greatly help if keys are compressed or indexed in some way since it could be done transparently. You may recall the Mongo team being reluctant to make the database function well in single server setups, but they did address that with journalling.
- ukd1 14y ago
  I'm not sure if they are still doing it, but they used to work on the highest voted stuff as a priority; so if you want a feature, vote. Also, I'm working on Snappy compression with Mongo (it's already used for the journal), however it's not currently stable and work is sporadic due to my startup.

by ukd1 14y ago

scubaguy 14y ago

Spring Data - MongoDB's ORM provides a nice way of doing this.

alpb 14y ago
I prefer Morphia as ORM for MongoDB. Actively developed and maintained, less seems like enterprise http://code.google.com/p/morphia/ http://code.google.com/p/morphia/

rogerbinns 14y ago

There is a ticket for compression of both keys and values https://jira.mongodb.org/browse/SERVER-164 https://jira.mongodb.org/browse/SERVER-164 The Mongo team seem somewhat reluctant to implement it.

codewright 14y ago
It's probably not a clear win in most use-cases.
- rogerbinns 14y ago
  Reducing the working set is a big win. Mongo's behaviour when the working set is larger than RAM is really bad- https://jira.mongodb.org/browse/SERVER-574 https://jira.mongodb.org/browse/SERVER-574 Compression could have drawbacks on documents that get updated frequently. But it will be extremely useful on documents that get created and rarely/never change, coincidentally what I mostly have. It would also greatly help if keys are compressed or indexed in some way since it could be done transparently. You may recall the Mongo team being reluctant to make the database function well in single server setups, but they did address that with journalling.
ukd1 14y ago
I'm not sure if they are still doing it, but they used to work on the highest voted stuff as a priority; so if you want a feature, vote. Also, I'm working on Snappy compression with Mongo (it's already used for the journal), however it's not currently stable and work is sporadic due to my startup.