Lindorm identifies historical data that is infrequently accessed as cold data and uses Capacity storage to store the data to reduce storage costs. This topic describes the benefits of Capacity storage and provides sample performance testing results for the feature.
Features
Capacity storage is cost-effective.
The costs of Capacity storage are 20% of the costs of Standard storage.
Capacity storage supports data write operations and ensures that you can read data at each point in time.
Capacity storage is easy to use.
To use Capacity storage to store cold data, set Purchase Capacity Storage to Yes and specify a value for Capacity Storage when you purchase a Lindorm instance. Then, specify that cold data is stored in Capacity storage when you use CREATE TABLE statements to create tables.
Capacity storage can be used to implement hot and cold data separation within a single table.
If you enable the hot and cold data separation feature for a table, Lindorm stores data that is frequently accessed in hot storage with higher data read and write performance, and stores historical data that is infrequently accessed in Capacity storage to reduce storage costs. To separately store hot and cold data in your business, see Overview.
Enable Capacity storage
For information about how to enable Capacity storage for a Lindorm instance, see Enable cold storage.
Performance test
Test environment: In this test, a master node of the ecs.c5.xlarge specification is required. The master node has 4 CPU cores and 8 GB of memory. Four region servers of the ecs.c5.xlarge specification are required. Each region server has 4 CPU cores and 8 GB of memory.
The following table describes the write performance of Capacity storage.
Storage type | avg rt | p99 rt |
Hot storage | 1736 us | 4811 us |
Capacity storage | 1748 us | 5243 us |
In the test, each data row has 10 columns and has 100 bytes of data stored in each column. This means that each row stores 1 KB of data. The system uses 16 parallel threads to write data.
The following table describes the random read performance of Capacity storage.
Storage type | avg rt | p99 rt |
Hot storage | 1704 us | 5923 us |
Capacity storage | 14738 us | 31519 us |
During the performance test, BlockCache is disabled and the system reads data in disks. Each data row has 10 columns and has 100 bytes of data stored in each column. This means that each row stores 1 KB of data. The system uses 8 threads to read 1 KB of data for each request.
The following table describes the range scanning performance of Capacity storage.
Storage type | avg rt | p99 rt |
Hot storage | 6222 us | 20975 us |
Capacity storage | 51134 us | 115967 us |
During the performance test, BlockCache is disabled and the system reads data in disks. Each data row has 10 columns and has 100 bytes of data stored in each column. This means that each row stores 1 KB of data. The system uses 8 threads to read 1 KB of data for each request. The Caching parameter is set to 30.
Limits on the read IOPS of Capacity storage
Capacity storage is applicable to scenarios in which data is frequently written to but is infrequently read from databases. The read IOPS of Capacity storage has the following limits:
The Capacity storage of each Lindorm instance has a token pool. If the number of available tokens in the pool becomes
0
, the read IOPS of Capacity storage is throttled. In this case, the read IOPS of each node can be up to 10.Tokens in the token pool of an instance are automatically generated at a rate that increases with the Capacity storage size of the instance.
When the number of tokens in a token pool reaches the upper limit, tokens stop being generated. The maximum number of tokens in a token pool increases with the Capacity storage size of the instance.
The read IOPS of Capacity storage is not throttled when the token pool still has available tokens. Each I/O operation consumes a token. In this case, the maximum IOPS of a single node is 1,500.
The number of I/O operations performed on Capacity storage by upper-layer Lindorm engines, such as LindormTable or LindormTSDB, depends on how many I/O operations are caused by a read request. For example, a read request may cause multiple I/O operations if it hits the data in multiple data blocks in Capacity storage. Similarly, if a read request hits only data in the cache, no I/O operations are performed on data in Capacity storage. Therefore, the maximum QPS of read operations that can be performed by upper-layer Lindorm engines to access Capacity storage cannot be estimated based on the read IOPS of Capacity storage. We recommend that you estimate the value based on the tokens consumed to access Capacity storage.
Monitoring metrics of Capacity storage
Log on to the Lindorm console. In the upper-left corner of the page, select the region where the instance is deployed. On the Instances page, click the ID of the instance that you want to manage or click Manage in the Actions column corresponding to the instance.
In the left-side navigation pane, click Instance Monitoring to view Underlying Storage Metrics. The following table describes underlying storage metrics.
Metric
Description
Percentage of available token
An instance-level metric. The percentage of available tokens. If the overall available token percentage of an instance is reduced to
0%
, read requests are throttled.DataNode capacity cloud storage IOPS
A node-level metric. Each read IOPS consumes 1 token. A larger value indicates a faster token consumption speed. Due to the difference between the data engine and I/O model, a read request may be repeatedly sent and consume multiple tokens.
Capacity-based cloud storage throttling OPS
A node-level metric. The read OPS of each node that is throttled. A value greater than
0
% indicates that read requests are throttled, which increases the upper-layer read latency.ImportantIf the total available token percentage of an instance is greater than
0
% and the IOPS of a single node is greater than1500
, reads are throttled.
Considerations
Capacity storage is suitable for scenarios in which data is not frequently queried because the IOPS of Capacity storage is limited.
The write throughput of Capacity storage is close to that of Standard storage.
Capacity storage is not suitable for processing a large number of concurrent read requests. An error may occur if Capacity storage is used to process a large number of concurrent read requests.
If you purchase a large capacity of Capacity storage for your Lindorm instance, you can adjust the read IOPS based on your business requirements. For more information, contact technical support.
We recommend that you store no more than 30 TB of cold data on each node. To increase the amount of cold data that can be stored on each node, contact technical support.
If more than 95% of the Capacity storage of an instance is used, data can no longer be written to Capacity storage. Monitor the utilization of the Capacity storage of your instance. For more information, see View the size of cold storage.