Data Expiration

TcaplusDB supports table-level data expiration and record-level data expiration

1. Table-level Data Expiration

Table-level data expiration applies to all data in a table. The system periodically starts the data expiration task, traverses the data in the table, and sorts out the expired data.

Whether the data needs to be deleted depends on the following standard: current system time - Current system time - Last modification time of data > Set TTL.

Each time data is updated (insert, modify, replace), the system updates the last modification time of the data to the current system time.

The actual deleting time of the expired data depends on the scheduling time of the system deleting task. After the data expires, it may still exist in the database and can be queried.

It only needs to modify the table configuration through the TcaplusDB OMS console or the WebService API to use table-level data expiration without the need for app code modification.

1.1. Application Scenarios

Table-level data expiration scenarios should meet the following conditions:

  1. All data in the table follow the same data expiration rules.

  2. It can tolerate the situation that data can be queried in a short time after expiration.

For example, a historical battle table in the game field, which may only need to save the last 30 days of battles, might consider using table-level expiration.

1.2. Instructions

Users can set table-level data expiration strategies through the TcaplusDB OMS console or the WebService API. Please refer to:

  1. Set a table-level data expiration strategy through the TcaplusDB OMS console;

  2. Set a table-level data expiration strategy through the TcaplusDB WebService API.

2. Record-level Data Expiration

TcaplusDB supports setting the Time To Live (TTL) for a single piece of data in a Generic table (List tables are not supported at present). The TTL is set explicitly by the app through a request, which is flexible.

After the TTL is set, the system returns an error code when a user attempts to access expired data to ensure that the user does not access expired data.

There are two ways to expire record-level data:

  1. Passive data expiration. The actual deleting time of expired data depends on the next access time of the data. In other words, the data deletion is triggered by the user's request, which requires the cooperation of app code. App code needs to initiate access to expired data to trigger data deletion in time.

  2. Active data expiration. The system periodically starts the data expiration task, traverses the data in the table, and sorts out the expired data.

2.1. Application Scenarios

The following scenarios can consider using record-level data expiration:

  1. A scenario that needs to ensure that users will not access expired data;

  2. A scenario where the data in the table may have different requirements for expiration strategies.

2.2. Instructions

For details about how to query and set the TTL interface for a single piece of data, see the descriptions of SDKS and API, TcaplusDB SDK & API.

Note: If table level data elimination is set while calling the TTL interface to set certain keys to never expire and eliminate (Record-level Data Expiration), it may actually eliminate records that are set to never expire by the TTL interface

results matching ""

    No results matching ""