Choose Lindorm engines-Lindorm(Lindorm)-阿里云帮助中心

Lindorm provides multiple engines: the wide table engine, time series engine, search engine, compute engine, and streaming engine. These engines are compatible with open source APIs such as HBase, Cassandra, S3, OpenTSDB, Solr, and HDFS, and support SQL queries, time series processing, and full-text search.

Each engine can be independently scaled to adapt to dynamic workloads. The wide table engine and time series engine provide high-concurrency throughput.

Select an engine

Select one or more engines based on your requirements. The following table describes each engine.

Engine	Compatibility	Scenario	Description
Wide table engine (LindormTable)	Compatible with SQL, the HBase API, Cassandra Query Language (CQL), and the Amazon S3 API.	Suitable for managing and analyzing metadata, orders, bills, user personas, social information, feeds, logs, trajectories.	A distributed engine for semi-structured and structured data at scale. Supports global secondary indexes, multi-dimensional searches, dynamic columns, and TTL. Handles tens of millions of concurrent requests and stores up to hundreds of petabytes of data. Compared with open source HBase: 3-7x read/write throughput, 1/10 P99 latency, 2x compression ratio, and 50% lower storage cost. Includes hot/cold data separation. The built-in Ganos service supports spatial and spatio-temporal data for large-scale historical trajectory queries.
Time series engine (LindormTSDB)	Provides an HTTP API and is compatible with the OpenTSDB API.	Suitable for storing and processing time series data such as measurement data and operational data of devices in scenarios such as IoT and monitoring.	A distributed engine optimized for time series data. Supports SQL queries, dedicated time series compression algorithms for improved compression ratios, multi-dimensional timeline queries and aggregation, downsampling, and elastic scaling.
Search engine (LindormSearch)	Compatible with SQL, Apache Solr, and Elasticsearch APIs.	Suitable for querying large amounts of data, such as logs, text, and documents. For example, you can use the search engine to search for logs, bills, and user personas.	A distributed search engine with decoupled storage and compute. Seamlessly indexes data from the wide table and time series engines to accelerate queries. Supports full-text search, aggregation, complex multi-dimensional queries, horizontal scaling, one-write-multiple-read architecture, cross-zone disaster recovery, and TTL.
Compute engine (LDPS)	Compatible with the Apache Spark API.	Suitable for scenarios such as the production of large amounts of data, interactive analytics, computational learning, and graph computing.	A cloud-native distributed computing service compatible with community Spark models and APIs. Deeply integrated with Lindorm storage engines to leverage underlying data features and indexes for efficient distributed job execution.
Streaming engine	Compatible with SQL and the Apache Kafka API.	Suitable for scenarios such as IoT data processing, application log processing, logistics aging analysis, travel data processing, and real-time trajectory processing.	An engine for storing and performing lightweight computation on streaming data. Stores streaming data to Lindorm for real-time processing. Combined with the wide table engine's Ganos service, enables real-time trajectory analysis such as geofencing and regional statistics.

Select node specifications and quantity

Lindorm supports horizontal scale-out of engine nodes. Adding nodes resolves issues such as high latency and unstable performance. However, adding nodes alone cannot resolve single-node hotspot issues — you must upgrade the node specification instead. The node specification determines the single-node hotspot handling capacity. Lower-specification nodes may experience excessive load or out-of-memory (OOM) errors under heavy traffic.

Evaluate your workload and choose appropriate node specifications. To upgrade node specifications, use the Lindorm console. For more information, see Change instance type. For assistance, contact Lindorm technical support (DingTalk ID: s0s3eg3).

Wide table engine (LindormTable)

LindormTable nodes support specifications from 4 cores / 8 GB to 32 cores / 256 GB, with horizontal scale-out. Choose a specification based on your per-node request rate (rows/s) and region count.

Note

When Product Type is set to Lindorm, the minimum LindormTable specification is 4 cores / 16 GB.
Some performance optimizations require nodes with more than 16 GB of memory, and some write optimizations require at least 3 nodes. We recommend at least 3 nodes with 8 cores / 32 GB each (16 cores / 64 GB preferred).

Recommended specifications:

< 1,000 requests/s per node, < 500 regions per node: 4 cores / 16 GB.
< 20,000 requests/s per node, < 1,000 regions per node: 8 cores / 32 GB or higher.
> 20,000 requests/s per node, > 1,000 regions per node: 16 cores / 64 GB or higher.
Important
Request rate and region count are not the only factors for choosing node specifications.
- For complex workloads, the recommendations above may be insufficient. Choose a higher specification if any of the following apply:
  - Row sizes reach kilobytes or megabytes.
  - SCAN requests use complex filters.
  - Cache hit rate is low — most requests read from disk.
  - The instance contains many tables.
- For online services, choose larger memory to improve cache hit rates.
- For offline heavy-load tasks (MapReduce, Spark) or very high TPS/QPS, choose more CPU cores.
- If CPU utilization stays at 70% or above, consider upgrading the node specification.

Time series engine (LindormTSDB)

LindormTSDB nodes support specifications from 4 cores / 8 GB to 32 cores / 256 GB. Select the node specification and quantity based on your TPS (measurement points/second).

Note

When Product Type is set to Lindorm, the minimum LindormTSDB specification is 4 cores / 16 GB.

Recommended specifications (3-node cluster):

TPS < 1.9M: 4 cores / 16 GB per node.
TPS < 3.9M: 8 cores / 32 GB per node.
TPS < 7.8M: 16 cores / 64 GB per node.
TPS < 11M: 32 cores / 128 GB per node.

Note

These recommendations assume optimal data processing performance. Actual capacity depends on your business model, batch size, and concurrency. For more information, see Results of write tests and Query test results.