ApsaraDB for Lindorm (Lindorm) uses LindormStore to decouple storage from computing. The storage fee is separately charged. You can perform online scale-up operations without downtime. The storage capacity of a Lindorm instance is shared among multiple engines within the same instance.

Storage types

Lindorm provides three storage types: capacity, standard, and performance. The following table describes the scenarios of different storage types.

Storage type Latency Scenario Recommended engine
Capacity 15ms ~ 3s Applicable to scenarios in which infrequently accessed data is stored. For example, you can use this storage type to store monitoring logs and historical orders, archive audio and video files, store data to data lakes, and compute data offline. The wide table engine, the time series engine, and the file engine
Standard 3ms ~ 5ms Applicable to scenarios in which data is accessed in real time. For example, you can use this storage type for feed storage, data exchanges in chats, real-time report processing, and online computing. The wide table engine, the time series engine, the search engine, and the file engine
Performance 0.2ms ~ 0.5ms Applicable to scenarios in which data access requires low latency. For example, you can use this storage type for bid advertising, user persona creation, customer group selection, real-time searches, and risk control. The wide table engine, the time series engine, the search engine, and the file engine
Note

Latency refers only to the storage latency and does not refer to the end-to-end latency.

Capacity storage uses high-density disk arrays to provide extremely cost-effective storage services and supports high read/write throughput. However, it delivers relatively poor random read performance. The capacity storage type is suitable for the scenarios in which a large number of write requests and a few read requests are processed or big data analytics scenarios.