Does TiDB have a buffer pool similar to MySQL for caching data pages?

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: TiDB 中有类似 MySQL 的 buffer pool 用于缓存数据页吗?

| username: KaiNiao

【TiDB Usage Environment】Testing
【TiDB Version】6.5.0
【Reproduction Path】RocksDB 简介 | PingCAP 文档中心
【Encountered Problem: Phenomenon and Impact】

The document shows:
To improve read performance and reduce disk reads, RocksDB splits files stored on disk into blocks of a certain size (default is 64KB). When reading a block, it first checks the BlockCache in memory to see if the block data exists. If it does, it can be read directly from memory without accessing the disk.

BlockCache eliminates infrequently accessed data according to the LRU algorithm. TiKV by default uses 45% of the total system memory for BlockCache.

Questions:

  1. Can the BlockCache in memory be understood as MySQL’s buffer pool?
  2. When data is written, does it not update the BlockCache and then generate dirty pages?

【Resource Configuration】
【Attachments: Screenshots/Logs/Monitoring】

| username: hey-hoho | Original post link

Looking at this picture, it’s very clear, similar to MySQL’s buffer pool.

| username: 海石花47 | Original post link

In TiDB, there is a membuffer cache pool where you can flush infrequently updated small table data, and then queries will use the cache.

| username: KaiNiao | Original post link

Thank you, expert. So when data is written, will it also update the BlockCache and generate dirty pages?

| username: KaiNiao | Original post link

Okay, thank you.

| username: hey-hoho | Original post link

When writing, it will not write to the block cache.

| username: KaiNiao | Original post link

Okay :ok_hand:

| username: TiDBer_jYQINSnf | Original post link

The write path is:
WAL is written to disk first, then memtable is written, and that’s it.
There is a background thread monitoring the memtable. When the memtable size exceeds the threshold, it switches to an immutable memtable.
Then, when the number of immutable memtables exceeds the limit, it flushes to disk.

The read path is:
Check if the data exists in the memtable. If not, check the block cache. If it still doesn’t exist, read from the disk and update the block cache with the data.

From this, it can be seen that writes do not evict the block cache. The block cache only has one entry point, which is when reading from the file and not finding the data.

However, writes will evict the memtable, pushing the previously written data to the disk. So, if the data written needs to be read immediately, it can be retrieved from the memtable. If it has been a while, the data will have been flushed to disk and will need to be read again to be loaded into the block cache.

| username: KaiNiao | Original post link

Thank you, boss!

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.