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