On 11/23/19 9:51 AM, Paul Emmerich wrote:
Question: lower alloc sizes seem like a work-around. Would it be better to have an option to store small objects entirely in rocksdb? I've seen a lot of setups that would really benefit from such a feature. It's usually a case of mixed object sizes with a lot of very small (< 10kb) objects and some large objects that unfortunately can't be mapped to different directories/buckets/pools on a higher layer. (I think I did see some pull request that did something like that some time ago?) Paul
There are a couple of PRs that attempt this, including one that Igor wrote a while back. I think there is both potential for reward and risk in this approach. We already are facing some issues with RocksDB not scaling well as the amount of data grows. Potentially with >4K objects this could start adding up very quickly. I think the most recent ideas here have a lot of merit though. If we can allow for a smaller allocation size when the objects have the immutable hint that would give us a win when we are most likely to want/need it. Perhaps also putting the data in the onode for <4K objects might also be worth exploring, but personally I think we'll need to do a lot of testing before we roll that one out into production. For RGW if we could get the allocation size down to 4K that would by itself be a huge win.
Mark _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
