This topic describes the key advantages of Lindorm compared to Apache HBase.
Category | Lindorm | Apache HBase | |
Core features | HBase API | Supported | Supported |
Data model | Supports multiple data models, including wide column (HBase API), table (SQL-like API), and queue. Contact us to learn more about other models. | Supports only the wide column model. | |
Global secondary index | Provides a built-in global secondary index that ensures high-performance, transparent queries and allows on-demand redundancy for non-indexed columns. For more information, see secondary index. | Requires complex configuration of external components. | |
Full-text search | Integrates with the Solr search engine to provide unified access to storage, multi-dimensional queries, and full-text indexing for massive datasets. For more information, see full-text index service. | Not supported | |
Performance | Throughput | Delivers up to 7 times the single-node throughput of Apache HBase. For more information, see Test results. | No optimization |
Latency spike | Reduces P99 latency to one-tenth that of Apache HBase. For more information, see Test results. | No optimization | |
Cost | Data compression | Uses a deeply optimized Zstandard (ZSTD) algorithm, rewritten with Java Native Access (JNA) to prevent core dumps. This algorithm uses dictionary sampling to improve the compression ratio by 50% over Snappy and achieves a compression ratio of up to 10:1. | Uses Snappy by default. Using ZSTD requires Hadoop 3.0 and poses a risk of core dumps. |
Encoding | Uses the IndexableDelta algorithm, which provides the same compression ratio as the DIFF algorithm but doubles the access speed. | Recommends the DIFF algorithm, which provides slower random access. | |
Hot and cold data separation | Automatically tiers data, storing cold data with high compression on low-cost media. This reduces storage costs by 70% and improves hot data access performance by 15%. For more information, see hot and cold data separation. | Not supported | |
Storage media | Supports a variety of storage media, including ultra disk, standard SSD, local HDD, and local SSD. Also supports cold storage on Object Storage Service (OSS) and highly cost-effective capacity-optimized disks (coming soon). | N/A | |
Reliability | Active-standby redundancy | Provides a mature solution for dual-cluster deployments, featuring automatic failover and concurrent request processing. You can also create a hybrid active-standby setup with a self-managed HBase instance. | Not optimized and does not support failover. |
Backup and restoration | Supports backups of over 100 TB of data to Object Storage Service (OSS). It provides advanced capabilities, such as an RTO of less than 30 minutes regardless of data size, on-demand backups, and point-in-time recovery. For more information, see Enable backup and restoration. | Not supported | |
MTTR | Achieves a recovery speed 10 times faster than Apache HBase, significantly reducing the mean time to repair (MTTR). | No optimization | |
Multitenancy | Authentication and ACL | Provides username and password authentication and ACL management. For more information, see Manage users and ACLs. | Complex to configure |
Resource isolation | Provides physical resource isolation between tenants through resource groups. | Not supported | |
O&M and diagnostics | O&M tools | Provides a GUI-based cluster management system for managing tables, namespaces, groups, and ACLs. For more information, see cluster management system. | HBase Shell |
Data query | Supports data queries through both HBase Shell and an interactive SQL query tool in the GUI-based cluster management system. For more information, see Data query. | HBase Shell | |
Ecosystem | Data migration | Supports online, automated, and cross-version data migration from various HBase versions without impacting applications or requiring code changes. For more information, see Introduction to Lindorm Tunnel Service (LTS). | Supports only offline migration. |
MySQL data synchronization | Supports full and real-time synchronization of data from MySQL to Lindorm. For more information, see Introduction to Lindorm Tunnel Service (LTS). | Requires third-party tools and does not support online incremental synchronization. | |
Spark analysis | Offers productized integration with Spark. You can use Spark SQL to analyze Lindorm data, perform incremental archiving from Lindorm to Spark (HDFS/OSS), and return offline analysis results to Lindorm. | No optimization. Data integration requires significant development effort. | |
MaxCompute | Provides productized integration. For more information, see Export full data to MaxCompute. | Data integration requires significant development effort. | |
Log Service (SLS) | Supports incremental data import from Log Service (SLS). For more information, see Introduction to Lindorm Tunnel Service (LTS). | Data integration requires significant development effort. | |
Service capabilities | Service level agreement (SLA) | Includes a service level agreement (SLA) guaranteeing 99.9% availability for a single cluster and 99.95% for a high-availability dual-cluster deployment. | N/A |
O&M cost | Provides a fully managed service that eliminates complex database O&M and reduces operational overhead. | N/A | |
Technical team | Supported by a dedicated team that includes multiple Apache community PMC members and committers. | N/A | |
Practical experience | Battle-tested at a massive scale, supporting Alibaba's 11.11 Global Shopping Festival for nine consecutive years on tens of thousands of servers. | N/A | |
Comparison with traditional databases
