Josh, thanks! I will read more about LSM in RocksDB, thanks!
Can I ask last one question) We have a lot of "old" SSD OSDs in the index pool which were deployed before Pacific. In the Pacific we have RocksDB column families. It will be helpful in the case of many tombstones to do resharding of our old OSDs? Do you think It can help without rocksdb_cf_compact_on_deletion? Or, maybe It can help much more with rocksdb_cf_compact_on_deletion? On 18.07.2024, 18:01, "Joshua Baergen" <jbaer...@digitalocean.com <mailto:jbaer...@digitalocean.com>> wrote: > And my question is: we have regular compaction that does some work. Why It > doesn't help with tombstones? > Why only offline compaction can help in our case? Regular compaction will take care of any tombstones in the files that end up being compacted, and compaction, when triggered, may even favor files that have more tombstones in them. However, to my original point, compaction decisions themselves have nothing to do with tombstones. I suggest you read up a bit on rocksdb architecture and log-structured merge trees if you want the details, but the basics are: A tombstone exists until it gets compacted to the bottom-most level. You have 4 levels (plus level 0), so levels 1-3 can have any number of tombstones in them, and there's nothing that guarantees that a given tombstone will get compacted to level 4 with any sort of deadline. (Well, sort of - newer rocksdb, available in Nautilus+ IIRC, has a "TTL" concept set at 30 days by default that ensures no file gets older than 30 days. You can tweak this down to, say, a day or hours, and this effectively introduces an upper bound on most tombstones' lifetime, but also increases compaction traffic substantially. rocksdb_cf_compact_on_deletion is a more intelligent way to achieve a similar effect.) Josh _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io
