This page compares Lindorm GanosBase against HBase with GeoMesa and ApsaraDB for MongoDB across four dimensions: write throughput, storage footprint, spatial range query latency, and spatio-temporal range query latency.
Test environment
All three databases use equivalent node specs to ensure a fair comparison.
| Database | Configuration |
|---|---|
| Lindorm instance with Lindorm GanosBase activated | 3 LindormTable nodes, each with 16 dedicated CPU cores and 32 GB of dedicated memory. Storage type: Performance-optimized storage. |
| HBase cluster with GeoMesa installed | GeoMesa 3.0.0. 3 HBase nodes, each with 16 dedicated CPU cores and 32 GB of dedicated memory. Storage type (core node): SSD cloud disks. |
| ApsaraDB for MongoDB sharded cluster | MongoDB 5.0. 3 mongos nodes, each with 16 dedicated CPU cores and 32 GB of dedicated memory. 3 shard nodes, each with 16 dedicated CPU cores and 64 GB of dedicated memory. Storage type: SSD cloud disks. |
Test results
Write performance
Lindorm GanosBase inherits the data writing capabilities of LindormTable. Writing 7.6 GB of spatio-temporal trajectory data took 7 minutes with Lindorm GanosBase — roughly half the time of HBase with GeoMesa, and one-fifth the time of ApsaraDB for MongoDB.
| Database | Write time (7.6 GB) |
|---|---|
| Lindorm instance with Lindorm GanosBase activated | 7 minutes |
| HBase cluster with GeoMesa installed | 13 minutes |
| ApsaraDB for MongoDB sharded cluster | 34 minutes |
Storage usage
When spatio-temporal primary key indexes are used, Lindorm GanosBase stores the same dataset in less space. Indexes are built into the primary key rather than maintained as separate structures, so there is no additional index footprint.
| Database | Table size | Spatio-temporal primary key index |
|---|---|---|
| Lindorm instance with Lindorm GanosBase activated | 4.7 GB | None |
| HBase cluster with GeoMesa installed | 5.9 GB | None |
| ApsaraDB for MongoDB sharded cluster | 8.2 GB | 1.6 GB |
Lindorm GanosBase uses approximately 80% of the storage that HBase with GeoMesa requires, and approximately 47% of the storage that ApsaraDB for MongoDB requires.
Spatial range query latency
When you query spatial ranges, the time used for query increases when more results are returned. In most scenarios, Lindorm GanosBase completes spatial range queries in about one-third the time of HBase with GeoMesa and about half the time of ApsaraDB for MongoDB.
Spatio-temporal range query latency
In most scenarios, Lindorm GanosBase completes spatio-temporal range queries in about one-third the time of HBase with GeoMesa and about half the time of ApsaraDB for MongoDB. In a subset of queries, the three systems perform similarly.
Summary
Lindorm GanosBase offers the following advantages over HBase with GeoMesa and ApsaraDB for MongoDB:
SQL-based querying: Query spatio-temporal data using standard SQL statements without additional tooling.
Integrated storage and indexing: LindormTable handles most business workloads directly, keeping the solution simple.
Faster writes: Write spatio-temporal data up to 5 times faster than ApsaraDB for MongoDB and up to 2 times faster than HBase with GeoMesa.
Lower storage costs: Reduce storage costs by 20% to 50% compared to HBase with GeoMesa and ApsaraDB for MongoDB.
Higher query throughput: Achieve 2–3x better query performance in most scenarios.
Lindorm GanosBase is well-suited for high-frequency write workloads with spatio-temporal query requirements, such as Internet of Vehicles (IoV) platforms and travel scenarios.