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

Needs more space efficient row checksums #50

Closed
hermanlee opened this issue Sep 28, 2015 · 2 comments
Closed

Needs more space efficient row checksums #50

hermanlee opened this issue Sep 28, 2015 · 2 comments

Comments

@hermanlee
Copy link
Contributor

Issue by yoshinorim
Monday Jul 27, 2015 at 14:49 GMT
Originally opened as MySQLOnRocksDB#93


Here are sizes of loading LinkBench data with 1.5B max ids.
Without row checksum: 570959236
With row checksum enabled: 705439184

23.6% space increase is too much. This was because current row checksum adds 9 bytes (1B + CRC32 key and CRC32 value) into value for each index entry.

How about doing some optimizations like below?

  • Adding new checksum format using CRC8 instead of CRC32. This makes per row size reduced from 9B to 3B.
  • Adding rocksdb_checksum_row_pct global variable to control how many percentage of rows to be checksummed. For example, by setting to 10, checksum is enabled for only 10% of rows. This reduces checksum space overhead by 90%. This approach may miss some checksum corruptions. But in practice, many more than 10 rows will be affected if there is any corruption bug, so sooner or later it is possible to detect corruption.
@hermanlee
Copy link
Contributor Author

Comment by yoshinorim
Tuesday Aug 04, 2015 at 03:41 GMT


Introducing rocksdb_checksums_pct variable -- https://reviews.facebook.net/D43419

I'll keep this issue opened until we figure out if CRC8|16 are needed.

@gunnarku
Copy link

gunnarku commented Apr 6, 2017

No longer relevant.

@gunnarku gunnarku closed this as completed Apr 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants