Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom Comparators #10

Closed
dgrnbrg opened this issue Jul 11, 2015 · 2 comments
Closed

Custom Comparators #10

dgrnbrg opened this issue Jul 11, 2015 · 2 comments

Comments

@dgrnbrg
Copy link
Contributor

dgrnbrg commented Jul 11, 2015

Hello, I'm interested in custom comparator support. I would like to be able to specify keys as lists of sorted keys. This way, I could do prefix lookups on multiple levels of variable-length prefixes. This indexing scheme is critical for building EAV database indices like Datomic (a functional DB) use.

@spacejam
Copy link
Member

Added: #13

I'm a bit unfamiliar with the comparator, could you modify the test in comparator.rs so that it covers your desired use-case? Bonus points for a short usage example in the readme with an example of how the comparator can assist with this interesting problem.

@dgrnbrg
Copy link
Contributor Author

dgrnbrg commented Jul 13, 2015

Basically, I'd like to initialize the DB w/ a "serialization config", so that you can have a designated pair of K & V types with custom-defined serialization & comparator, so that it's possible to use RocksDB with crazy types. For instance, I've often wanted keys which are actually a list of many variable-length lexographically or ordinally ordered elements. For instance, a key of the form [hostname time] would allow one DB to answers queries about the hostname and about the hostname at a specific time, assuming that you sort time in reverse order (since the value at the hostname itself would be the latest time). But since hostname is variable length, this is trickier.

Another thing I'd like is to store multiple distinct keyspaces in the same RocksDB, in order to take advantage of the atomic writes to a single db and key multiple indices on the in sync.

I will write some code for this in a bit--I want to figure out the iterator first :)

BusyJay pushed a commit to BusyJay/rust-rocksdb that referenced this issue May 9, 2016
…-opt

option: add max_bytes_for_level_base option
BusyJay pushed a commit to BusyJay/rust-rocksdb that referenced this issue Jul 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants