All Products
Search
Document Center

Lindorm:Benefits

Last Updated:Apr 10, 2025

This topic compares Lindorm with other open source database services to show the benefits of Lindorm.

Background information

Lindorm is compatible with the standard APIs of multiple open source database services, such as Apache HBase, Apache Cassandra, AWS S3, TSDB, HDFS, and Apache Solr. In addition, Lindorm supports various data models such as wide tables, time series, objects, texts, queues, and spatial data. Therefore, Lindorm is applicable to store and analyze multiple types of data such as logs, bills and tags with high performance and low costs.

This topic compares the features, performance, and cost of Lindorm with those of Apache HBase, Apache Cassandra, OpenTSDB, ElasticSearch, Solr, and open source HDFS. This helps you understand the differences between Lindorm and other database services and the advantages of Lindorm.

Comparison between Lindorm and other database services

Lindorm VS Apache HBase VS Apache Cassandra

Lindorm provides a wide table engine named LindormTable for large amounts of semi-structured data and structured data. LindormTable is a distributed storage system and is compatible with the standard APIs of multiple open source software and services, such as Apache HBase, Apache Phoenix, and Apache Cassandra. The following table compares the features, performance, and costs of Lindorm, Apache HBase, and Apache Cassandra.

Item

Lindorm

Apache HBase

Apache Cassandra

Core features

Data models

Lindorm supports multiple data models such as wide tables, time series, searches, and files. You can use multiple types of clients and multiple APIs to access wide tables.

Only wide tables are supported.

Only wide tables are supported.

Supported APIs

Lindorm supports the HBase API, Cassandra Query Language (CQL), and Phoenix SQL and provides data interoperability. For example, data that is written into Lindorm by using the HBase API can be queried by using CQL.

Apache HBase supports the HBase API and Phoenix SQL.

Cassandra CQL

SQL

Lindorm supports standard Java Database Connectivity (JDBC) protocols and is compatible with Apache Phoenix. Lindorm provides higher stability and performance.

Apache HBase requires external components to support Phoenix.

Apache Cassandra supports simple SQL dialects.

Data types

Lindorm supports various data types. For more information, see Data types.

Apache HBase supports only the BYTE[] type.

Apache Cassandra supports various data types.

TTL

Lindorm supports the enterprise-grade time-to-live (TTL) feature. You can specify TTL values based on various granularities, such as tables, columns, and cells.

Table-level TTL and cell-level TTL are supported.

Only table-level TTL is supported.

Strong consistency

Lindorm supports multiple consistency levels such as strong consistency and eventual consistency.

Supported

Supported

Global secondary indexes

Lindorm provides built-in global secondary indexes. This helps make queries transparent, improves performance, and allows you to configure redundancy for non-index key columns based on your business requirements.

Apache HBase requires external components to support global secondary indexes. In this case, the configuration process is complex.

Apache Cassandra supports global secondary indexes.

Multi-dimensional searches

LindormTable is integrated with LindormSearch and supports unified access capabilities. For example, Lindorm can store large amounts of data and supports multi-dimensional queries and full-text searches. For more information, see Overview.

Not supported

Not supported

Performance

Throughput

The throughput of a Lindorm instance is seven times that of an open source Apache HBase instance. For more information, see Analyze benchmark results.

No available data

No available data

Response latency

The P99 latency of a Lindorm instance is 1/10 of that of an open source Apache HBase instance. For more information, see Analyze benchmark results.

Response latency frequently occurs.

Response latency frequently occurs.

Costs

Storage costs

Lindorm supports various storage specifications such as Performance, Standard, and Capacity. The storage cost of Lindorm is 80% lower than the cost of self-managed cloud disks.

Apache HBase supports self-managed disks that are developed based on cloud disks or local disks. Disks of this type incur high costs and do not support scaling.

Apache Solr supports self-managed disks that are developed based on cloud disks or local disks. Disks of this type incur high costs and do not support scaling.

Separation of computing and storage resources

Supported. Storage resources and computing resources can be separately scaled.

Not supported

Not supported

Data compression

Lindorm provides a built-in optimized compression algorithm. The data compression ratio can exceed 10:1, which is more than 50% higher than the compression ratio that is provided by Snappy.

Apache HBase supports Snappy, LZ4, and LZO. The compression ratio is not high.

Apache Cassandra supports Snappy and LZ4. The compression ratio is not high.

Encoding

Lindorm provides adaptive encoding for data types. This helps you ensure a high compression ratio and allows you to perform fast queries without the need for decoding.

Apache HBase supports DIFF. The compression effect is moderate, and the encoded data cannot be retrieved.

Not supported

Hot and cold data separation

Hot data and cold data are automatically stored in tiered storage. Lindorm uses high-compression and cost-effective media to store cold data. This helps reduce the storage cost by 80% and improve the query performance for hot data by 15%. For more information, see Overview.

Not supported

Not supported

Scalability and elasticity

Minimum number of nodes

N/A

At least 3 nodes

At least 3 nodes

Scalability

High scalability. An instance can be scaled out to contain several thousands of nodes.

High scalability. An instance can be scaled out to contain several thousands of nodes.

Moderate scalability. An instance can be scaled out to contain about 100 nodes. If this limit is exceeded, the performance bottleneck of the instance can be reached.

Reliability

Active-active redundancy

Supported. Lindorm supports advanced capabilities such as automatic failover and dual-cluster deployment for concurrent request processing. You can deploy a Lindorm instance and a self-managed Apache HBase or Apache Cassandra instance in primary/secondary mode.

Failover is not supported.

Apache Cassandra supports active-active redundancy but requires three replicas.

Strong consistency across data centers

An instance can be deployed across data centers. This way, data center-level disaster recovery can be performed and strong data consistency is ensured.

Not supported

Not supported

Backup and restoration

Lindorm allows you to back up more than 100 TB of data to Object Storage Service (OSS) and provides advanced capabilities such as a recovery time objective (RTO) of less than 30 minutes, on-demand backup, and point-in-time restoration. The RTO is ensured regardless of the amount of data. For more information, see Enable data backup and restoration.

Apache HBase provides limited support for data backup and restoration.

Apache Cassandra provides limited support for data backup and restoration.

Active geo-redundancy

Supported. You can use Lindorm to deploy databases across regions and units and synchronize data based on your business requirements.

Not supported

Apache Cassandra provides moderate support for the active geo-redundancy feature.

Multitenancy and security

Authentication and ACL

Lindorm supports ACLs and authentication based on username and password.

Not supported

Supported

Resource isolation

Lindorm provides the resource group feature to allow you to physically isolate resources among tenants.

Not supported

Not supported

Quota

Lindorm supports global quotas for tenants, including request quotas and storage quotas.

Multitenancy is not supported.

Not supported

At-rest encryption

Supported. Lindorm uses Key Management Service (KMS) to manage keys and encrypts all data and logs.

Apache HBase provides limited support for at-rest encryption.

Not supported

Remote procedure call (RPC) blacklist

Supported. You can limit the number of RPC calls.

Not supported

Not supported

Auditing

Not supported

Not supported

Not supported

Advanced features

Table recycle bin

After a data table is deleted, it is moved to the recycle bin. You can recover the data table to prevent unexpected data loss.

Not supported

Not supported

Cascading splitting

Regions can be continuously split without the need to wait for the compaction process to be complete. This helps improve the scaling and load balancing capabilities.

Not supported

Not supported

Discrete TTL

Lindorm allows you to retain data of multiple time ranges.

Not supported

Not supported

O&M and diagnostics

O&M tools

Lindorm provides a GUI-based cluster management tool that allows you to manage tables, namespaces, groups, and ACLs. For more information, see Log on to the cluster management system.

HBase Shell

CLI-based tools that do not provide GUIs

Data queries

Lindorm provides a cluster management system that allows you to run SQL queries in a graphical interface. For more information, see Data Query. Lindorm also supports HBase Shell and CQLsh.

HBase Shell

CQLsh

Ecosystem

Data migration

Lindorm supports online, cross-version, automated, and efficient data migration from each version of Apache HBase or Apache Cassandra. During the migration process, your application is not affected, and you do not need to modify the code of the application. For more information, see Overview.

Only offline migration is supported.

Only offline migration is supported.

Data synchronization from MySQL databases

Lindorm provides Lindorm Tunnel Service (LTS). You can use LTS to import full data and synchronize incremental data in a MySQL database to Lindorm. For more information about LTS, see Overview.

Open source ElasticSearch does not provide dedicated tools and does not support online incremental synchronization. You need to use third-party tools to migrate data from MySQL databases.

Apache Solr does not provide dedicated tools and does not support online incremental synchronization. You need to use third-party tools to migrate data from MySQL databases.

Spark analysis

Lindorm is deeply integrated with Apache Spark. For example, you can synchronize incremental data from Lindorm to Apache Spark, use Spark SQL to analyze data in Lindorm, and then return the analysis result data that is generated offline to Lindorm.

No improvements are made. Data integration requires large numbers of development resources.

No improvements are made. Data integration requires large numbers of development resources.

MaxCompute

Lindorm is integrated with MaxCompute. You can archive incremental data in Lindorm to MaxCompute.

Data integration requires large numbers of development resources.

Data integration requires large numbers of development resources.

Simple Log Service (SLS)

Lindorm allows you to subscribe to real-time data from Log Service and import the data to Lindorm. For more information about LTS, see Overview.

Data integration requires large numbers of development resources.

Data integration requires large numbers of development resources.

Service capabilities

SLA

Lindorm provides SLA guarantees. Lindorm ensures up to 99.9% service availability for single-cluster deployment and 99.99% service availability for dual-cluster deployment.

Not provided

Not provided

O&M costs

Lindorm provides fully managed services. This way, you do not need to focus on complex database O&M operations.

The O&M costs are high.

The O&M costs are high.

Technical support

An expert team that consists of multiple Apache Project Management Committee (PMC) members and committers provides technical support.

Not provided

Not provided

Practical experience

Tens of thousands of Lindorm instances are deployed to support the business of Alibaba Group in the previous nine years during the Tmall Double 11 Shopping Festival.

None

None

Lindorm VS OpenTSDB

Lindorm provides a high-performance, cost-efficient, stable, and reliable online time series engine named LindormTSDB. LindormTSDB provides multiple capabilities such as efficient data reading and data writing, highly compressed data storage, and time series data aggregation. LindormTSDB is highly compatible with OpenTSDB protocols. It uses techniques that are developed by Alibaba Cloud, such as indexing, data models, and streaming aggregation, to provide powerful computing capabilities for time series data. The following table compares the features, performance, and costs of LindormTSDB and OpenTSDB.

Item

LindormTSDB

OpenTSDB

Operations, administration, and management

Service availability

99.9%

You must create clusters and add dependencies to ensure service availability.

Data reliability

99.9999%

You must create clusters and add dependencies to ensure service availability.

Software and hardware costs

You do not need to deploy software or hardware. You are charged based on your actual resource usage.

The cost of database servers is relatively high.

Maintenance costs

LindormTSDB provides managed services.

You must hire database administrators (DBAs) to maintain your TSDB databases. This requires high labor costs.

Deployment and expansion

LindormTSDB supports instant activation, fast deployment, and elastic scaling.

OpenTSDB requires you to procure hardware, host data centers, and deploy machines. This is time-consuming.

Dependency management

LindormTSDB is O&M-free.

You must add dependencies, such as the AysncHBase and HBase dependencies. This results in a high maintenance cost.

Parameter tuning

Default parameter configurations are provided based on best practices.

You must configure multiple parameters, such as the salt, the number of connections, the synchronous flushing mode, and compaction.

Statements used to create tables

LindormTSDB can manage table creation statements. The process is transparent to users.

O&M operations are required for static table creation statements.

Monitoring and alerting system

LindormTSDB provides a built-in monitoring system for all processes.

OpenTSDB requires third-party tools to build a monitoring system.

Features

Data models

LindormTSDB supports the multi-value data model and the single-value data model.

OpenTSDB supports only the single-value data model.

