Skip to content
This repository has been archived by the owner on Dec 7, 2018. It is now read-only.

Use a compaction filter to eventually remove data after DROP TABLE and DROP INDEX #22

Open
mdcallag opened this issue Dec 2, 2014 · 1 comment
Assignees

Comments

@mdcallag
Copy link

mdcallag commented Dec 2, 2014

How do we do DROP TABLE and DROP INDEX? Using a column family per index makes this easy, just drop the CF but I assume we must support N tables or indexes per column family and need a compaction filter to eventually remove deleted rows along with an option to trigger manual compaction after dropping a large table or index to reclaim disk space faster. Assuming each key for RocksDB has the table/index ID as the prefix do we track IDs for valid objects or IDs for dropped objects that have key-value pairs that must be removed? If we track valid IDs then compaction filters must always do a bloom filter check or hash table lookup to confirm that the IDs in the merged rows are valid. And this can be a big CPU overhead. If we track IDs for dropped objects then we have a new statement management problem. This state must be persisted to survive mysqld restart. We must also figure out when an ID can be removed from this set. But the benefit is that we only need the compaction filter when that set of IDs is not empty. As an optimization we can avoid the compaction filter checks for merges between L0 and L1 because that must be as fast as possible.

@jonahcohen jonahcohen self-assigned this Dec 8, 2014
@mdcallag
Copy link
Author

yoshinorim pushed a commit to yoshinorim/webscalesql-5.6 that referenced this issue Jan 2, 2015
- Specify the right column family when making a rocksdb::Get() call.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants