What is the relationship between Compaction and Garbage Collection (GC)?

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

Original topic: Compaction和Garbage Collection (GC) 是什么关系?

| username: 江湖故人

The two seem somewhat similar, but the triggering conditions are different.

| username: forever | Original post link

I understand, GC is a data behavior, Compaction is a TiKV behavior, and data will only be Compacted after GC.

| username: xfworld | Original post link

It’s not similar; the difference is significant.

GC, for TiDB, TiKV, and TiFlash, all have a recycling mechanism that releases memory fragments during the recycling and reuse process.

Compact or Compaction is only for data nodes, where data is compressed or discarded according to different data markers.

| username: 哈喽沃德 | Original post link

Compaction and Garbage Collection are two independent but interrelated concepts. Compaction addresses the issue of memory fragmentation, improving memory utilization; whereas Garbage Collection is responsible for reclaiming memory objects that are no longer in use, ensuring the automation and effectiveness of memory management.

| username: 江湖故人 | Original post link

The GC mentioned here is related to MVCC, reducing the outdated historical versions of keys in TiKV.

| username: 江湖故人 | Original post link

I understand that GC + Compaction in TiDB is equivalent to VACUUM in PostgreSQL :thinking:

| username: TiDBer_jYQINSnf | Original post link

The CRUD operations in TiDB ultimately reflect the handling of a key in TiKV. By adding a timestamp suffix to the key, MVCC is implemented. TiDB’s GC deletes expired versions. This means that a piece of data may have several versions like key1_ver1, key1_ver2, key1_ver3, etc. Once key1_ver1 has passed the GC time and is no longer used by any transactions, it needs to be deleted. This is the job of GC.

TiKV uses RocksDB at the underlying level. So, the deletion of a key mentioned above is essentially a delete(key1_ver1) operation. This marks the end of the GC process.

As for compaction, it needs to be understood from the perspective of RocksDB’s LSM tree. For RocksDB, all modifications are just appends. For example, the above operations reflected in RocksDB would result in several records:
deletekey(key1_ver1)
putkey(key1_ver3)
putkey(key1_ver2)
putkey(key1_ver1)
From bottom to top, the time is ordered from old to new.

In this way, key1_ver1 in RocksDB is actually a wasted key and cannot be read. When there are many such deleted keys, a lot of disk space will be wasted. Therefore, compaction is needed. After executing compaction, the data becomes:
putkey(key1_ver3)
putkey(key1_ver2)

This reduces disk space usage.

| username: zhanggame1 | Original post link

When we talk about GC in TiDB, it generally does not refer to memory GC. Instead, it refers to the cleanup of old data in TiKV that has been deleted, dropped, truncated, or updated, and has exceeded the time specified by the parameter tidb_gc_life_time. This old data is marked as cleaned up, and the space can be reused for writing new data.

| username: zhanggame1 | Original post link

Compaction is a concept in RocksDB, the underlying database of TiKV. It can be understood as data organization, compression, sorting, etc.

| username: h5n1 | Original post link

GC: The concept in TiDB involves cleaning up MVCC data before the GC safepoint time and cleaning up SST (drop, truncate). For data cleanup, it adds a delete marker in RocksDB, and the actual cleanup happens during RocksDB compaction.

Compaction: The concept in RocksDB involves merging written data layer by layer while cleaning up data marked as deleted.

TiKV has a GC in compaction filter feature, which performs GC operations through interface calls during RocksDB compaction.

| username: tidb菜鸟一只 | Original post link

A diagram can help understand this better…
Deleting is equivalent to marking the data as deleted, GC (Garbage Collection) will actually remove the deleted data, and compact will release the space of the deleted data. That’s roughly it…

| username: wangccsy | Original post link

Got it, learning.

| username: dba远航 | Original post link

One is data cleaning, and the other is data merging.

| username: Jellybean | Original post link

Simply put, GC is a logical action that mainly marks data for deletion; Compaction is a behavior at the underlying RocksDB level, merging SST files and transferring them to the next level to free up space.

| username: 江湖故人 | Original post link

Your explanation is clear and concise.

| username: 江湖故人 | Original post link

So GC actually doesn’t have much effect; it’s just a preparation for Compaction. Compaction is what can reduce read amplification during full table scans.

| username: zhanggame1 | Original post link

You can check this document reply key_skipped_count comes from where - :ringer_planet: TiDB Technical Issues - TiDB Q&A Community (asktug.com)

| username: 江湖故人 | Original post link

I really want to dump the raw data to take a look. The markers for truncate and delete should be different.


Will TiDB immediately release space after deleting data?

| username: zhanggame1 | Original post link

The truncate operation calls the DeleteRange interface of RocksDB, which can batch process consecutive keys, making it very fast. For the data storage part of TiDB, you need to refer to the relevant RocksDB documentation.

| username: 江湖故人 | Original post link

Okay, thank you.