Lindorm LindormTable is a distributed storage engine for massive semi-structured and structured data, including metadata, orders, bills, user profiles, social, feeds, and logs. Compatible with HBase and Phoenix (SQL), it supports single tables with hundreds of trillions of rows, tens of millions of concurrent requests, millisecond-level responses, and cross-data-center strong consistency for disaster recovery.
Core features
|
Feature |
Description |
|
Low cost |
High-density, low-cost storage media, intelligent hot/cold separation, high-compression algorithms, and adaptive encoding reduce storage and processing costs by up to 80% compared to self-managed databases. |
|
Cloud-native elasticity |
Storage-compute separation and serverless technology deliver instant, on-demand scaling for compute and storage. |
|
Ultra-wide tables |
Supports ultra-wide tables with over 10,000 columns and enables real-time, high-concurrency writes. |
|
Enterprise-grade stability |
Battle-tested for over a decade in Alibaba Group production environments, built on a high-availability architecture for rock-solid, enterprise-grade stability. |
|
Rich ecosystem |
Compatible with HBase and other open-source interfaces. Works with Spark, Flink, and other compute engines for seamless data ecosystem integration. |
Explore all Lindorm LindormTable capabilities: Features | Lindorm vs. HBase vs. Cassandra.
Architecture
Lindorm wide table engine architecture:
Key architectural designs:
-
Data storage and high availability
-
LindormTable persists data in LDFS, automatically partitioning it across cluster servers.
-
Each partition has 1 to N replicas (primary or secondary). Replicas can span zones for high availability and consistency.
-
Synchronization and read/write behavior varies by consistency mode:
-
Strong consistency: Only the primary handles reads and writes. Data is asynchronously replayed to secondaries. If the primary fails, a secondary is promoted to primary. The Master coordinates this promotion to ensure synchronization is complete.
-
Eventual consistency: Both primary and secondary replicas handle reads and writes. Data synchronizes between them to ensure eventual consistency across all replicas.
-
-
-
Multi-replica optimization
-
Timed trigger: A
GlitchTimeoutis set per request. On timeout, the request is resent to the other N-1 replicas, and the fastest response wins. -
Automatic replica isolation: Unhealthy replicas are isolated based on timeouts, errors, and health checks to maintain service stability.
-
-
Hot/cold data separation
LSM structure: Combines with LStore to automatically tier hot and cold data, enabling transparent queries at lower storage costs.
-
Data model
Flexible schema: Supports dynamic columns (no DDL required), global secondary indexes, and inverted indexes. The system auto-selects the optimal index based on query conditions to accelerate multi-condition queries.
Use cases
Access methods
Access the same LindormTable data through either method, or both simultaneously.
-
Lindorm SQL (Recommended): Relational-database-like developer experience.
-
HBase API: For applications already built on HBase.