Hologres is an all-in-one distributed real-time data warehouse engine that has high performance and separates computing from storage. It stores data on shards that reside in the underlying storage system. This topic describes table groups and shard counts in Hologres.
Table group and shard count
In Hologres, data is stored in shards on the Apsara Distributed File System. Table groups are similar to the storage logic and are used to manage these shards. The data in a table is stored in a fixed group of shards. When data is written to a Hologres table, the data is distributed to specific shards based on the distribution key. When a table is created, a group of shards is allocated to store data in the table. This group of shards is called a table group.
A table group is a logical storage concept specific to Hologres. PostgreSQL does not have this concept. Table group differs from tablespace in PostgreSQL. A tablespace uniquely identifies the storage location of database objects and is similar to a directory. A table group represents a group of underlying logical shards.
Based on the figure, the following relationships can be inferred.
- Relationship between table groups and schemas
A schema is a standard database concept, whereas a table group is not a standard database concept, but a logical storage concept. Tables in different schemas can belong to the same table group. In other words, the same group of shards is used to store data in these tables at the underlying layer.
- Relationship between table groups and databases
A database contains one or more table groups, and each database can have only one table group. After you create a database, Hologres creates a default table group. You can add table groups or modify the default table group based on your business requirements.
- Relationship between different table groups
A database can contain more table groups. Shards are not shared between these table groups, and each shard has a unique ID in an instance.
- Shard Count
The number of shards in a table group is called the shard count. You must specify the shard count when you create a table group, and you cannot change the shard count later. You can change the shard count only by creating another table group.
- Relationship between tables and shards
- Shards are used to store and query data in a table. Hologres determines the shards to which the data is distributed based on the distribution key. Without the distribution key, the data is randomly allocated to the shards.
- A table group can contain multiple tables. In other words, multiple tables can belong to the same group of shards. However, a table can belong to only one table group. If a table group contains no tables, Hologres automatically deletes the table group.
- You cannot move a table to another table group unless you re-create the table or call the function that is used to move a table to another table group.
Relationship between shard counts and worker compute nodes
In Hologres, the storage engine is used to manage and process data. In Data Manipulation Language (DML), the storage engine provides a single or batch create, read, update, and delete (CRUD) operations. The query engine can access data on shards by calling these operations to implement high-performance data writes or reads.
The following figure shows how table groups and shard counts are related to storage
allocation and workers.
- When you create a database, you can create table groups and set the shard count for each table group. Each worker creates multiple internal storage engines and each storage engine reads data from and writes data to a shard. If you do not specify the number of table groups and shard count when you create a database, Hologres creates a default table group for you and sets the default shard count for the table group. For more information, see Instance types.
- Hologres ensures that storage engines are evenly distributed in each worker. This allows resources to be allocated evenly among the workers.
- Hologres ensures that shards in a table group are distributed to multiple workers.
This prevents uneven resource allocation where a table group is allocated to one worker
and other workers are idle. However, if the shard count in table groups is not proportional
to the number of workers in an instance, the shards cannot be allocated to some workers
and these workers become idle. When you specify the shard count, make sure that the
total shard count in the instance is proportional to the number of workers.
In the preceding figure,
Table Group 1contains three shards but these shards are allocated to two workers. This means that the shard count in the table group is not proportional to the number of workers. Therefore, the shard count allocated to a worker is one more than that allocated to the other worker. In this case, resources are unevenly allocated to the workers and a long tail occurs. To address this, we recommend that you change the shard count to make sure that the shard count is proportional to the number of workers. In the following figure, the total shard count inTable Group 1andTable Group 2is a multiple of the number of workers. Resources can be evenly allocated to the workers.
If a worker fails over due to reasons such as out of memory (OOM), Hologres automatically allocate the shards corresponding to this worker to other healthy workers. This ensures even allocation of shards to each healthy worker. In the following example, there are four workers in an instance and two table groups contain eight shards. Originally, each worker has two storage engines and the storage engines correspond to two shards. AfterWorker 4that is allocatedShard 7andShard 8fails over,Shard 7andShard 8are quickly allocated to the other three workers. Because there are only two shards, the system randomly selects two workers to allocate the shards. This ensures that the number of storage engines on each worker is basically even.
Summary
- If a table group has a large shard count, data can be written, queried, and analyzed at high concurrency. However, a larger shard count does not necessarily bring better performance. More communications and computing resources and larger memory space are required for increased shards. From this perspective, if resources are insufficient or only a small amount of data is queried, increasing the shard count may lead to the opposite effect.
- In Hologres, the lower limit of the shard count is 1. If the data amount is only hundreds or thousands of records, you can set the shard count to 1. In principle, the upper limit of the shard count is the total number of computing cores of your instance. This ensures that each shard can occupy at least one core for computing. If the shard count exceeds the number of computing cores, some shards cannot be allocated CPU resources all the time during the query. This may cause long tails and failover overheads.
- Similar to the shard count, the number of table groups must be set to an appropriate value. A shard occupies specific memory space regardless of whether it is in use, to store information such as metadata and schemas in a table. If data is written to the tables, the shard occupies more memory space. The total number of shards in your instance increases with the number of table groups, which results in larger memory space. In addition, if you want to perform local join operations on multiple tables that are related to each other, these tables must belong to the same table group.
- From the perspective of a disk, for the same table, if more shards exist, the data is more scattered, small files are more likely to appear, and the number of files is greater. If a large number of tables and shards exist, the number of files becomes very large. Consequently, more overheads are required during query and failover, query I/O is increased, and a longer recovery time is required.