Decoupling local cache function and cache algorithm

[KinderRiven]

Changelog category (leave one):

• Not for changelog (changelog entry is not required)

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

• Resolve previous issues at PR
• Decoupling the caching algorithm and caching function, we implement the caching algorithm based on IFilecachePriority, thus avoiding the modification of FileCache after implementing a new algorithm.
• Currently only LRU algorithm is supported, maybe more cache algorithm in future.

Information about CI checks: https://clickhouse.com/docs/en/development/continuous-integration/

[kssenii]

may be unique_ptr? or it is shared somewhere?

[KinderRiven]

ReadIterator can be unique_ptr. But for WriteIterator, I don't know if it should be set to unique_ptr, because it may be copied with the FileSegment, do we need to invalidate the iterator before copying?

[kssenii]

because it may be copied with the FileSegment, do we need to invalidate the iterator before copying?

but file segment cannot be copied

[KinderRiven]

It looks like this, I tried to modify it, but sometimes we need to use a temporary pointer to keep some code readable, such as the following cases, so I think it may be better to keep it as it is, what do you think?

auto priority_iter = record->second;
priority_iter->use(cache_lock);
result_state = priority_iter->hits() >= enable_cache_hits_threshold ? FileSegment::State::EMPTY : FileSegment::State::SKIP_CACHE;

[kssenii]

but looks like here auto & is possible, then unique_ptr will be ok

[KinderRiven]

I tried to fix it, but I always get an error when compiling involves unordered_map. Maybe there is something wrong with my understanding of uniqueu_ptr :(

[kssenii]

may be not use a pointer at all - just an object? (and in FileSegmentCell put std::optional to iterator).

[KinderRiven]

Sounds feasible, do you mean all ReadIterator and WriteIterator as objects? In this case, there will be more revisions, but I may not have much time to make revisions recently (there is a lot of work to deal with in reality), and I will reconsider the relevant implementation when I have time :).

[kssenii]

do you mean all ReadIterator and WriteIterator as objects

yes

but I may not have much time to make revisions recently (there is a lot of work to deal with in reality), and I will reconsider the relevant implementation when I have time

ok, let's leave it as it is for now

[kssenii]

LGTM
thanks, very good changes