No. Table Store supports semi-structured tables. Only the primary key columns (columns 1-4) are required during table creation.
The number of attribute columns of a table is not limited in Table Store. Each row of data can have different quantities and types of attribute columns. When the application is writing data, Table Store needs the application to specify the names and values of all the data columns (primary key columns and attribute columns).
When the table data size reaches a set value, Table Store partitions the table based on the range of values in the partition key column to achieve load balancing.
At table creation, the table has one partition by default and all table data is in this partition. When the table has multiple partitions, the data stored in each partition is all the data within a certain range of values in the partition key column. All the ranges of values in the partition key column are segmented by the natural order of the column values based on the data type Integer or String in the primary key column.
In addition to the data query performance, data partitioning also affects the usage of your reserved read/write throughput. When a table has multiple partitions, the reserved read/write throughput of the table is proportioned to each partition.
Selection of the partition key is important at table creation because it affects the query performance of the table when massive data exists. When setting the partition key for applications, observe the following basic principles:
Do not use attributes with a fixed value or a small value range, such as user gender (Male/Female).
Avoid attributes that have obvious query hotspots after sorting by the natural order, for example, using TimeStamp as the partition key for querying the latest data.
Use attributes with scattered query hotspots after sorting by the natural order, such as UserID.
We recommend that you hash the data according to the application features before writing the partition key. For example, when writing a row of data, generate a hash value for the UserID using the simple hash algorithm, splice the hash value and the UserID, and save them as the partition key value to the Table Store table. This lightweight operation can effectively solve some query hotspot issues. Note that because the partition key value is a result of the spliced hash value and actual value, the application cannot read the range (getRange) using the partition key.
Each Table Store user can create up to 10 instances and each instance can have up to 64 tables, amounting to a maximum of 100 tables under one account.
The limit on the number of tables may be increased in the following scenarios:
Huge data volumes and high query performance requirement
Different from conventional SQL databases (for example, MySQL) which address massive data access demands by database sharding and table partitioning, Table Store adopts the distributed design and cracks the bottleneck of huge data volumes and access latency.
You can save the structured or semi-structured data in a sparse table, without worrying about the compromised query performance resulting from huge data volumes.
Rapid growth in applications
In addition to the increase in data and access volumes, you may use Table Store to offer services to your customers (such as third-party partners and vendors). If you provide services for vendors and have a solution based on Table Store, you must deploy a set of Table Store tables for each vendor. In this case, the number of tables quickly reaches the upper limit. If you constantly increase the upper limit on table quantities, it can cause uncontrollable costs of operation and maintenance and increase the complexity of global data analysis.
We recommend that you use Table Store in a new way and save the same type of massive structured/semi-structured data to a large table.
Considerations of Table Store
The number of tables is a resource attribute in the distributed architecture of Table Store. It can be understood that the number of tables has a maximum value given a fixed scale of a Table Store cluster. The scalability of Table Store can effectively address the limit of table quantities, but for resource controllability, Table Store sets a limit on the maximum number of tables under one account.
To increase the maximum number of tables under your account, you can open a ticket.