You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@bookkeeper.apache.org by GitBox <gi...@apache.org> on 2018/04/27 10:57:00 UTC

[GitHub] ArvinDevel opened a new issue #1370: RocksDB compaction relative

ArvinDevel opened a new issue #1370: RocksDB compaction relative
URL: https://github.com/apache/bookkeeper/issues/1370
 
 
   
   **QUESTION**
   When we use RocksDB as storage for index info, we treat 'ledgerId + entryId' as key in RocksDB. Imagine one case, we have too much ledgers, after put one ledger's index into RocksDB, we put another ledger's index info to it, then RocksDB has to sort these data according to  'ledgerId + entryId' key, these sorting and following compaction will cause some overhead.  As @sijie suggested, this [compaction strategy ](https://github.com/facebook/rocksdb/blob/master/include/rocksdb/utilities/table_properties_collectors.h#L23-L27) in RocksDB is helpful, although we haven't active this by default.  If I‘m not mistaken, @merlimat introduced RocksDB as a storage for index, so call for your analysis too. 
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services