SDK

Java SDK

OpenTSDB does not support open source SDKs for queries.

Multiple data types

LindormTSDB supports multiple data types, such as the numeric, Boolean, and string types.

OpenTSDB supports only numeric data types.

SQL queries

LindormTSDB allows you to execute SQL statements to analyze and query data.

Not supported

Support for Chinese characters

LindormTSDB supports letters and Chinese characters.

OpenTSDB supports only letters.

Whether the tags parameter is required

The tags parameter is optional.

The tags parameter is required.

Number of tag keys

The maximum number of tag keys is 16.

The maximum number of tag keys is 8.

Integration capabilities

LindormTSDB can be seamlessly integrated with Flink and IoT Platform to build a variety of ecosystems.

OpenTSDB is an open source service and can barely be integrated with Alibaba Cloud services.

Storage costs

Data compression

LindormTSDB uses a compression algorithm dedicated to time series data to ensure a high compression ratio.

OpenTSDB uses common compression algorithms that yield a low compression ratio.

Stability

Data reading

LindormTSDB separates read threads from write threads by using different thread pools. This helps simplify connection management, and provides stable performance for read and write operations.

OpenTSDB couples reading and writing. This may exhaust the connection resources and increase the probability of read/write failures.

Aggregators

LindormTSDB uses streaming aggregation and fine-grained memory management to ensure strong controllability.

OpenTSDB uses in-memory aggregation. This may cause OutOfMemory exceptions.

Lindorm VS ElasticSearch VS Apache Solr

Lindorm provides a search engine named LindormSearch. LindormSearch provides distributed search storage services for large amounts of data. It is compatible with the standard Apache Solr API. The following table compares the features, performance, and costs of LindormSearch, open source Elasticsearch, and Apache Solr.

Item

LindormSearch

Open source Elasticsearch

Apache Solr

Core features

Data models

LindormSearch supports multiple data models such as wide tables, time series, searches, and files. LindormSearch can be used to seamlessly store indexes of other engines.

Only searches are supported.

Only searches are supported.

Supported APIs

Cassandra Query Language (CQL), Phoenix SQL, and the Solr API

ES API

Solr API

TTL

LindormSearch supports the enterprise-grade time-to-live (TTL) feature. You can specify TTL values based on multiple granularities, such as tables and columns.

Only table-level TTL is supported.

Only table-level TTL is supported.

Unified access API for data storage and retrieval

LindormSearch is seamlessly integrated with LindormTable and LindormTSDB to provide unified storage and retrieval capabilities for multiple data models.

Not supported

Not supported

Performance and costs

Throughput

The throughput of a single Lindorm instance is 130% to 200% that of an Apache Solr instance.

No available data

No available data

Storage costs

LindormSearch supports various storage specifications such as Performance, Standard, and Capacity. The minimum cost is 80% lower than that of self-managed cloud disks.

Open source ElasticSearch supports self-managed disks that are developed based on cloud disks or local disks. Disks of this type incur high costs and do not support scaling.

Apache Solr supports self-managed disks that are developed based on cloud disks or local disks. Disks of this type incur high costs and do not support scaling.

Separation of computing and storage resources

Supported. LindormSearch allows you to separately scale storage resources and computing resources.

Not supported

Not supported

Data compression

LindormSearch provides a built-in optimized compression algorithm. The data compression ratio can exceed 10:1, which is more than 50% higher than the compression ratio that is provided by Snappy.

Not supported

Not supported

Hot and cold data separation

LindormSearch performs automatic sharding based on the time field. The engine uses cost-effective media that features a high compression ratio to store cold data. This helps reduce costs and improve query performance for hot data.

Not supported

Not supported

Scalability

Storage scalability

High storage scalability. LindormSearch decouples storage from computing and allows you to perform scale-up or scale-out operations with a few clicks. Storage resources can be scaled up in a few seconds, and computing resources can be scaled out in a few minutes.

Low storage scalability. Data must be migrated before a scale-out operation is performed. A scale-out operation requires hours to complete.

Low storage scalability. Data must be migrated before a scale-out operation is performed. A scale-out operation requires hours to complete.

