Capacity storage

更新时间:
复制 MD 格式

Lindorm uses capacity storage as a cold storage medium for infrequently accessed historical data (cold data), reducing storage costs.

Features

  • Low storage costs.

    Costs only 20% of standard storage.

  • Supports data writes with continuous read access.

  • Easy to use.

    Select capacity storage and specify the storage space when purchasing a Lindorm instance, then use CREATE TABLE statements to store cold data.

  • Supports hot and cold data separation within a single table.

    Hot data stays in high-performance storage while infrequently accessed data moves to capacity storage automatically. Hot and cold data separation.

Enable capacity storage

Enable capacity storage.

Capacity storage performance benchmarks

Test environment: one master node (ecs.c5.xlarge, 4-core 8 GB) and four RegionServer nodes (ecs.c5.xlarge, 4-core 8 GB).

Write performance:

Storage type

Avg rt

P99 rt

hot storage

1736 us

4811 us

capacity storage

1748 us

5243 us

Note

10 columns per record, 100 B each (1 KB total row size). 16 write threads.

Random read (Get) performance:

Storage type

Avg rt

P99 rt

hot storage

1704 us

5923 us

capacity storage

14738 us

31519 us

Note

BlockCache disabled. 10 columns per record, 100 B each (1 KB total). 8 read threads, 1 KB per request.

Range scan performance:

Storage type

Avg rt

P99 rt

hot storage

6222 us

20975 us

capacity storage

51134 us

115967 us

Note

BlockCache disabled. 10 columns per record, 100 B each (1 KB total). 8 read threads, 1 KB per request. The Caching parameter is set to 30.

Capacity storage performance guarantees

Lindorm guarantees read and write bandwidth based on purchased capacity storage. The system may burst beyond guaranteed bandwidth when the storage pool has idle capacity, but burst bandwidth is not guaranteed.

Guaranteed bandwidth by region:

Region

Guaranteed read bandwidth

Guaranteed write bandwidth

China (Shanghai)

China (Shenzhen)

China (Beijing)

China (Hangzhou)

Singapore

Guaranteed baseline of 5 Gbps. Bandwidth increases by 20 Gbps for each additional PiB of capacity, up to a maximum of 50 Gbps.

Guaranteed baseline of 2 Gbps. Bandwidth increases by 5 Gbps for each additional PiB of capacity, up to a maximum of 20 Gbps.

China (Guangzhou)

China (Heyuan)

China (Qingdao)

China (Zhangjiakou)

China (Chengdu)

China (Ulanqab)

China (Hohhot)

Guaranteed baseline of 2 Gbps. Bandwidth increases by 20 Gbps for each additional PiB of capacity, up to a maximum of 10 Gbps.

Guaranteed baseline of 1 Gbps. Bandwidth increases by 5 Gbps for each additional PiB of capacity, up to a maximum of 10 Gbps.

China (Hong Kong)

Japan (Tokyo)

Malaysia (Kuala Lumpur)

Indonesia (Jakarta)

UK (London)

Germany (Frankfurt)

Guaranteed baseline of 1 Gbps. Bandwidth increases by 20 Gbps for each additional PiB of capacity, up to a maximum of 5 Gbps.

Guaranteed baseline of 1 Gbps. Bandwidth increases by 5 Gbps for each additional PiB of capacity, up to a maximum of 5 Gbps.

Thailand (Bangkok)

US (Virginia)

US (Silicon Valley)

Guaranteed baseline of 0.6 Gbps. Bandwidth increases by 20 Gbps for each additional PiB of capacity, up to a maximum of 2 Gbps.

Guaranteed baseline of 0.6 Gbps. Bandwidth increases by 5 Gbps for each additional PiB of capacity, up to a maximum of 2 Gbps.

Capacity storage read throttling

Capacity storage targets write-heavy, read-light workloads. Read IOPS is throttled using a token system:

  • Each instance has a token pool. When tokens drop to 0, reads are throttled to a baseline of 10 IOPS per node.

  • Token replenishment rate scales with provisioned capacity.

  • Each read I/O consumes one token. Maximum read performance: 1,500 IOPS per node.

  • Token generation rate: 0.04 IOPS per GiB (1 IOPS per 25 GiB).

  • The token pool has a maximum capacity that scales with provisioned storage.

  • Maximum pool capacity equals 48 hours of token generation. When full, new tokens replace the oldest.

  • A single query from LindormTable or LindormTSDB may generate varying I/O requests depending on cache hits and data blocks accessed. QPS cannot be reliably predicted from IOPS. Monitor token consumption to assess actual load.

image

Capacity storage monitoring metrics

  1. Log on to the Lindorm console. In the upper-left corner of the page, select the region of the instance. On the Instances page, click the ID of the target instance or click View Instance Details in the Actions column for the instance.

  2. In the left-side navigation pane, click Instance monitoring. On the Cluster overview tab, find the Underlying storage metrics section.

    Metric

    Description

    Capacity storage read tokens

    An instance-level metric group that includes the percentage of available tokens, the number of available tokens, and the maximum token count. Each read I/O consumes one token. If the available token percentage drops to 0%, read requests are throttled.

    Capacity storage read status

    Total read IOPS and read traffic across all nodes and clients. Each read I/O consumes one token. Higher read IOPS means faster token consumption. A single database read may perform multiple I/O operations and consume multiple tokens.

    Capacity storage throttling status

    Total throttled read operations per second (OPS) across all nodes and clients. A value greater than 0 indicates read throttling, which increases read latency.

    Important

    Throttling can also occur if the IOPS of a single node exceeds 1500, even if the instance's overall percentage of available tokens is greater than 0.

Usage notes

  • Capacity storage has low read IOPS. Use it only for infrequent-query workloads.

  • Write throughput is comparable to standard storage.

  • The index building process for features like secondary index, columnar index, and search index requires reading data from storage. If you have enabled hot and cold data separation, you must monitor the throttling status of your cold storage (capacity storage). If read operations on cold storage are throttled, index building slows down and may cause write backpressure.

  • Not suitable for high-concurrency read workloads. Excessive concurrent reads may cause failures.

  • If you require higher read IOPS for a large provisioned capacity, contact technical support to request an adjustment.

  • Each node can manage a maximum of 30 TB of cold data. To increase this limit, contact technical support.

  • Write operations fail when capacity storage utilization exceeds 95%. Monitor usage regularly. View the capacity of capacity storage.