Before you create a Lindorm instance, decide on four configuration dimensions: storage type, engine, node specification, and number of nodes. Each choice affects latency, performance, and cost. Use this guide to identify the right starting point for your workload.
Choose a storage type
Your storage type determines data access latency. Lindorm uses LindormDFS as the underlying storage layer, which decouples storage from compute. Storage capacity is shared across all engines within the same instance.
Decision rule: Choose your storage type based on how sensitive your workload is to read/write latency. Different storage types trade off latency against cost, so match the storage tier to your access frequency and response time requirements.
For a comparison of storage types and their latency characteristics, see Storage types.
Choose an engine
Lindorm is a multi-model database that supports SQL queries, time series data processing, and text-based data query and analysis. It is compatible with the standard APIs of several open source systems, so you can adopt it without rewriting existing application logic.
Decision rule: Match the engine to your data model and access pattern. You can enable one or more engines on a single instance. If you are unsure which engine to start with, identify whether your primary workload is relational, time series, wide-column, or search-oriented, then map it to the corresponding engine.
For guidance on which engine fits your scenario, see Engines.
Choose a node specification and number of nodes
Node sizing involves more than matching raw read/write throughput. You also need to account for access distribution and hotspot tolerance.
All Lindorm node specifications are dedicated. Each instance exclusively occupies the CPU and memory allocated to it, so its performance is not affected by other instances on the same physical server.
Default recommendation: start with fewer, higher-spec nodes
When you are unsure how your traffic will be distributed, start with a higher node specification and fewer nodes rather than more nodes with lower specifications.
-
If traffic is evenly distributed across your data: you can scale out later by adding nodes to handle increasing load. Lindorm supports unlimited horizontal scaling.
-
If traffic concentrates on a subset of data (for example, during a flash sale, a batch import, or a time-series spike): the single-node specification — not the node count — determines whether the instance can absorb the spike without latency jitter. A higher node specification gives you that headroom.
This recommendation applies in both cases because higher-spec nodes handle hotspot scenarios that more numerous lower-spec nodes cannot, while still allowing horizontal scaling when your load grows evenly over time.
For a complete sizing guide, including how to estimate the right node count and specification for your workload, see Select the number and specification of nodes.
FAQ
When both a higher-spec/fewer-nodes option and a lower-spec/more-nodes option meet my stated requirements, which should I choose?
Start with higher-spec nodes and fewer of them. Adding nodes helps when traffic is evenly distributed across data, but when traffic concentrates on a small subset — for example, during a flash sale or a bulk data import — it is the single-node specification that determines whether the instance can absorb the spike without jitter. A higher node specification gives you stronger resistance to performance jitter and better overall service stability. Because Lindorm supports unlimited horizontal scaling, you can always add nodes as traffic grows.