Diagram of the storage allocation strategy of tcapsusdb



There are many ways to save data. The most direct way is to build a data structure in memory to save data. For example, with a list, every time a piece of data is received, a record is appended to the list.

This scheme is very simple and has good performance, but the problem is that the data is stored in the memory. Once the server is shut down or restarted, the data will be lost permanently.

In order to solve the problem of data loss, data can be persisted in non-volatile storage media (such as hard disk). You can use the file on disk to add a line to the file whenever you receive a piece of data. This is a solution for persistent storage of data, but what if the disk is damaged? Raid is a single machine redundant storage scheme. What if the host is damaged?

Network storage is a solution, through the software layer for storage copy replication. It seems that we can solve the problem of data security, but can we ensure the consistency between replicas in the process of storage replica replication?

The developers of tcapsusdb have considered these storage problems. In this issue of the knowledge base, tcapsusdb will introduce the storage allocation strategy of tcapsusdb, and we will introduce the data reading and writing logic in the next issue of the knowledge base.

Basic strategy of storage space allocation

  • Tcapsusdb takes precedence over the first 1g of the data file. The reason is that when the storage engine starts up, the first 1g space of the data file will be mapped to the memory through MMAP, so the access efficiency is high, and the data in the remaining space will be directly accessed by docking with the file IO;
  • The key of data has more right to use the first 1g space than the value of data. The reason is that the access frequency of key is usually higher than that of value. When there are not enough free blocks allocated to key in the current 1g space, the free blocks allocated to value in the first 1g space will be transferred to key;
  • The keys of all data should be stored together as far as possible. This is because we have many key traversal scenarios (such as data migration). Putting keys together can speed up the traversal process to a certain extent and reduce disk IO;
  • The search strategy of free block is best fit, that is to find the smallest free block to meet the demand. The purpose is to make the data exist in the same block as much as possible and avoid data splitting.

The detailed allocation process of storage space is shown in the figure below (the figure below is divided into two parts, and the two pictures are linked by the “try to allocate from file space” node in the dotted box)

Diagram of the storage allocation strategy of tcapsusdb

< center > storage space detailed allocation process diagram < Center / >

Diagram of the storage allocation strategy of tcapsusdb

< center > allocate graph from file space < Center / >

Consideration of strategy design

According to the space allocation strategy, the storage engine allocates the storage space of the data value first, writes the data value part, allocates the storage space of the data key, and writes the data key part. There are two reasons for this order

  • The header of the data key needs to record the storage address of the value it points to. First, allocate the storage space of the value, get the storage address header of the value, and then write the key;
  • The data access entry is key. In this order, if the key is successfully written, we can basically think that the value is also successfully written, which can reduce the data inconsistency.


We have learned about the storage allocation strategy of tcapsusdb, and we will uncover more special secrets of tcapsusdb design in the future.