Comparator mismatch - does not match existing comparator

420 views
Skip to first unread message

kenjic...@gmail.com

unread,
Jan 12, 2021, 6:37:33 AM1/12/21
to rocksdb
Hi all,

I use uint64_t as keys (binary). But rocksdb doesn't sort my key in order, so I created my own comparator for binary uint64. For the first time, I could create the db and write some key/value, but the 2nd time I re-open the DB, it always failed with an error saying:

Invalid argument: StoreComparator: does not match existing comparator leveldb.BytewiseComparator

I don't understand why, because I set my own comparator when I open/create/write to the DB. Why is the comparator still seems to be BytewiseComparator?

BTW, I don't know how to create a new DB with column family the first time. Do I need to open with "create_if_exist" to create a db without column family, then ListColumnFamilies to get all the families, then re-open it with a list of families?

Can someone help me please?

Thanks,
Kenji Chan

kenjic...@gmail.com

unread,
Jan 12, 2021, 6:39:30 AM1/12/21
to rocksdb
sorry, it should have been create_if_missing, not create_if_exist.

Mark Rambacher

unread,
Jan 12, 2021, 9:40:40 AM1/12/21
to kenjic...@gmail.com, rocksdb
What version of RocksDB are you using?

I changed the simple_example to use a custom Uint64Comparator and am not seeing this issue.

The one thing I am seeing that is a bit unexpected is that the key slices coming into my Comparator are not 8 bytes long but are instead 16-bytes.  I believe this is because the slices are probably containing the Internal key data (and not just the user key).

As for your question on creating a ColumnFamily, are you asking how to create/add the non-default Column Family if one does not exist, or are you asking how to set up the default Column Family?

/ Mark

--
You received this message because you are subscribed to the Google Groups "rocksdb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rocksdb+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rocksdb/56f799e9-985e-40eb-8080-fe0c89aff7adn%40googlegroups.com.

kenjic...@gmail.com

unread,
Jan 12, 2021, 12:04:25 PM1/12/21
to rocksdb
I'm using v6.15.2.

8 bytes become 16, I haven't seen this in my case.

this is my comparator:
Screenshot 2021-01-13 at 12.04.02 AM.png

I expect the db may or may not exist at all. I was hoping I could just open the db and iterate each column family's data.
But it turns out much more complicated than I thought. I'm not sure if there is another way to do it. But this is how I do it for now.

Below:
  1. Try to get a list of column families.
  2. if it fails, then I guess the db doesn't exist, so I open it with create_if_missing, then close it
  3. Try to get a list again.
  4. Now I have the list, so I prepare the descriptor vector needed to open the db
  5. If the list is empty...I can't open it..., but I know there is always a default one
  6. then I have a map< column name, handle >, which I later use to write data into each column family
I know it's over complicated, but I don't know any better way.

Screenshot 2021-01-13 at 12.08.52 AM.png

I keep a map to cf handles:
Screenshot 2021-01-13 at 12.57.13 AM.png

To write data:
  1. if the name is not found in the column family map, create a new column family
  2. use the newly created or existing column family handle to write data, where key is timestamp
I'm confused in line 131, if I need to set my comparator again or not.
Screenshot 2021-01-13 at 12.58.56 AM.png

There must be something wrong, but I don't know what/why.
Do you have any idea? Mark

Thanks,
Kenji

kenjic...@gmail.com

unread,
Jan 12, 2021, 12:45:39 PM1/12/21
to rocksdb
UPDATE:
I know why I got the comparator mismatch, that's because of line 131, I didn't set my comparator when I write.
But if I do set that, I got another error, every 2nd time I write I got the error below:

Corruption: two consecutive TryAgain in WriteBatch handler; this is either a software bug or data corruption.

I have no idea what it is.

Kenji
Reply all
Reply to author
Forward
0 new messages