fix(streaming): use xxhash64 for hash key in cache

[BugenZhao]

Signed-off-by: Bugen Zhao i@bugenzhao.comI hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Resolve the long-standing issue of #5579. Also, add a generic for HashCode to avoid misusing between different hashers.

We may perform some benchmarks to see whether...

• xxHash is fast enough,
• and there are frequent key conflicts before (cc @kwannoel)

This PR does not introduce breaking changes, as this only affects the hash code for hash maps and the hasher of hash-shuffle or consistent hash is still Crc32.

Close #5579.

Checklist For Contributors

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• I have demonstrated that backward compatibility is not broken by breaking changes and created issues to track deprecated features to be removed in the future. (Please refer to the issue)
• All checks passed in ./risedev check (or alias, ./risedev c)

Checklist For Reviewers

• I have requested macro/micro-benchmarks as this PR can affect performance substantially, and the results are shown.

Documentation

• My PR DOES NOT contain user-facing changes.

Click here for Documentation

Types of user-facing changes

Please keep the types that apply to your changes, and remove the others.

• Installation and deployment
• Connector (sources & sinks)
• SQL commands, functions, and operators
• RisingWave cluster configuration changes
• Other (please specify in the release note below)

Release note

[kwannoel]

Running q17 bench to see performance, give me a while

[BugenZhao]

Running q17 bench to see performance, give me a while

Thanks for your being so responsive! 😍

[st1page]

Running q17 bench to see performance, give me a while

Thanks for your being so responsive! heart_eyes

+1 😍

[kwannoel]

Slight improvement from q17 micro bench (may be just noise 😆 )

cargo bench
Q17/benchmark_hash_agg  time:   [7.1066 s 7.1511 s 7.2039 s]
                        change: [-3.4729% -2.6952% -1.8194%] (p = 0.00 < 0.05)
                        Performance has improved.

Will try out q17 nexmark bench later, benchmark instance still compiling the code 😅

[kwannoel]

and there are frequent key conflicts before (cc @kwannoel)

Not too sure if frequent key conflicts OR it's just many duplicate keys. I'm guessing it may be the latter, and if so there's not much we can do about it by changing the hash type.

Need to verify kube-bench workload to know for sure. Let me open an issue to track this.

[codecov]

Codecov Report

Merging #9163 (e5ee601) into main (9bf890a) will decrease coverage by 0.02%.
The diff coverage is 70.00%.

@@            Coverage Diff             @@
##             main    #9163      +/-   ##
==========================================
- Coverage   70.86%   70.85%   -0.02%     
==========================================
  Files        1200     1200              
  Lines      199974   199986      +12     
==========================================
- Hits       141711   141696      -15     
- Misses      58263    58290      +27     

Flag	Coverage Δ
rust	70.85% <70.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/batch/src/task/hash_shuffle_channel.rs	0.00% <0.00%> (ø)
src/common/src/hash/key.rs	78.43% <64.00%> (-0.68%)	⬇️
src/common/src/row/mod.rs	67.59% <66.66%> (ø)
src/common/src/util/hash_util.rs	85.71% <75.00%> (-4.29%)	⬇️
src/batch/src/executor/hash_agg.rs	90.98% <100.00%> (ø)
src/common/src/array/data_chunk.rs	90.73% <100.00%> (ø)
src/common/src/hash/consistent_hash/vnode.rs	91.35% <100.00%> (ø)
src/common/src/row/owned_row.rs	87.68% <100.00%> (ø)

... and 9 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[kwannoel]

Looks good, seems like 20% improvement

[kwannoel]

Let me run it for longer and see how it goes

[kwannoel]

Okay LGTM it is done processing.

[kwannoel]

I will run a longer bench tmr with 1B records

[lmatz]

Hash Joins should also improve this massive I suppose

[kwannoel]

1B:

[lmatz]

impressive improvement