All Products
Search
Document Center

Lindorm:Overview

Last Updated:Oct 16, 2024

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

Note

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

Note

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

Note

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

  1. 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.

  2. 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.

    Important

    If the total available token percentage of an instance is greater than 0% and the IOPS of a single node is greater than 1500, 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.