Track range load and split hotspots

[bootjp]

Summary

• track access load for each key range
• automatically split hot ranges when access counts exceed threshold
• expose stats and tests for load tracking and hotspot splitting

Testing

• go test ./...

---

https://chatgpt.com/codex/tasks/task_e_68b1f46a2f608324ab808e6b46373eb5

[gemini-code-assist]

Summary of Changes

Hello @bootjp, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the Engine component by introducing mechanisms for tracking key range access patterns and dynamically splitting 'hot' ranges. This improvement aims to optimize data distribution and performance by preventing single ranges from becoming bottlenecks under high access loads, thereby improving overall system responsiveness and scalability.

Highlights

• Hotspot Detection: Introduced a 'Load' counter to the 'Route' struct to track access frequency for each key range, enabling the identification of 'hot' ranges.
• Automatic Range Splitting: Implemented logic to automatically split key ranges when their access load exceeds a predefined 'hotspotThreshold'. This helps in distributing load more evenly across the system.
• Configurable Engine Initialization: Modified the 'Engine' constructor to allow setting a 'hotspotThreshold' at initialization, enabling or disabling automatic splitting based on configuration.
• Exposed Statistics and Testing: Added a 'Stats' method to the 'Engine' to expose current range loads and included new test cases to validate the load tracking and hotspot splitting functionalities.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces valuable functionality for tracking range load and automatically splitting hotspots. The implementation is clear and includes relevant tests. My review provides suggestions to enhance performance, refine the splitting logic, and improve test coverage. Specifically, I've pointed out a potential performance bottleneck in RecordAccess due to its locking strategy, suggested improvements for load distribution and slice manipulation in splitRange, and recommended making the hotspot splitting test more comprehensive.

[gemini-code-assist]

The use of a full e.mu.Lock() in RecordAccess serializes all access recordings, which could become a performance bottleneck under high contention, as this is likely a hot path.

For better concurrency, you could consider a more fine-grained locking approach. For instance, you could use atomic.AddUint64 to increment the Load counter under a read lock (e.mu.RLock). The range splitting, which is a less frequent and more expensive operation, could then acquire a full write lock (e.mu.Lock()) only when the threshold is met.

This change would increase complexity, as you'd need to carefully handle the race condition where a range is split by another goroutine between releasing the read lock and acquiring the write lock (e.g., by re-checking the condition after acquiring the write lock). However, it would significantly improve the scalability of access tracking.

[gemini-code-assist]

This test correctly verifies that a split occurs, but it could be more robust. It would be beneficial to add more specific assertions to check the properties of the newly created ranges.

I recommend adding checks for:

1. The exact Start and End keys of the new ranges to ensure the midpoint logic is working as expected.
2. The Load of the new ranges. Based on the current implementation, they should be 0. If you adopt my suggestion to distribute load, this test should be updated to check for the distributed values (e.g., 1 and 1 in this case).

if len(stats) != 2 {
	t.Fatalf("expected 2 routes after split, got %d", len(stats))
}

// Check that the new ranges are correct.
midKey := []byte("a\x00")
if !bytes.Equal(stats[0].Start, []byte("a")) || !bytes.Equal(stats[0].End, midKey) {
	t.Errorf("expected first range to be [a, a\\x00), got [%q, %q]", stats[0].Start, stats[0].End)
}
if !bytes.Equal(stats[1].Start, midKey) || !bytes.Equal(stats[1].End, []byte("c")) {
	t.Errorf("expected second range to be [a\\x00, c), got [%q, %q]", stats[1].Start, stats[1].End)
}

// Check that load is reset after split.
if stats[0].Load != 0 || stats[1].Load != 0 {
	t.Errorf("expected loads to be reset to 0, got %d, %d", stats[0].Load, stats[1].Load)
}

[github-actions]

🚫 [golangci] _{reported by reviewdog 🐶}
File is not properly formatted (gci)

[github-actions]

🚫 [golangci] _{reported by reviewdog 🐶}
Magic number: 2, in detected (mnd)