[Tracking] Breaking changes in V2

[marvin-j97]

API

• [x] Remove FlushMode alias
• [x] Enable bloom feature by default

Data format

• [x] Start journal markers at 1, to prevent the zeroed pre-allocated bytes from matching the start marker tag, causing unnecessary logging of an unfinished batch at journal tail https://github.com/fjall-rs/fjall/issues/53
• [x] #58 PartitionCreateOptions need to be stored to be recovered
• [x] Fix journal length of values https://github.com/fjall-rs/fjall/issues/68
• [x] Set max value length to u32
• [x] Key-Value separation #34
• [x] Correctly track lowest closed instant/snapshot seqno #61

[i18nsite]

I hope that fixed-length key values ​​can be considered when designing the format. Many times, keys and values ​​can be fixed-length (such as u64 id - file hash). I believe that fixed-length fields can be optimized a lot.

I think you can refer to duckdb and consider writing data to the log regularly and compressing it into parquet format. https://duckdb.org/docs/data/parquet/overview.html https://parquet.apache.org

I believe this format does a lot of optimizations for the data

You can use this library to read and write https://docs.rs/parquet/latest/parquet/

[marvin-j97]

I hope that fixed-length key values ​​can be considered when designing the format. Many times, keys and values ​​can be fixed-length (such as u64 id - file hash). I believe that fixed-length fields can be optimized a lot.

I'm not sure if fixed lengths can really be optimized in block based tables. You would at most save 3 byte per K-V pair for a lot of added complexity. It could save you some decent space for huge data sets, but not in block-based tables, and right now I don't plan on adding other types of tables.

compressing it into parquet format.

Parquet is a column-based format with row groups. There is no notion of columns or rows here, so I'm not sure there is an advantage over packed K-V blocks. I have some interest in implementing an alternative block format that is row group based. The current blocks are KVKVKVKV, but an alternative Parquet-esque format could be KKKKVVVV, which would allow for better compression, depending on the values.