2.2x lower than redb and sled？

[lixiaoyong12]

Question

The bench test case is run in the Windows 10（x86,intel i7） environment. The TONBO performance in all scenarios is not higher than that in redb and sled (no tests are performed in rocksdb). How to set the TONBO performance to 2.2 times on the official website?

tonbo: Bulk loaded 10000 items in 201807ms
tonbo: Wrote 10000 individual items in 204077ms
tonbo: Wrote 10000 individual items (4 threads) in 208614ms
tonbo: Wrote 10000 individual items (8 threads) in 206650ms
tonbo: Wrote 100 x 100 items in 203021ms
tonbo: Wrote 100 x 100 items (4 threads) in 206750ms
tonbo: Wrote 100 x 100 items (8 threads) in 202160ms
tonbo: Random range read 400000 elements in 119334ms
tonbo: Random range read 400000 elements in 118964ms
tonbo: Random range projection read 400000 elements in 29907ms
tonbo: Random range projection read 400000 elements in 29854ms
tonbo: Random range projection reads (4 threads) 400000 elements in 27135ms
tonbo: Random range projection reads (8 threads) 400000 elements in 27110ms
tonbo: Random range projection reads (16 threads) 400000 elements in 25959ms
tonbo: Random range projection reads (32 threads) 400000 elements in 26283ms
tonbo: Removed 5000 items in 100255ms
redb: Bulk loaded 10000 items in 206787ms
redb: Wrote 10000 individual items in 223423ms
redb: Wrote 10000 individual items (4 threads) in 219312ms
redb: Wrote 10000 individual items (8 threads) in 219379ms
redb: Wrote 100 x 100 items in 207569ms
redb: Wrote 100 x 100 items (4 threads) in 207385ms
redb: Wrote 100 x 100 items (8 threads) in 199280ms
redb: Random range read 400000 elements in 9646ms
redb: Random range read 400000 elements in 8733ms
redb: Random range projection read 400000 elements in 8669ms
redb: Random range projection read 400000 elements in 8661ms
redb: Random range projection reads (4 threads) 400000 elements in 8661ms
redb: Random range projection reads (8 threads) 400000 elements in 8657ms
redb: Random range projection reads (16 threads) 400000 elements in 8326ms
redb: Random range projection reads (32 threads) 400000 elements in 8349ms
redb: Removed 5000 items in 100800ms
sled: Bulk loaded 10000 items in 205312ms
sled: Wrote 10000 individual items in 221942ms
sled: Wrote 10000 individual items (4 threads) in 207565ms
sled: Wrote 10000 individual items (8 threads) in 207317ms
sled: Wrote 100 x 100 items in 204311ms
sled: Wrote 100 x 100 items (4 threads) in 201806ms
sled: Wrote 100 x 100 items (8 threads) in 193332ms
sled: Random range read 400000 elements in 9731ms
sled: Random range read 400000 elements in 7531ms
sled: Random range projection read 400000 elements in 7432ms
sled: Random range projection read 400000 elements in 7431ms
sled: Random range projection reads (4 threads) 400000 elements in 7445ms
sled: Random range projection reads (8 threads) 400000 elements in 7419ms
sled: Random range projection reads (16 threads) 400000 elements in 7137ms
sled: Random range projection reads (32 threads) 400000 elements in 7160ms
sled: Removed 5000 items in 100604ms

Before asking a question, make sure you have:

• Reviewed relevant Rust information: Google your error messages and look at official docs.
• Searched open and closed GitHub issues

[ethe]

Tonbo is unstable and has regression in latest commits, according to our measurement, it is caused by the implementation of parquet, we are working on reproducable benchmarks, please follow us to get the latest info.

[KKould]

Thank you for your feedback.

The benchmark code described in the issue has fallen behind. You can try the latest code. Our current main comparison object is rocksdb (the current write performance is the same as rocksdb. In some cases, the projection scan will be faster than rocksdb because projection pushdown), please compare with rocksdb after updating

[lixiaoyong12]

How to fix this mistake

[KKould]

How to fix this mistake

We have not encountered such a problem (macos & window), please go to https://github.com/rust-rocksdb/rust-rocksdb to see if there are related issues

[lixiaoyong12]

Thank you for your feedback.

The benchmark code described in the issue has fallen behind. You can try the latest code. Our current main comparison object is rocksdb (the current write performance is the same as rocksdb. In some cases, the projection scan will be faster than rocksdb because projection pushdown), please compare with rocksdb after updating
How is data generated in read_bench?

[lixiaoyong12]

@KKould I am very interested in this project. Do you have any documents designed for me to quickly understand and participate in this project?

[KKould]

Thank you for your feedback.
The benchmark code described in the issue has fallen behind. You can try the latest code. Our current main comparison object is rocksdb (the current write performance is the same as rocksdb. In some cases, the projection scan will be faster than rocksdb because projection pushdown), please compare with rocksdb after updating
How is data generated in read_bench?

This tbl file is generated by tpch's dbgen, we use sf 1000 as the factor for testing

[KKould]

@KKould I am very interested in this project. Do you have any documents designed for me to quickly understand and participate in this project?

@lixiaoyong12 Unfortunately, tonbo is currently in its early stages and we have not invested much energy in documentation. I am very happy to discuss the technical details of Tonbo with you. You are welcome to come to discord to ask questions.

If you want to get involved, welcome to see what issues are within your capabilities

[lixiaoyong12]

About WASM Support Design

[lixiaoyong12]

Please send a verification result.

[ethe]

We are working on parquet lru cache #193 and #215 , performance would be back to expectation if it is merged, thanks for your feedback! WASM is a too complicated topic, we choose implementing it by ourselves, you are ablt to checkout #118 to get more info.