One primary replica and multiple read-only replicas

Each data shard supports one primary replica and multiple read-only replicas. You can perform scale-out operations to add read-only replicas. The scale-out operation takes effect in a few seconds.

Supported. Data migration is required before you add read-only replicas. The scale-out operation takes effect in a few hours.

Supported. Data migration is required before you add read-only replicas. The scale-out operation takes effect in a few hours.

Ecosystem

Data migration

LindormSearch supports online, automated, and efficient data migration from Apache Solr or open source Elasticsearch to Lindorm. During the migration process, your application is not affected, and you do not need to modify the code of the application. For more information, see Overview.

Only offline migration is supported.

Only offline migration is supported.

Data synchronization from MySQL databases

You can use LTS to import full data and synchronize incremental data in a MySQL database to Lindorm. For more information about LTS, see Overview.

Open source ElasticSearch does not provide dedicated tools and does not support online incremental synchronization. You need to use third-party tools to migrate data from MySQL databases.

Apache Solr does not provide dedicated tools and does not support online incremental synchronization. You need to use third-party tools to migrate data from MySQL databases.

Spark analysis

Lindorm is deeply integrated with Apache Spark. For example, you can use Spark SQL to analyze data in Lindorm, synchronize incremental data from Lindorm to Apache Spark, and then return the analysis result data that is generated offline to Lindorm.

No improvements are made. Data integration requires large numbers of development resources.

No improvements are made. Data integration requires large numbers of development resources.

Simple Log Service (SLS)

LindormSearch allows you to subscribe to real-time data from Log Service and import the data to Lindorm. For more information about LTS, see Overview.

Data integration requires large numbers of development resources.

Data integration requires large numbers of development resources.

Service capabilities

SLA

Lindorm provides SLA guarantees. Lindorm ensures up to 99.9% service availability for single-cluster deployment and 99.99% service availability for dual-cluster deployment.

Not provided

Not provided

O&M costs

Lindorm provides fully managed services. This way, you do not need to focus on complex database O&M operations.

No available data

No available data

Technical support

An expert team that consists of several Apache Project Management Committee (PMC) members and committers provides technical support.

Not provided

Not provided

Practical experience

Tens of thousands of Lindorm instances are deployed to support the business of Alibaba Group in the previous nine years during the Tmall Double 11 Shopping Festival.

None

None

Lindorm VS Open source HDFS

Lindorm provides a file engine named LindormDFS. LindormDFS provides cloud native file storage services and is compatible with Hadoop Distributed File System (HDFS) protocols. The following table compares the features, performance, and costs of LindormDFS and open source HDFS.

Item

LindormDFS

Open source HDFS

Feature positioning

Distributed file system

Distributed file system

HDFS compatibility

HDFS communication protocols

Supported

Supported

Basic read/write APIs

Fully supported

Fully supported

Advanced management APIs

Fully supported

Fully supported

Costs

Unit price of storage (Actual prices displayed on the purchase page prevail.)

Minimum: USD 0.019/GB/month

Minimum: USD 0.023/GB/month

Storage scalability

LindormDFS supports smooth online scaling.

The minimum cost of scaling is high, and the scaling step size is large.

Separation of computing and storage resources

Supported. LindormDFS decouples storage from computing. Storage and computing resources can be separately scaled.

Not supported. HDFS uses a hybrid deployment method to deploy the storage engine and the compute engine.

Hot and cold data separation

LindormDFS provides tiered storage and stores hot data and cold data in different media.

Not supported

Scalability

Number of nodes

N/A

0 to 1000

Storage capacity

0 to 1 EB

0 to 10 PB

Number of files

Hundreds of billions

Tens of millions

Ecosystem

LindormDFS can be integrated with the Alibaba Cloud data ecosystem and open source big data ecosystems such as Apache Hadoop and Apache Spark.

HDFS can be integrated with open source big data ecosystems such as Apache Hadoop and Apache Spark.

Usability

LindormDFS is O&M-free and requires simple maintenance.

HDFS provides stateful services and requires complex maintenance.