considerations for creating Tablestore tables-Tablestore(Tablestore)-阿里云帮助中心

Tablestore tables are semi-structured: you define one to four primary key columns at creation time, but attribute columns are schema-free. Each row can have a different set of attribute columns, and a table can hold an unlimited number of them.

When an application writes data, it must specify the names and values for all columns in that write operation, including primary key and attribute columns.

How the partition key works

The first primary key column is the partition key. When a table's data volume reaches a threshold, Tablestore automatically splits the data based on the partition key value range. This process—called data partitioning—balances read and write load across the table.

A new table starts with a single partition. As the table grows and Tablestore creates additional partitions, each partition stores data within a specific partition key value range. Splits follow the natural sort order of the partition key's data type, such as Integer or String.

Data partitioning also affects reserved throughput allocation. When a table has multiple partitions, its reserved read throughput and reserved write throughput are distributed proportionally across those partitions.

Choose a partition key

The partition key determines how data is distributed across partitions, which directly affects read and write performance for large tables. A good partition key distributes access evenly; a poor one concentrates traffic on a single partition—creating a hot spot.

Use the following table to evaluate candidate partition keys:

Partition key candidate	Uniformity	Reason
User ID (high cardinality, many distinct values)	Good	Spreads access evenly across partitions
Device ID (many devices, similar access patterns)	Good	Access is naturally distributed
Timestamp (frequently querying the latest data)	Bad	Recent timestamps cluster writes in one partition
Status code (only a few possible values)	Bad	Low cardinality concentrates data in few partitions
Customer gender (Male, Female)	Bad	Static values with a tiny range

Key principles:

Avoid properties with static values or a small range of possible values.
Avoid properties that naturally sort into access hot spots, such as timestamps when your workload focuses on the most recent data.
Choose properties with high cardinality that distribute access evenly, such as a user ID.

For more information, see Table operations.

Handle unpredictable hot spots

When you cannot predict which partition key values will be accessed most, use a hashing strategy to distribute writes more evenly. Two approaches are available:

Strategy	When to use	How it works	Trade-off
Random suffix	Write throughput is the top priority and item-level reads are rare	Append a random number (e.g., 1–200) to the partition key value. For example, `UserID_42`.	Writes spread across partitions, but reads require querying all suffix variants and merging results.
Calculated suffix	You need to retrieve individual items by key	Derive the suffix from something you know at query time—for example, hash the UserID modulo 200. For example, `UserID_{hash(UserID) % 200}`.	You can recalculate the suffix to retrieve a specific item, but range reads (GetRange) on the original key are no longer possible.

Both strategies add a lightweight computation step at write time.

Table limits per account

An Alibaba Cloud account supports up to 10 Tablestore instances, each with up to 64 tables—640 tables total. This limit exists because in a distributed architecture, the number of tables is a resource property: a cluster of a given size can support only a bounded number of tables.

Hitting this limit typically reflects one of two design patterns that Tablestore's large table model is built to address:

High-volume workloads: Traditional databases like MySQL use sharding to scale out. Tablestore's distributed architecture eliminates that need—store structured or semi-structured data in one large, sparse table without sacrificing performance as data volume grows.
Multi-tenant applications: If each new tenant (such as a supplier or partner) gets its own set of tables, the account limit fills up quickly and makes global analytics difficult. Instead, use a single large table with a tenant identifier as part of the primary key.

To raise the table limit for your account, submit a ticket.

For the full list of service limits, see Limits.